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

Toke Høiland-Jørgensen toke at redhat.com
Sun Feb 10 15:30:44 EST 2019

Jon Pike <jonpike54 at 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.

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 :)


More information about the Make-wifi-fast mailing list