[Make-wifi-fast] Where is the bloat in WiFi?

[Sebastian Moeller]

Hi Michael,

just to add another anecdotal data point on a nominal 100/40 access link (synced at 100/32, cake-shaped to 95/31, wifi currenrly ath10K @ 2.4 and 5 GHGz). The access link is the bottleneck most of the time. WiFi typically only shows up in dedicated testing by odd side-effects, like cyclic latency spikes when a station running the speedtest just starts scanning other channels (macos seems prone to do this if location services are somehow triggered), or airtime starvation, when a station (ab)uses AC_VI or AC_VO and the others do not manage to squeeze packets in... 
	Other than that even without the latest wifi drivers (router still on OpenWrt 19.07.4) WiFi mostly works without nasty latency issues, but I have a number of machines connected via wires, so already behaviorally try to keep WiFi only lightly loaded. Not sure whether you where looking for reports like this though. And I have to admit my family is mostly latency tolerant, at least to the lever we encounter it, not sure how that would look without cake (I currently run a speedtest automatically every two hours from the router, but from just using the network I can not tell when these run, of even fully loaded cake keeps the access link quite usable, hurrah for cake's per internal IP address fairness modes, but that is orthogonal to your wifi question).

Best Regards
        Sebastian

P.S.: Do to typical end-user access link asymmetry, I agree with Toke, that WiFi bufferbloat will mostly be seen in the download direction, which is actually not bad, as that means that an air-time fair AP can help a lot. For egress, that is going to be much harder, to sufficiently coordinate all stations to behave well, short of tracking all stations air time usage and reprogram the airtime access parameters individually for each station, but I digress)

> On Oct 6, 2020, at 14:15, Michael Welzl <michawe at ifi.uio.no> wrote:
> 
> Hi, and thanks for a quick answer!
> 
> But, it's not quite what I was looking for.... see below:
> 
>> On 6 Oct 2020, at 13:47, Toke Høiland-Jørgensen <toke at toke.dk> wrote:
>> 
>> Michael Welzl <michawe at ifi.uio.no> writes:
>> 
>>> Hi all,
>>> 
>>> A simple question to y'all who spent so much time on Cake and things
>>> ... in a household using WiFi, which buffer is usually bloated? Where
>>> does the latency really come from?
>>> 
>>> Is it:
>>> 1. the access point's downlink queue, feeding into the WiFi network,
>> 
>> This we mostly fixed, but only if you're on a recent OpenWrt with the
>> right WiFi drivers.
> 
> Well okay... I was curious about where the bottleneck is. I can translate my question into: "if Cake is installed everywhere, where does it have the most work to do?".
> 
> 
>> Otherwise, this is a major source of latency *if*
>> the WiFi link is faster than the downlink from the internet.
> 
> Huh? Slower, you mean?
> 
> 
>> This
>> depends on both the internet connection and the current rate each WiFi
>> station operates at, so it can vary wildly, and on very short time
>> scales.
> 
> Sure... I was asking for the "if" in your statement above - since this is an operationally-oriented list: what do people see? What is the more common case?
> 
> 
>>> 2. the modem's downlink queue, feeding into the access point,
>> 
>> If your internet (downlink) connection is slower than your WiFi link,
>> this is where you'll get the queueing.
> 
> Yes sure  :-)     see above: I wanted to know what the more common case is, in households that people on this list have dealt with.
> 
> 
>>> 3. the modem's uplink queue,
>> 
>> As above, but in the other direction - but as uplinks tend to be
>> asymmetric, this direction is often more of a problem.
>> 
>>> 4. the access point's uplink queue towards the modem   (hm, that seems
>>> silly, surely the AP-modem connection is fast... so perhaps, instead:
>>> the queue in the host, as it wants to send data towards the access
>>> point)
>> 
>> Yeah, that would be in the host; but host drivers can suffer from severe
>> bufferbloat as well, especially as rates drop (since the buffers are
>> often tuned for the maximum throughput the device can deliver in
>> best-case signal conditions).
>> 
>>> or is it a combination of these?
>> 
>> Usually it's a combination; especially since the WiFi capacity varies
>> wildly with signal conditions (as devices move around relative to the
>> AP), general link usage (more devices active mean less available
>> capacity for each device, exacerbated by airtime unfairness), and
>> interference. Also there are things like excessive retries causing HoL
>> blocking.
> 
> Man, what an academic answer!    Makes me think you have a PhD, or something!  What *theoretically* can happen is not what I was fishing for   :-D
> 
> 
>>> I guess that, with openwrt, Cake is operating on the queue that's
>>> feeding the wifi network, as the modem's queue is out of its
>>> control... so: is this where the bottleneck usually is?
>> 
>> It certainly used to be; but as uplink connection speeds improve, the
>> bottleneck moves to the WiFi link.
> 
> Yessss, that's why I was asking....
> 
> 
>> The extent to which this happens
>> depends on where you are in the world; personally I've been bottlenecked
>> on the WiFi link ever since I got a fibre upstream (and with 802.11ax
>> rates maxing at >1Gbps, maybe that'll change again?).
> 
> THIS is what I was after   :)   one data point, cool - so far, so good...
> 
> Cheers,
> Michael
> 
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast