I have been sucked into helping stablizing the current and next releases of openwrt wifi, and it's beginning to look like many of the power, multicast, and reliability problems have all been solved, thx to the enthusiastic testing and commitment by openwrt's wonderful community, and I really hope rc6 rocks and hundreds of wifi bugs all over can be closed that were side-effects of the mess.
What I'd actually set out to do months ago was test implementing more than a few latency reducing ideas left over from the original make-wifi-fast project: https://www.youtube.com/watch?v=Rb-UnHDw02o - of note were ack-filtering, reducing the intervals announced in the beacon, reducing the codel target, l4s-style ecn, better controlling the multicast queue, and fiddling with understanding the real effects of qosify on modern wifi stacks.
The simplest of these is to try improving multiplexing behavior by reducing the maximum txop size. There's four places to do this nowadays, this is in hostapd.conf...
The simplest test is to verify that the AP chipset can use some reduced parameters, mimicking the VI queue thusly.
tx_queue_data2_aifs=1 tx_queue_data2_cwmin=7 tx_queue_data2_cwmax=15 tx_queue_data2_burst=3.0 # this is a really low value for modern ac but
This will clobber from the AP performance even more than what we are seeing today, and is undesirable for most apps. (but does it work in x chipsets? What does it look like?) - CORRECTION - I assumed this was the max txop size (5.7), in saying that, and it turned out that openwrt was already tuning it down to 2. Putting it up to 3 got a better down/up ratio. Still not the right thing but (see a few more posts below)
More interesting is observing whether or not announcing this reduced interval in the beacon is respected by the client, which should improve up/down fairness in the rrul_be test, and is probably desirable behavior for most.
wmm_ac_be_aifs=2 wmm_ac_be_cwmin=3 wmm_ac_be_cwmax=4 wmm_ac_be_txop_limit=94 # arguably we can just change this wmm_ac_be_acm=0
There are a lot of other mysterious parameters in https://w1.fi/cgit/hostap/plain/hostapd/hostapd.conf -
Now, an algorithm to do this more right (reducing the txop size in beacon announcements in response to the number of stations with data outstanding) is in the cards, with a ceiling of say, 1.1ms instead of 5.7, but first up is merely verifying that drivers and clients obey the rruls. There is also a potential impact on the ATF calculations...
Assuming that actually doesn't crash things, verifying that the VI queue is working as designed vs a vs the BE queue would be next, then merely reducing wmm_ac_be_txop_limit sanely for be.
anyway, we could get a 4-8fold reduction in latency and jitter by fiddling with these at some cost in bandwidth that those with a lot of stations would probably find acceptible. I routinely ran with 2.1ms as my outer limit on my old mesh.