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

[Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>]

[-- Attachment #1: Type: text/plain, Size: 2710 bytes --]



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@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
>>
>> -Toke
> 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.
>
> Fun!
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)
target/interval.

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.


Kevin



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4816 bytes --]