> On 12 Apr, 2020, at 11:23 am, Kevin Darbyshire-Bryant > <ke...@darbyshire-bryant.me.uk> wrote: > > I’m wondering what the relationship between actual incoming rate vs shaped > rate and latency peaks is? My brain can’t compute that but I suspect is > related to the rtt of the flow/s and hence how quickly the signalling manages > to control the incoming rate.
There are two important cases to consider here: the slow-start and congestion-avoidance phases of TCP. But in general, the bigger the difference between the link rate and Cake's shaped rate, the less latency peaks you will notice. Slow-start basically doubles the send rate every RTT until terminated by a congestion signal. It's therefore likely that you'll get a full RTT of queued data at the moment of slow-start exit, which then has to drain - and most of this will occur in the dumb FIFO upstream of you. Typical Internet RTTs are about 80ms. You should expect a slow-start related latency spike every time you start a bulk flow, although some of them will be avoided by the HyStart algorithm, which uses increases in latency as a congestion signal specifically for governing slow-start exit. In congestion avoidance, TCP typically adds one segment to the congestion window per RTT. If you assume the shaper is saturated, you can calculate the excess bandwidth caused by this "Reno linear growth" as 8 bits per byte * 1500 bytes * flow count / RTT seconds. For a single flow at 80ms, that's 150 Kbps. At 20ms it would be 600 Kbps. If that number totals less than the margin you've left, then the peaks of the AIMD sawtooth should not collect in the dumb FIFO and will be handled entirely by Cake. - Jonathan Morton _______________________________________________ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
