[Make-wifi-fast] less latency, more filling... for wifi
dave.taht at gmail.com
Mon Oct 9 16:13:18 EDT 2017
There were five ideas I'd wanted to pursue at some point. I''m not
presently on linux-wireless, nor do I have time to pay attention right
now - but I'm enjoying that thread passively.
To get those ideas "out there" again:
* adding a fixed length fq'd queue for multicast.
* Reducing retransmits at low rates
See the recent paper:
"Resolving Bufferbloat in TCP Communication over IEEE 802.11 n WLAN by
Reducing MAC Retransmission Limit at Low Data Rate" (I'd paste a link
but for some reason that doesn't work well)
Even with their simple bi-modal model it worked pretty well.
It also reduces contention with "bad" stations more automagically.
* Less buffering at the driver.
Presently (ath9k) there are two-three aggregates stacked up at the driver.
With a good estimate for how long it will take to service one, forming
another within that deadline seems feasible, so you only need to have
one in the hardware itself.
Simple example: you have data in the hardware projected to take a
minimum of 4ms to transmit. Don't form a new aggregate and submit it
to the hardware for 3.5ms.
I know full well that a "good" estimate is hard, and things like
mu-mimo complicate things. Still, I'd like to get below 20ms of
latency within the driver, and this is one way to get there.
* Reducing the size of a txop under contention
if you have 5 stations getting blasted away at 5ms each, and one that
only wants 1ms worth of traffic, "soon", temporarily reducing the size
of the txop for everybody so you can service more stations faster,
* Merging acs when sane to do so
sane aggregation in general works better than prioritizing does, as
shown in ending the anomaly.
CEO, TekLibre, LLC
More information about the Make-wifi-fast