[Cake] Thinking about ingress shaping & cake

[Kevin Darbyshire-Bryant]

> On 10 Apr 2020, at 15:14, Jonathan Morton <chromatix99 at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20200412/05010c4c/attachment.sig>