[Cake] More on 'target' corner cases - rate/target/interval confusion?
kevin at darbyshire-bryant.me.uk
Sun Nov 8 05:19:26 EST 2015
On 05/11/15 16:41, Kevin Darbyshire-Bryant wrote:
> On 03/11/15 14:12, Toke Høiland-Jørgensen wrote:
>> Kevin Darbyshire-Bryant <kevin at darbyshire-bryant.me.uk> writes:
>>> 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 :-)
>> Yup, exactly. However that can be true because tin 4 is shaped to 1/4
>> the rate; so for 1 packet, that is actually true.
>> However, it's not really a shaping, it's a threshold. Or is it? As I
>> said, I need to go read the code :P
> Following this up: The existing code is correct, or is certainly much
> more correct than some changes I've been experimenting with :-) The
> bottom line is that passing the true 'line' rate and hence related
> target/intervals for each tin rather breaks the class/tin shaper,
> something I proved with the aid of flent. 'b->tin_rate_bps = rate;' is
> really a reporting construct and isn't actually used as an active part
> of code.
> So I'm gradually understanding things....by breaking them and putting
> them back together :-) The exact mechanism for shaping eludes me at
> the moment (I suspect 'threshold') and quite what effect 'target' and
> 'interval' really have again is something to experiment with.
Ok, so more following up. 'threshold' does indeed act as the shaper and
bases its value on target/interval for that tin which is why tweaking
'tin_rate_bps' doesn't help. I still feel confused as to why 'lower
bandwidth allocation/higher priority/lower jitter' tins end up with
higher targets & intervals. So, in the interests of experimentation I
came up with another way of setting all tins to the same (tin 0)
I pushed a branch
https://github.com/dtaht/sch_cake/tree/targetintervalcopied I'm sorry
Jonathan, every time I touch your code I feel like I'm being an absolute
vandal, please forgive the horrors!
If someone is bored, has a suitable test bed etc I'd be really
interested to know what differences are seen with this code.
Whilst I was there I also subtly tweaked the diffserv4 video tin
bandwidth allocation to 11/16ths rather than 3/4. In combination with
voice (1/4) it meant that (theoretically) best effort could be
completely starved, let alone bulk - it doesn't seem to actually happen
in real life, but setting video to 11/16th & voice to 4/16th means that
there's 1/16th to be fought over between best effort and bulk - and best
effort as a result does seem to get a little bit more of a look-in in
the face of 'more important' competition.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4816 bytes
Desc: S/MIME Cryptographic Signature
More information about the Cake