From: Sebastian Moeller <moeller0@gmx.de>
To: David Lang <david@lang.hm>
Cc: Jonathan Morton <chromatix99@gmail.com>, cake@lists.bufferbloat.net
Subject: [Cake] Re: help request for cake on a large network
Date: Tue, 30 Sep 2025 14:56:40 +0200 [thread overview]
Message-ID: <FA76869A-F4A3-4C70-8F15-57E4168DAC71@gmx.de> (raw)
In-Reply-To: <n21672r7-056q-ppo6-rpno-139os0o3154r@ynat.uz>
Hi David,
> On 30. Sep 2025, at 14:37, David Lang <david@lang.hm> wrote:
>
> Jonathan Morton wrote:
>
>> On Sunday, 28 September 2025, David Lang wrote:
>>> I'm starting to prepare for the next Scale conference and we are switching from
>>> Juniper routers to Linux routers. This gives me the ability to implement cake.
>>>
>>> One problem we have is classes that tell everyone 'go download this' that
>>> trigger hundreds of people to hammer the network at the same time (this is both
>>> a wifi and a network bandwidth issue, wifi is being worked on)
>>>
>>> The network is pretty flat, a couple of subnets each on ipv4 and ipv6.
>>>
>>> Any suggestions on how to configure cake for this sort of environment where
>>> there are so many devices?
>>
>> So far as Cake is concerned, the normal setup should work fine even under stress conditions. If there are too many simultaneous flows to achieve full flow isolation, it degrades gracefully to statistical multiplexing, and you still have the AQM working to keep everything responsive. Or rather, a thousand AQMs working in parallel...
>
> what would need to be done to increase resources to allow for full isolation of more flows?
I believe editing net/sched/sch_cake.c and increase the number of CAKE_QUEUES:
#define CAKE_QUEUES (1024)
to something larger...
however I do not know what a realistic maximum is... and IIRC cake will search through this repeatedly, 1024 is one full memory page (4k pages) anything larger will require multiple pages (likely as single contiguous allocation). I remember dimmly someone ages ago playing with this and finding that the number can be increased, but not arbitrarily so at least on your typical somewhat memory-poor router. But that should be easy to figure out.
Mind you, given Toke's reminder on the small number of concurrently active flows and cake's 8-way associativity, maybe this is not necessary at all.
>
>> Of course, this only matters when Cake is set up to be the bottleneck. If wifi is the bottleneck, you'll want a wifi stack with integrated fq_codel, which I believe still applies to only some hardware since it needs to manage the MAC queue which some devices don't expose. This has the extra smarts needed to adapt gracefully to wifi's foibles, and might already be enough to convert an effectively nonfunctional wifi into one that feels, if not fast, then at least reliable.
>
> I am doing everything I can to eliminate wifi as the bottleneck and overload our uplink ;-p
>
> mostly the wifi bottleneck is being eliminated by having lots of separate APs for people to connect to.
>
> David Lang
> _______________________________________________
> Cake mailing list -- cake@lists.bufferbloat.net
> To unsubscribe send an email to cake-leave@lists.bufferbloat.net
next prev parent reply other threads:[~2025-09-30 12:56 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-28 11:06 [Cake] " David Lang
2025-09-28 12:10 ` [Cake] " Sebastian Moeller
2025-09-28 12:17 ` David Lang
2025-09-30 9:04 ` Toke Høiland-Jørgensen
[not found] ` <837EA4ED-26D3-4D83-84D9-5C0C75CFB80D@gmx.de>
2025-09-30 9:23 ` Toke Høiland-Jørgensen
2025-09-30 12:44 ` David Lang
2025-09-28 12:12 ` Jaap de Vos
2025-09-28 12:38 ` David Lang
2025-09-28 12:56 ` Frantisek Borsik
2025-09-28 17:07 ` dave seddon
2025-09-28 17:26 ` David Lang
2025-09-30 5:18 ` Jonathan Morton
2025-09-30 6:09 ` Sebastian Moeller
2025-09-30 8:59 ` Jonathan Morton
2025-09-30 9:00 ` Sebastian Moeller
2025-09-30 12:55 ` David Lang
2025-09-30 3:55 ` Jonathan Morton
2025-09-30 4:30 ` dave seddon
2025-09-30 12:49 ` David Lang
2025-09-30 12:37 ` David Lang
2025-09-30 12:56 ` Sebastian Moeller [this message]
2025-09-30 13:19 ` David Lang
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/cake.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=FA76869A-F4A3-4C70-8F15-57E4168DAC71@gmx.de \
--to=moeller0@gmx.de \
--cc=cake@lists.bufferbloat.net \
--cc=chromatix99@gmail.com \
--cc=david@lang.hm \
/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