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

[Dave Taht]

Pete Heist <peteheist at gmail.com> writes:

>> On Oct 9, 2017, at 1:13 PM, Dave Taht <dave.taht at gmail.com> wrote:
>> 
>> * 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.
>
> For what it’s worth, I’d love to see this. One of the few arguments for doing
> soft rate limiting with point-to-point WiFi is that it’s still possible, when
> rates are stable, to achieve lower latency under load than with the new ath9k
> driver. It would be nice to see that argument disappear. Solid...

I had some hope that perhaps the powersave timing architecture could be
leveraged (somehow), within the new API (somehow), to starve the ath9k
driver this way (someday).

>
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast