[Cake] More on 'target' corner cases - rate/target/interval confusion?

[Kevin Darbyshire-Bryant]

At the moment cake is effectively saying that it expects stuff in tin 4 to take 4 times as long to send/its packets are 4 times as big depending which warped view you care to take :-)

That really doesn't make sense to me. 

--
Cheers,

Kevin at Darbyshire-Bryant.me.uk
Sent from my phone, apologies for brevity, spelling & top posting

> On 3 Nov 2015, at 13:56, Toke Høiland-Jørgensen <toke at toke.dk> wrote:
> 
> Sebastian Moeller <moeller0 at gmx.de> writes:
> 
>> I thought the rationale was that a target be tow the transfer time for
>> a single MTU packet is not too reasonable as the queue will enter
>> dropping state for each (full MTU) packet transferred.
> 
> Yes, that is exactly it. But that happens when the packet at the head of
> the queue is waiting on the packet *before* it, which will be in a lower
> layer in the process of being transferred (at low bandwidths that "lower
> layer" has in practice been HTB).
> 
> However, now that cake itself is doing the delaying (via the packet
> transmission scheduling), this is not as clear-cut. The actual packet at
> the head of the queue is now the one being delayed. I'm afraid I don't
> quite grok how the shaper and CoDel interacts in this case; guess I'll
> go read the code.
> 
>> I guess most VoIP packets will not be full MTU, so on a dedicated VoIP
>> queue the 1.5 * full MTU idea might be sub-optimal...
> 
> That is also a (separate IMO) issue; however, as Dave said, we need to
> be vary of just assuming that the VoIP queue will be only small VoIP
> packets: there's no admission control!
> 
> -Toke
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3062 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20151103/956db65f/attachment-0002.bin>