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@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@toke.dk> wrote:
> 
> Sebastian Moeller <moeller0@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