Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: David Lang <david@lang.hm>
To: dave seddon <dave.seddon.ca@gmail.com>
Cc: Jonathan Morton <chromatix99@gmail.com>,
	David Lang <david@lang.hm>,
	Cake List <cake@lists.bufferbloat.net>
Subject: [Cake] Re: help request for cake on a large network
Date: Tue, 30 Sep 2025 05:49:33 -0700 (PDT)	[thread overview]
Message-ID: <s552o40s-9o87-69rs-0415-67o993r9rp4r@ynat.uz> (raw)
In-Reply-To: <CANypexQ0_bNcOOs-_WuvGqJ1==Ye-k3an5Zuvw43Psot7Bo16A@mail.gmail.com>

dave seddon wrote:

> Agreed.
>
> I nearly replied to suggest getting Crown Castle to just provide dark fiber
> to One Wilshire and fire it up at 10GE. ( I assume any of the major
> sponsors could provide a 10ge internet link for a few days without any
> concern.)

that would be fantastic if it could be done, but in our experience, getting a 
hotel/convention center to allow a new network service to be setup is increadily 
hard.

> This way the bottle neck moves to the APs, which have a significant smaller
> number of flows each.

the user may move from one AP to another in the middle of a flow, so the shaping 
needs to move further from the APs

> The other option, if upgrading the Internets isn't an option, could be to
> use 100mbs links to the APs. This sounds counter intuitive, is essentially
> moving the bottleneck to the APs.
>
> I assume you have traffic graphs from the APs from last year? I guess none
> really exceeded 100mbs?

If they did, it wasn't by much, we only use single channels on each band on each 
AP, isn't that going to limit each radio to 56k? (we do this instead of wider 
channels so that we can reuse the channel spacially sooner)

so limiting the connection to 100m isn't going to add any noticable 
restriction/bottleneck

David Lang

>
> On Mon, Sep 29, 2025, 20:56 Jonathan Morton <chromatix99@gmail.com> 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...
>>
>> 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.
>>
>>  - Jonathan Morton
>> _______________________________________________
>> Cake mailing list -- cake@lists.bufferbloat.net
>> To unsubscribe send an email to cake-leave@lists.bufferbloat.net
>>
>

  reply	other threads:[~2025-09-30 12:49 UTC|newest]

Thread overview: 25+ 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 [this message]
2025-09-30 12:37   ` David Lang
2025-09-30 12:56     ` Sebastian Moeller
2025-09-30 13:19       ` David Lang
2025-09-30 18:00         ` Toke Høiland-Jørgensen
2025-09-30 18:45       ` Jonathan Morton
2025-10-01 20:58         ` dave seddon

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=s552o40s-9o87-69rs-0415-67o993r9rp4r@ynat.uz \
    --to=david@lang.hm \
    --cc=cake@lists.bufferbloat.net \
    --cc=chromatix99@gmail.com \
    --cc=dave.seddon.ca@gmail.com \
    /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