[Make-wifi-fast] bloated ath10k

Adrian Popescu adriannnpopescu at gmail.com
Sun Feb 10 09:37:16 EST 2019


Running a wire isn't an option for devices which don't have ethernet ports.

I'll try to run some tests with flent to figure out what's happening. A
constant latency of 20-30 ms isn't a big deal. The spikes which cause
stuttering during a voice or video call are the real problem. The
stuttering may not have been caused by these spikes.

It seems that these routers don't have enough power to do traffic shaping,
NAT and to forward hundreds of mbps of data. It might be interesting to
compare the idle latency with the latency under load. I've also considered
running some tests with mac80211_hwsim. mac80211_hwsim may not provide the
option to simulate a deep buffer like the ath10k one and may not be as
relevant.



On Sun, Feb 10, 2019 at 2:38 PM Jonathan Morton <chromatix99 at gmail.com>
wrote:

> > On 10 Feb, 2019, at 2:24 pm, Adrian Popescu <adriannnpopescu at gmail.com>
> wrote:
> >
> > My attempts to use SQM and codel to reduce wifi bloat didn't seem to get
> me very far. 802.11ac seems more reliable and it seems to be more bloated.
> ath9k can go as low as 3-5 milliseconds. ath10k is usually in the 20-50
> milliseconds range (or more, based on the number of stations). I usually
> test with a single client as I don't expect latency to improve with more
> clients.
>
> Some things are unavoidable when you move to a shared, half-duplex, noisy
> medium like wifi versus a switched, full-duplex, error-free medium like
> Ethernet.
>
> If you're getting 20-50ms under load, then I think things are working
> quite well with wifi.  We can wish for better, but not long ago you could
> be looking at multiple seconds in bad cases.  At the levels you're now
> seeing, ordinary interactive protocols like DNS and HTTP will work reliably
> and quickly, and even VoIP should be able to cope; you'll likely only
> really notice a problem with online games.
>
> Ath9k has some advantages over ath10k in this area.  Its MAC is managed at
> a lower level by the driver, so we have much more control over it when
> trying to debloat.  I think we still have more control over ath10k than
> most of the alternatives.
>
> If low latency is mission critical, though - just run a wire.
>
>  - Jonathan Morton
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/make-wifi-fast/attachments/20190210/f7694ad9/attachment.html>


More information about the Make-wifi-fast mailing list