Pete Heist <[email protected]> writes: >> On Jul 6, 2018, at 11:29 AM, Toke Høiland-Jørgensen <[email protected]> wrote: >> >> Pete Heist <[email protected] <mailto:[email protected]>> 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 _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
