Hi Jonathan,
On Mar 18, 2015, at 09:41 , Jonathan Morton <[email protected]> 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
>
_______________________________________________
Codel mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/codel
