Airtime fairness by hostapd

Hello,
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.

Also:
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.

Finally:
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.