Re: [Cake] [CAKE] Rate is much lower than expected - CPU load is higher than expected

[Sebastian Moeller <moeller0@gmx.de>]

Hi Jonathan,

> On Jun 23, 2020, at 17:21, Jonathan Morton <chromatix99@gmail.com> wrote:
> 
>> On 23 Jun, 2020, at 5:41 pm, Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>> 
>> Right, well if you're not running out of CPU I guess it could be a
>> timing issue. The CAKE shaper relies on accurate timestamps and the
>> qdisc watchdog timer to schedule the transmission of packets. A loaded
>> system can simply miss deadlines, which would be consistent with the
>> behaviour you're seeing.
>> 
>> In fact, when looking into this a bit more, I came across this commit
>> that seemed to observe the same behaviour in sch_fq:
>> https://git.kernel.org/torvalds/c/fefa569a9d4b
>> 
>> So I guess we could try to do something similar in CAKE.
> 
> Actually, we already do.  The first version of Cake's shaper was based closely on the one in sch_fq at the time, and I modified it after noticing that it had a very limited maximum throughput when timer resolution was poor (eg. at 1kHz on an old PC without HPET hardware, we could only get 1k pps).  Now, any late timer event will result in a burst being issued to catch up with the proper schedule.  The only time that wouldn't work is if the queue is empty.

	This nicely and effortlessly explains why cake unlike HTB+fq_codel maintains the set bandwidth better under CPU load (but then these burst also increase latency under load a bit more; then again again, we had to make the burst buffering for HTB configurable so it would not be as bad in dropping bandwidth on the floor). But I assume that you bound the bursts somehow, do you remember your bust sizing method by chance? (For HTB/TBF sqm now simply allows the user to configure a maximum burst service time im microseconds, that at least allows to make a conscious trade-off).


> 
> If the patches currently being trialled are not sufficient, then perhaps we could try something counter-intuitive: switch on "flows" instead of "flowblind", and enable the ack-filter.  That should result in fewer small packets to process, as the ack-filter will coalesce some acks, especially under load.  It might also help to select "satellite" AQM parameters, reducing the amount of processing needed at that layer.
> 
> - Jonathan Morton
> 
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake