Re: [Cake] cake at 60gbit

["Toke Høiland-Jørgensen" <toke@toke.dk>]

Pete Heist <pete@heistp.net> writes:

>> On Jul 6, 2018, at 11:29 AM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>> 
>> Pete Heist <pete@heistp.net <mailto:pete@heistp.net>> writes:
>> 
>>> - is tin_deficit overflowing at these rates? at 50gbit, 2^31-1 bytes
>>> happen in 344 ms (involuntary chuckle)
>>> - what’s the value of tin_quantum_band here? but I suspect it’s ok.
>> 
>> I thought about overflows, but I don't get any "weird" values, and
>> everything ends up back at zero when the flows stop. And it's not
>> actually tin_backlog that's causing the looping…
>
> Ok, I think tin_deficit is meant here, esp. in light of what follows regarding *_flow_count.
>
> Once we do get past this infinite loop, which it sounds like is not
> caused by overflow here, I guess it’s still worth reviewing whether
> tin_backlog or other values _could_ overflow in certain conditions.

There's a global memory limit which limits the backlog. So no overflows
as long as the accounting is working correctly :)

>> Yeah, they are; that's why it keeps looping. I've been looking at both
>> tin_backlog and the *_flow_count vars as different ways of checking
>> whether the tins are actually empty... they are all 0 when this happens.
>
> Aha, ok. It does look physically possible for these to both be 0 since
> there appear to be cases where one is decremented without the other
> being incremented. That _all_ *_flow_count vars are 0 seems strange
> logically. I’ll leave this alone now though as don’t yet understand
> what the values represent well enough… :)

Yeah, that state machine is a bit too complicated for my taste as well;
not sure it's actually incorrect, though...

-Toke