From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [45.145.95.4]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id DEF7A3B29E for ; Tue, 6 Oct 2020 08:44:29 -0400 (EDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1601988268; bh=vz3g3sGM21vZoHhvoob+5r+CrWoZx9LnYGfRA+TTtw8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=NHRa6SAWsy9YcrpDY0KKPeU8OWwQ/rlyRLug/lFd14j1fE3lXPVJK0LAi34iXXcTT cweHJh4qE+rCBGWOekjbAi2D8p1fTpZYV9hF0o0EvzBALWYWFxvCa76aGc/reETQzW RSLl8QnR6emoKZMmb12k0GJoDSrfGYE/0hvfmoFQCbK5/worl/hji9VAIbGjX00C+E SD6m03UJBOY6VPu1Cv6miiyOX5r6tNM9zp2I8v8ejYTc+UsnfX/cnZfzCblcPW3QEH pcB/imvY/oBWyIkWdOf3vO6iJhNOweqNy14LwrXotiLoZ5jACC1+DNPkkku530WM5q omhmzwURBujxQ== To: Michael Welzl Cc: make-wifi-fast@lists.bufferbloat.net In-Reply-To: References: <87d01vfue4.fsf@toke.dk> Date: Tue, 06 Oct 2020 14:44:27 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87a6wzfrro.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 12:44:30 -0000 Michael Welzl 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=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. > > 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