[Codel] The next slice of cake

[Sebastian Moeller]

Hi Jonathan,

On Mar 18, 2015, at 09:41 , Jonathan Morton <chromatix99 at gmail.com> wrote:

>> I wonder, are the low priority classes configured with a guaranteed minimum bandwidth to avoid starvation? And will they opportunistically grab all left over bandwidth to fill the pipe? Then speed test should just work as long as there is no competing traffic…
> 
> The problem is that, in the present version, *only* the bulk/background class can use the full pipe.  Best effort gets a large fraction as its limit, but it’s not full.  Existing speed tests use best-effort traffic, and that’s not likely to change soon.
> 
> The next version should change that.

	Great.

> 
>> I am probably out of my mind, but couldn't it help if cake would allow a fixed cycle mode where it would process 50ms or so worth of packets pass them to the interface, and then sleep until the next 50ms block start. This should just be a fallback mode to not degrade badly under overload…
> 
> There is already such a mode to cope with limited-resolution timers and the existing overheads.  Without it, the Pentium-MMX is limited to a rather low rate (since it then has to wait for a timer interrupt for alternate packets).  At 50Mbps+, it’s not too far off what it can bridge without shaping (60Mbps+).  For some reason, the little CPE boxes still lose more performance than that to shaping.

	Excellent.

> 
> Note that due to the very nature of shaping, the link is always either effectively idle (in which case an arriving packet is dispatched immediately, without waiting for a timer), or overloaded (in which case packets are delivered according to a schedule).  The question is whether the shaping rate also overloads the hardware.
> 
> In any case, bursting for fifty whole milliseconds at a time would absolutely *destroy* cake’s latency performance.  I’m not going to do that.  Accommodating timer performance is the only concession to bursting I’m willing to make.

	Well, I should not have put a number in, I know, I was mainly trying to push for a batching mode to distribute the timer and context switching costs over more work done, like the batching patches Jesper got into the kernel. I guess I should look at the cake code and try to understand what is happening ;)
	I think with HTB latency starts to suffer once the shaped rates exceed the hardware’s capabilities, so I think of this as a trade-off between latency and bandwidth; if cake does not show this behavior but just bounds the effective bandwidth instead of increasing latency the whole configurable tradeoff idea might make not much sense ;)

> 
>> I think the highest priority band should only get its bandwidth quota, and have no silent priority demotion; but otherwise I think that idea that classes can pick up unused bandwidth sounds sane, especially for best effort and background.
> 
> Let’s see how well it works this way.  It should be fairly easy to adjust this aspect of behaviour later on.
> 
> - Jonathan Morton
>