From: Michael Welzl <michawe@ifi.uio.no>
To: "Toke Høiland-Jørgensen" <toke@toke.dk>
Cc: make-wifi-fast@lists.bufferbloat.net
Subject: Re: [Make-wifi-fast] Where is the bloat in WiFi?
Date: Tue, 6 Oct 2020 15:24:26 +0200 [thread overview]
Message-ID: <E25B250D-462A-4F8F-BBD5-11B8DACC9E6E@ifi.uio.no> (raw)
In-Reply-To: <87a6wzfrro.fsf@toke.dk>
Thanks a lot - just the info I was looking for (also from others who have responded in the meantime, thanks!)
> On 6 Oct 2020, at 14:44, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>
> Michael Welzl <michawe@ifi.uio.no> writes:
>
>> 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@toke.dk> wrote:
>>>
>>> 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.
>>
>> 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?".
>
> Well, CAKE only runs on the upstream link, so that's where it does its
> work. The software shaper model doesn't really work that well on WiFi,
> so we generally encourage people to just run fixed drivers there
> instead. That being said I have heard of one or two WiFi deployments
> where that was not an option, and where CAKE was used as a shaper
> instead. This was for a fixed WiFi backhaul, though, and even so they
> had to set the shaper quite a lot lower than the max bandwidth to get
> reliable performance.
>
>>> Otherwise, this is a major source of latency *if*
>>> the WiFi link is faster than the downlink from the internet.
>>
>> Huh? Slower, you mean?
>
> No, if the WiFi link is faster, the upstream link becomes the bottleneck
> and CAKE has work to do :)
>
>>> 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?
>
> Right, well as you can probably tell that might not have been entirely
> clear from your initial post ;)
>
>>> 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...
>
> Ah, you're after anecdotes - well why didn't you say so? ;)
>
> In that case I'll add that my own connection is the only one I've come
> across where the WiFi link is *never* the bottleneck. In Denmark we are
> finally (slowly) getting out of the dark ages as far as fibre
> deployments are concerned, but most operators will sell connections
> capped at 100Mbps or 250Mbps, which is still less than the throughout of
> a 802.11ac link with good signal conditions (my phone consistently gets
> ~250-350 Mbps on a speedtest.net run).
>
> DSL connections tend to have awful latency, and are still quite common,
> but they are pretty easy to fix with CAKE. Cable connections likewise,
> or so is my impression (those are not so common around these parts).
>
> The worst are definitely LTE/mobile broadband connections. Wildly
> varying link speeds, and awful over-buffering; so you really have to
> clamp them down to get anything useful out of CAKE.
>
> -Toke
next prev parent reply other threads:[~2020-10-06 13:24 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
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 [this message]
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=E25B250D-462A-4F8F-BBD5-11B8DACC9E6E@ifi.uio.no \
--to=michawe@ifi.uio.no \
--cc=make-wifi-fast@lists.bufferbloat.net \
--cc=toke@toke.dk \
/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