Re: [Make-wifi-fast] bloated ath10k, extra latency at lower rates?

[Dave Taht <dave@taht.net>]

Toke Høiland-Jørgensen <toke@redhat.com> writes:

> Jon Pike <jonpike54@gmail.com> writes:
>
>> This might be a good time to mention an observation I've seen that's
>> related to this.
>>
>> I have noticed about the same as reported, 10's down to single digits
>> on my ath9k radios, and a similar 20ms-30ms on the ath10k's. Thats at
>> high signal strength and the highest data rates. But, I've also
>> noticed that it's different if you get farther out in range, and you
>> end up on the slower signaling speeds.
>>
>> Under those conditions, I'm seeing the ath9k latency rise only
>> slightly, maybe to 20-30ms, while the ath10k will go up more
>> drastically, like a continuous 100-150ms or more. Been meaning to
>> mention it to see if it should be considered as an issue.

The C7 has an older version of firmware. It would be interesting to
benchmark the -ct version of the firmware. 

>
> Well yeah, I guess it should. To answer both you and Adrian: The
> debloating of ath10k is only partial currently. It uses the intermediate
> queueing system, but it still has quite a bit of buffering in the
> firmware, which is not controlled by the driver. The actual latency
> induced by this buffering varies by firmware version; but it sounds
> quite likely that it would be worse as the rates drop.
>
> The fix for this is to control the queue length in the firmware, similar
> to what BQL does for Ethernet drivers. The ChromeOS people at Google
> already has this as a patch for ath10k, which we are planning to port
> upstream to live inside mac80211 on top of the airtime fairness
> mechanism that is in the process of being merged.
>
> So there is some hope that this situation will improve in the future :)
>
> -Toke
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast