> On 10 Apr 2020, at 15:14, Jonathan Morton <chromati...@gmail.com> wrote: > > > No. If the dequeue rate is never less than the enqueue rate, then the > backlog remains at zero pretty much all the time. There are some short-term > effects which can result in transient queuing of a small number of packets, > but these will all drain out promptly. > > For Cake to actually gain control of the bottleneck queue, it needs to > *become* the bottleneck - which, when downstream of the nominal bottleneck, > can only be achieved by shaping to a slower rate. I would try 79Mbit for > your case. > > - Jonathan Morton >
Thanks for correcting my erroneous thinking Jonathan! As I was typing it I was thinking “how does that actually work?” I should have thought more. I typically run ingress rate as 97.5% of modem sync rate (78000 of 80000) which is gives me a little wiggle room when the modem doesn’t quite make the 80000 target (often 79500ish). Egress is easy, 99.5% of 20000 ie. 19900, all is wonderful. 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. I guess ultimately we’re dependent on the upstream (ISP) shaper configuration, ie if that’s a large buffer and we’ve an unresponsive flow incoming then no matter what we do, we’re stuffed, that flow will fill the buffer & induce latency on other flows. Cheers, Kevin D-B gpg: 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake