Re: [Make-wifi-fast] Flent results for point-to-point Wi-Fi on LEDE/OM2P-HS available

[Pete Heist <peteheist@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2303 bytes --]


> On Feb 9, 2017, at 3:44 PM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> 
> Pete Heist <peteheist@gmail.com> writes:
> 
>> I’ll mention one example I noticed of the kind of adjustment that
>> probably can’t be done from the qdisc layer today. On page 3 from
>> http://pollere.net/Pdfdocs/noteburstymacs.pdf:
>> 
>> "In addition to increasing the interval by the waiting delay s,
>> another adjustment might be useful for certain kinds of bursty MACs.
>> If the MAC is a request-and-grant type, as wifi in infrastructure
>> mode, cable modems and some satellite modems, the allocation of bytes
>> or packets that can be sent during each transmission slot is generally
>> known at the beginning of transmission and may vary for each
>> transmission slot. In that case, it MAY be useful to use that value
>> instead of the MTU value to reset first_above_time_."
> 
> Yeah, we've had this issue with CoDel when the per-station WiFi rate
> drops too low (this is a function of both signal quality and number of
> stations). As a temporary fix, I just fiddled with the target until
> CoDel stopped being too aggressive, but that is not a proper solution,
> and so has not been upstreamed. I'm planning to get back around to
> fixing that properly at some point... Problem is that it is not always
> the case that "the allocation of bytes or packets that can be sent
> during each transmission slot is generally known". For ath9k we could
> get at this information at dequeue time, but for ath10k, only the
> firmware knows ahead of time...
> 
> -Toke

Interesting, I hope there’s a solution. Here are the fixed MCS level results I saw yesterday:

http://www.drhleny.cz/bufferbloat/mcstmp/mcs_latency.png <http://www.drhleny.cz/bufferbloat/mcstmp/mcs_latency.png>

http://www.drhleny.cz/bufferbloat/mcstmp/mcs_throughput.png <http://www.drhleny.cz/bufferbloat/mcstmp/mcs_throughput.png>

in case anything can be seen in it related to this. I noticed that for the ath9k driver CoDel latency maxed out at 45 ms at around MCS 10, and didn’t get any higher down to MCS 8.

Overall, the CoDel / Cake algorithms seem to keep rrul latency much lower than sfq at lower bitrates, but the differences are smaller at higher bitrates. More results later...

Pete


[-- Attachment #2: Type: text/html, Size: 3490 bytes --]