Hi Toke,
> On Nov 23, 2021, at 11:39, Toke Høiland-Jørgensen <t...@toke.dk> wrote:
>
> Sebastian Moeller <moell...@gmx.de> writes:
>
>> Hi Dave,
>>
>> On 23 November 2021 08:32:06 CET, Dave Taht <dave.t...@gmail.com> wrote:
>>> The context of my question is basically this:
>>>
>>> Is cake baked? Is it done?
>>
>> How about per MAC address fairness (useful for ISPs and to treat
>> IPv4/6 equally)?
>>
>> How about configurable number of queues (again helpful for ISPs)?
>
> FWIW I don't think CAKE is the right thing for ISPs, except in a
> deployment where there's a single CAKE instance per customer.
Fair point. My other reason for wanting to expose this is to allow easier
experimentation, but I can be expected to build from modified sources so that
is rather weak.
> For
> anything else (i.e., a single shaper that handles multiple customers),
> you really need hierarchical policy enforcement like in a traditional
> HTB configuration. And retrofitting this on top of CAKE is going to
> conflict with the existing functionality, so it probably has to be a
> separate qdisc anyway.
I had sort of ignored that ISPs generally do not offer, fair sharing of
a link's capacity between all connected users ;)
>
>> IMHO cake works pretty well, with the biggest issue being its CPU
>> demands. As far as I understand however, that is caused by the shaper
>> component and there low latency and throughput are in direct
>> competition, if we want to lower the CPU latency demands we need to
>> allow for bigger buffers that keep the link busy even if cake itself
>> is not scheduled as precisely as we would desire or as e.g. BQL
>> requires.
>
> Yes, as link speed increases, batching needs to increase to keep up.
Yes, all the way through the stack.
> This does not *have* to impact latency, as the faster link should keep
> the granularity constant in the time domain.
Nit-pick: any batching impacts latency compared to perfect just in time
processing, just some impact can easily be accepted/tolerated ;)
> So experimenting with doing
> this dynamically in CAKE might be worthwhile, but probably not trivial.
We tried to do the same for HTB/fq_codel and testing was a bit
inconclusive (then again, affected users where not to dedicated in testing)
> And either way, CAKE is still going to be limited by being single core
> only, and fixing that requires some serious surgery that I seem to
> recall looking into and giving up at some point :(
That is sad, and pretty much rules out that I could make some progress
in that direction. The next level is shaping at ~1Gbps, even though faster
access links become available, like 8.5/10 Gbps (XGS-PON is nominally 10G, but
after FEC only ~8.5 Gbps actually are usable) or for a lucky few even 25 Gbps
...
Regards
Sebastian
>
> -Toke
_______________________________________________
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake
