Airtime fairness by hostapd

I have to serve 25 clients (simultaneously streaming over tcp - must be unicast) by one AP.
Obviously Airtime Fairness is what I think of now.

Hostapd says the following

Set the airtime policy operating mode:

0 = disabled (default)

1 = static config

2 = per-BSS dynamic config

3 = per-BSS limit mode

AP has been tested to achieve ~250Mbps over TCP for 1 client.

I was wondering for the following.

  1. What will be the result of disabling the airtime fairness and capping all clients (from client side) to 10mbps ? Usually capping means, dropping random packets to reduce the speed. Anyways if this dropped packet was Aired by AP it is still Airtime I think and seems poor choice, but as it is more simple it can be actually better than the other options by cutting the AP/STA communication in the initial phase of the TCP handshake.

  2. Static config isn't an option here.

  3. What beats between per-BSS dynamic config and per-BSS limit mode ?
    I think per-BSS limit mode is the round-robin everybody talks about. For every client it gives 1/25 Airtime (if 25 clients are connected) which potentially caps everyone at steady 10mbps. Or this is false logic?
    Like in this 1/25th Airtime we can have some dropped packets leading to 8-9 Mbps in a good scenario ?

Which leads me back to option 1. No Airtime fairness with everyone capped at 10mbps even 15mbps should be more steady ?
About the dynamic config there's no info how it works. I assume this can potentially bring almost all the airtime to single STA, but slow recalculations if other STAs start using the stream, leading to instability.

12 clients are MCS 15 with perfect signal, 13 clients are MCS 6 with poor-to-mid signal.
So these 13 clients, will they request more airtime ? Although 6 MCS is much greater than 20mbps. Bad & retransmitted packets are minimal when testing each STA individually.

Beacons - Well, I've set 1000ms on AP beacon Interval (10 times less). As well as on all STAs.
I was wondering to achieve AP isolation (including on ARP level) between the STAs, OR better if somebody can point out what should we have in /etc/sysctl.conf to disable ARP requests except to the AP.

Which band what channel width etc?

I am forced to use 2.4G 20/40Mhz and the STAs are N mode compatible only.

You should not assume more than half of link bandwidth in wifi. 250Mbps means you use 40MHz channels which is out of spec.

1 Like

This is not airtime fairness issue, it is qos, in style of fq(_codel) needed for normal or video class in wifi to equally split airtime between receivers. You have best chance buying ancient wifi-n dual radio enterprise class 2.4GHz mesh point which has two 2.4ghz radios. Then you can have 3 (US) or 4 (everywhere else) independent 144Mbps (/2) distribution channels in the air.
Airtime fairness would kick in if you had multiple AP-s on same channels.

Beacons - Well, I've set 1000ms on AP beacon Interval (10 times less). As well as on all STAs.

What is your experience with such a long beacon interval? According to my personal experience, many device disassociate if they do not receive beacon frames for an extended period of time. I observed this happening even if other frame exchanges occurred.

Therefore, I personally hesitate to set beacon intervals to more than 300 TUs (Time Units = 1024 µs).

Would be great to learn from your experience with a beacon interval of 1000 TUs.

1 Like

I see 1000 as the maximum safe value for me. Clients do not dissociate, usually there's entire 10 minutes by default (600 sec) for a client to be inactive and being considered for dissociation, until these 10 minutes he has to receive a beacon packet and a probe packet.
What is more difficult is to scan and find the ap. It takes 10 times longer, but not more than 30 seconds usually.
Also seems like better than -69dbm signal is needed, while at 100ms the threshold is lower.