Re: [Cake] Thinking about ingress shaping & cake

[Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>]

[-- Attachment #1: Type: text/plain, Size: 1637 bytes --]



> On 10 Apr 2020, at 15:14, Jonathan Morton <chromatix99@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 #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]