From: Sebastian Moeller <moeller0@gmx.de>
To: bloat@lists.bufferbloat.net, Tom Henderson <tomh@tomh.org>,
Daniel Sterling <sterling.daniel@gmail.com>,
davecb@spamcop.net
Cc: Jonathan Morton <chromatix99@gmail.com>,
"dave.collier-brown@indexexchange.com"
<dave.collier-brown@indexexchange.com>,
bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] How about a topical LWN article on demonstrating the real-world goodness of CAKE?
Date: Mon, 10 Aug 2020 17:34:09 +0200 [thread overview]
Message-ID: <87878C8E-88D6-4218-A3D9-1CAE99CB1B59@gmx.de> (raw)
In-Reply-To: <d23ef628-8109-f0b2-526e-cd21f25ca5c8@tomh.org>
Hi Tom,
On 10 August 2020 17:08:49 CEST, Tom Henderson <tomh@tomh.org> wrote:
>
>> so after much tweaking, I've got cake set to 40mbit down, 20mbit up,
>> enforced by two cakes (one for each NIC). that's fairly low --
>
>Thanks for sharing this configuration experience, but it leads me back
>to a question I have about best current practice for deployment. Can
>CAKE/SQM handle dynamic Wi-Fi bandwidth due to Wi-Fi rate control
>selecting lower MCS to increase range, or does it rely on first getting
>
>the Wi-Fi deployed so that it has strong signal everywhere, and then
>finding a CAKE shaping rate that shaves off a few Mb/s from the highest
>
>capacity MCS so that the bottleneck always lands on the CAKE AQM? It
>seems like the deployment that you shared with a separate router will
>require a predictable Wi-Fi rate, but I am wondering more about the
>case
>in which CAKE is deployed on the AP.
>
>- Tom
No, neither cake nor SQM can deal all too well with variable rate links, if we talk about link rate variations in the second to second range. But in OpenWrt both the ath9k and the ath10k WiFi drivers gained airtime fairness modes, which do a pretty good job at keeping link sharing fair and WiFi bufferbloat low.
The issue here is not really that closely related to cake or sqm, but that WiFi without AQL (airtime queueing limits, analog to wired Ethernet's byte queue limits) does not give the required pushback for an upstream qdisc to keep the WiFi queues at an acceptable/reasonable size and it also does not really offer a reliable fast estimator of achievable rate, as far as I can tell.
The current best practice seems to be to instantiate cake/SQM on a reasonably fixed rate wan link and select WiFi cards/socs that offer decent airtime fairness.
Works pretty well in practice...
Best regards
Sebastian
>
>_______________________________________________
>Bloat mailing list
>Bloat@lists.bufferbloat.net
>https://lists.bufferbloat.net/listinfo/bloat
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
next prev parent reply other threads:[~2020-08-10 15:34 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-09 18:27 David Collier-Brown
2020-08-09 19:18 ` Tom Henderson
2020-08-09 21:35 ` Jonathan Morton
2020-08-10 12:57 ` David Collier-Brown
2020-08-10 14:00 ` Daniel Sterling
2020-08-10 15:08 ` Tom Henderson
2020-08-10 15:34 ` Sebastian Moeller [this message]
2020-08-10 15:57 ` Jonathan Morton
2020-08-10 16:04 ` Tom Henderson
2020-08-11 12:43 ` Daniel Sterling
2020-08-11 13:57 ` Kenneth Porter
[not found] ` <D8B6D86243E4539BBA58E32C@172.27.17.193>
2020-08-11 14:09 ` Daniel Sterling
2020-08-11 14:11 ` Daniel Sterling
2020-08-11 16:19 ` Kenneth Porter
2020-08-10 17:58 ` Jonathan Foulkes
2020-08-10 19:13 ` Carlos R. Pasqualini
2020-08-10 20:28 ` Dave Collier-Brown
2020-08-11 12:41 ` Michael Yartys
2020-08-10 14:16 ` [Bloat] Sidebar to "How about a topical LWN article on demonstrating the real-world goodness of CAKE?" David Collier-Brown
2020-08-11 15:48 ` [Bloat] How about a topical LWN article on demonstrating the real-world goodness of CAKE? Simon Barber
2020-09-05 18:52 ` Dave Taht
2020-09-05 20:35 ` Dave Collier-Brown
2020-09-07 9:23 ` Toke Høiland-Jørgensen
2020-09-07 11:33 ` Dave Collier-Brown
2020-09-07 17:20 ` David Collier-Brown
2020-09-08 15:43 ` Dave Taht
2020-09-08 16:48 ` Matt Mathis
2020-09-08 17:09 ` Jonathan Morton
2020-09-10 15:08 ` Anthony Minessale II
2020-09-10 16:52 ` Dave Collier-Brown
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/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87878C8E-88D6-4218-A3D9-1CAE99CB1B59@gmx.de \
--to=moeller0@gmx.de \
--cc=bloat@lists.bufferbloat.net \
--cc=chromatix99@gmail.com \
--cc=dave.collier-brown@indexexchange.com \
--cc=davecb@spamcop.net \
--cc=sterling.daniel@gmail.com \
--cc=tomh@tomh.org \
/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