From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 D1FE03B29E for ; Tue, 6 Oct 2020 08:44:07 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1601988245; bh=KVzxMYwe7uNzA3TyFv58+86jSE8tc2K7fQQMPTmOJbo=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=LQ4BfozUxFHws2e4dpNF3gc9ZjGl6P2+Z7DM3FIdjdGM8Xp7areBDyLre9lc39z8s VDhKQsLeyEy3ldrmTXZE2zH4EvCUhl3rN2Uru6GuYHBE/3tIniU3YSfkpDyauTEf43 y1dwhvqJypNpz/+2FNlotorK+zCMCUIkE+C2tWrc= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [172.16.12.100] ([134.76.241.253]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MnJhU-1kpAvJ17Ei-00jKZ8; Tue, 06 Oct 2020 14:44:05 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) From: Sebastian Moeller In-Reply-To: Date: Tue, 6 Oct 2020 14:44:02 +0200 Cc: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , make-wifi-fast@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <7BFF2AA7-AB58-46D2-91F2-9BEE2D34AA28@gmx.de> References: <87d01vfue4.fsf@toke.dk> To: Michael Welzl X-Mailer: Apple Mail (2.3445.104.17) X-Provags-ID: V03:K1:v67yzx6e7W/iFJAkLMUfjbzttuI4dTyW/16RKcTEWLI9Bf7Qp// IK/sFt6N5umC6JT869CGskqTUmgTgyrIoCUDudO2Tud0eC2hXkrWWnxBkEVtkjTvyIxPVVv qKjzpVkOMSQgTQn2qP5bALmWEg9l6bVlBX3o/NXOrtt9hX/lsscm12sNBdGO7g7WUNL33uQ Axge6CtNA5Y1ur8hVPplQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:iRwXiyD0bYk=:S4YV+9bkNw8507vweS5i4D JL+uXz8tChy1dHk6rErGINWUrVfmgtKBwnZYw6PKVtRm/p50awD7Dm8TUyh7rfIGuaOHJJy2K U1DpmdiKXzXrSS9I+qIYdYmXnpZyrQTKi3/eFPObrobZyDi3XNw+tfeLZWf0UctxDGR1zZUdI wLgTbw3Cp2yvPG7HNc4AnlTj0ZmNyLOK/78C5l39+BjKNV7I6mDOrnDInqWLboPFvOd+Tr8v5 9bcbfDig1MvWv+HzneeKGW5+yW1zrgGq+Q9NQveKRTezW7c/cD3eTI6U/IewaAOEZRK8DTaEC lx8+mlV0osgVUEftHu9Q1BczS7fju9M1E06xeQt/AiHdnjxPJJSfr/cO92xKWEIDN8o8/RNZ/ 9foKKTKCuKNrcXUbNqG9ATVxphfg8uwFxcwC3RJ17LaJ8L+GF13eOip8iqBf4lY2XtDuzvYyh Oq98jBMpE93euYSisSiM1fh/eFEdkj+s8DxJeckspLaimHhIcP1hwctd2KTAsG0w6nlO005wO NF6LV+NdCBk2FJ/0p/qOyNJaTontkfjC5w1/Zly9pyEwN67O6l/87+9UrhJmeRSR/Ov8iOseV Mzc4LqMo+Zm0sJU3wl6IS+3o1HYI9nFhOsX75yyJTNqE8Y6sipOP/2XQLbzpTEKpYWmD16kCt WY3LDuzles8ii7KIaVYJpaJflrW/LbTO3guk+Z4951VjaWq92m3RcMpB3jRE7GblCfiHitLBT WXy6Jf5Dzc7UJW6EOWeE0s/n4Wr41e19WFGNHM8Ou5JT0gbG61c/L99AGn6l13t7syLpE84sS WtetgTQp8HVDroaH+gQ0P/EtbMni18VikMroqbJ6vPhREqFROJGh2GphDwLfwevGF1bJkp9KM ap/CVN3/S4/ojK/Tp1QbOUriOVn8Fk7GSCyNlsDfWbcJVHsN9ijVq58pAFBvajrfSgorb8etL SyQk/s59KaA5QXuGGouWkFpOO0NssEh+X8NdeCKGzcYmHpX4Ip1A/O1XTFP7xZuWx7PY0FC12 uVWb6e03x5CWCYcrxb/eaeFIbKLXzGTrAC7RhL4GnKfLuCIn1OB1q2lmsRVuCb/XkZmGpupwE z92KsEEqNe/r1kLiT3djB+OlWGeS8zd5eVZcm7BTRgPkERuzKuPjq00kqnUMXsVqjHENEwqrE TJnT/gNaQDhDsx67lav80rvB3NkzY7hvYfyvAmZiwgmuYT8fbZXcWkxtfws9mk9F9/M+jr9pJ q3KhJntSUhprtoQ2i 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:08 -0000 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...=20 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 wrote: >=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 >=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 >=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 >=20 >>> 2. the modem's downlink queue, feeding into the access point, >>=20 >> If your internet (downlink) connection is slower than your WiFi link, >> this is where you'll get the queueing. >=20 > Yes sure :-) see above: I wanted to know what the more common = case is, in households that people on this list have dealt with. >=20 >=20 >>> 3. the modem's uplink queue, >>=20 >> As above, but in the other direction - but as uplinks tend to be >> asymmetric, this direction is often more of a problem. >>=20 >>> 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) >>=20 >> 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). >>=20 >>> or is it a combination of these? >>=20 >> 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. >=20 > 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 >=20 >=20 >>> 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? >>=20 >> It certainly used to be; but as uplink connection speeds improve, the >> bottleneck moves to the WiFi link. >=20 > Yessss, that's why I was asking.... >=20 >=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 > Cheers, > Michael >=20 > _______________________________________________ > Make-wifi-fast mailing list > Make-wifi-fast@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast