From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id E3A8F3B29E for ; Tue, 6 Oct 2020 09:24:28 -0400 (EDT) Received: from mail-mx10.uio.no ([129.240.10.27]) by mail-out01.uio.no with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93.0.4) (envelope-from ) id 1kPmx9-0002Qh-Vb; Tue, 06 Oct 2020 15:24:27 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx10.uio.no with esmtpsa (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.93.0.4) (envelope-from ) id 1kPmx8-000DZ6-Vr; Tue, 06 Oct 2020 15:24:27 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Michael Welzl In-Reply-To: <87a6wzfrro.fsf@toke.dk> Date: Tue, 6 Oct 2020 15:24:26 +0200 Cc: make-wifi-fast@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: References: <87d01vfue4.fsf@toke.dk> <87a6wzfrro.fsf@toke.dk> To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= X-Mailer: Apple Mail (2.3445.9.1) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx10.uio.no: 129.240.68.135 is neither permitted nor denied by domain of ifi.uio.no) client-ip=129.240.68.135; envelope-from=michawe@ifi.uio.no; helo=boomerang.ifi.uio.no; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.009, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: FA5D7277FD74CAFCB95F33E38EBDBB73EA333E9C Subject: Re: [Make-wifi-fast] Where is the bloat in WiFi? X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2020 13:24:29 -0000 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=C3=B8iland-J=C3=B8rgensen = wrote: >=20 > Michael Welzl writes: >=20 >> Hi, and thanks for a quick answer! >>=20 >> But, it's not quite what I was looking for.... see below: >>=20 >>> On 6 Oct 2020, at 13:47, Toke H=C3=B8iland-J=C3=B8rgensen = wrote: >>>=20 >>> Michael Welzl writes: >>>=20 >>>> Hi all, >>>>=20 >>>> 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? >>>>=20 >>>> Is it: >>>> 1. the access point's downlink queue, feeding into the WiFi = network, >>>=20 >>> This we mostly fixed, but only if you're on a recent OpenWrt with = the >>> right WiFi drivers. >>=20 >> 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?". >=20 > 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. >=20 >>> Otherwise, this is a major source of latency *if* >>> the WiFi link is faster than the downlink from the internet. >>=20 >> Huh? Slower, you mean? >=20 > No, if the WiFi link is faster, the upstream link becomes the = bottleneck > and CAKE has work to do :) >=20 >>> 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. >>=20 >> 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? >=20 > Right, well as you can probably tell that might not have been entirely > clear from your initial post ;) >=20 >>> 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?). >>=20 >> THIS is what I was after :) one data point, cool - so far, so good... >=20 > Ah, you're after anecdotes - well why didn't you say so? ;) >=20 > 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). >=20 > 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). >=20 > 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. >=20 > -Toke