> On 29 May 2020, at 11:06, Kevin Darbyshire-Bryant > <[email protected]> wrote: > > I’m trying to create a ‘diffserv5’ for the purposes of implementing a 'Least > Effort’ class: something like LE=Bittorrent, BK=Backups/long term > down/uploads, BE=Best Effort/Normal, VI=Streaming media/facetime/zoom, > VO=VOIP/SIP. Not too hard you’d think, take diffserv4 and add a tin. > > I did this with tin allocation: 0=LE, 1=BE, 2=BK, 3=VI, 4=VO. BW allocation > relative to base rate = LE>>8, BE>>0, BK>>4, VI>>1, VO>>2. Tin display order > = 0, 2, 1, 3, 4. In theory I don’t mind LE being starved hence the above > order. This pretty much ‘jammed' the shaper as soon as any traffic went into > LE with other higher priority tins seeing huge latencies, lots of drops and > general bad news all over. > > I tried again with a slightly different tin allocation: 0=BE, 1=LE, 2=BK, > 3=VI, 4=VO more in keeping with the existing arrangement and display order 1, > 2, 0, 3, 4. The shaper doesn’t appear to obviously wedge, though I have seen > some latency spikes that I don’t normally see, so it feels like there’s still > a corner case being hit. > > Does anyone have any ideas?
Pondering out loud: Is setting different (i.e. increased) codel intervals & targets sensible for ‘artificially’ reduced bandwidths, especially in ingress mode? If I have a 100mbit link and I wish to have a minimum reservation for a low bandwidth, low priority tin e.g. 1mbit. Does it make sense to make that tin respond slower as if it were a 1mbit link whereas it’s a minimally reserved portion of a 100mbit link and it could burst up 100 times quicker than I think? Egress I suspect is less of a problem in that we’ll queue the packets and eventually throw them in the floor, but ingress??? Kevin _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
