[Make-wifi-fast] less latency, more filling... for wifi

[Dave Taht <dave.taht@gmail.com>]

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,
seems useful.

* Merging acs when sane to do so

sane aggregation in general works better than prioritizing  does, as
shown in ending the anomaly.

-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619