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 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