On 08/11/15 16:36, Jonathan Morton wrote: >> On 8 Nov, 2015, at 12:19, Kevin Darbyshire-Bryant wrote: >> >> 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. > Actually, the “threshold” mechanism doesn’t implement the priority queue at all, but only switches the underlying DRR weights between “priority balance” and “bandwidth balance”. Since it’s fundamentally DRR, and the weights of the queues never go to zero, there is no possibility of starvation. Additionally, the threshold mechanism itself “borrows” bandwidth from lower tins to serve higher ones - this is a holdover from an earlier version when there was indeed a separate hard shaper per tin. I did say that I felt my coding was more an act of vandalism than anything as well thought out as your code :-) > It *is* possible that the per-tin choices of target and interval might want tweaking, but it’s probably best to have some hard data for the effects of doing that. One possibility is that target should be tuned for the worst-case (minimum) bandwidth under maximally saturated conditions, rather than the raw threshold value. Oh absolutely. Real numbers from real testing, couldn't agree more. It's very much needed (by people who actually understand what they're looking at - rules me out) I think there are two separate questions that need looking at here: 1) In the presence of a full link, that link having competing 'full' flows in all 'tins', then how should cake split the link in terms of bandwidth? Dave has argued there is not enough focus on 'Best Effort' (tin 1) and too much focus on 'a bit better than best effort' (tin 2). Bulk (tin 0) I can't say I'm worried about. 'Voice' (low latency, low jitter) (tin 3) we're hoping is also low bandwidth. Without a full link it arguably doesn't matter 'cos as you say we 'borrow' bandwidth from the other tins to help out. I pushed a tweak to the bandwidth weights based on the insight you gave me ;-) It might keep Dave happier (Bulk = 1/16th, Best Effort 8/16th, 'Better than best effort' 7/16th, 'Voice, low latency & jitter' 2/16th) Needs testing, needs numbers, based on a *little* testing with flent it 'behaves' as per those allocations in the presence of saturated link, saturating all tins. 2) With each increasing priority of tini[0-3], we decrease the 'expected' bandwidth (good) but also as a result increase the target and interval. Unless I've missed it, I've not yet seen an explanation at my level (ie. idiot!) as to why that is the case. The underlying link rate doesn't change (it always runs at tin[0]) so it appears that we become more tolerant of things sitting in and take longer to do anything about it in tin[3]'s queue than tin[0]. I genuinely don't understand why....and I'll assume my default position that it's 'cos I'm dumb rather than an error in what I can see is carefully crafted code. But I do remain confused. Kevin