> 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

Attachment: signature.asc
Description: Message signed with OpenPGP

_______________________________________________
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Reply via email to