From: "Toke Høiland-Jørgensen" <toke@toke.dk>
To: Michael Welzl <michawe@ifi.uio.no>, make-wifi-fast@lists.bufferbloat.net
Subject: Re: [Make-wifi-fast] Where is the bloat in WiFi?
Date: Tue, 06 Oct 2020 13:47:47 +0200 [thread overview]
Message-ID: <87d01vfue4.fsf@toke.dk> (raw)
In-Reply-To: <D825F3B5-4190-4036-AA5B-598C004A4412@ifi.uio.no>
Michael Welzl <michawe@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. Otherwise, this is a major source of latency *if*
the WiFi link is faster than the downlink from the internet. 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.
> 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.
> 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.
> 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. 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?).
-Toke
next prev parent reply other threads:[~2020-10-06 11:47 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-06 11:25 Michael Welzl
2020-10-06 11:47 ` Toke Høiland-Jørgensen [this message]
2020-10-06 12:15 ` Michael Welzl
2020-10-06 12:44 ` Sebastian Moeller
2020-10-06 12:44 ` Toke Høiland-Jørgensen
2020-10-06 13:21 ` Jonathan Morton
2020-10-06 13:24 ` Michael Welzl
2020-10-07 0:10 ` Bob McMahon
2020-10-06 13:09 ` Luca Muscariello
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/make-wifi-fast.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87d01vfue4.fsf@toke.dk \
--to=toke@toke.dk \
--cc=make-wifi-fast@lists.bufferbloat.net \
--cc=michawe@ifi.uio.no \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox