Pete Heist <[email protected]> writes: >> On Jul 6, 2018, at 12:31 AM, Toke Høiland-Jørgensen <[email protected]> wrote: >> >> I suspected that cake_dequeue() was looping forever, so I added some >> debug statements to investigate this; and turns out I was right. Using >> the debug patch below, in unlimited mode I get loop aborts on loop 'i' >> for unlimited mode and loop 'l' if I enable the shaper at 70 gbit. It >> happens pretty reliably, but only when I load up the link sufficiently >> (need 4-6 TCP flows which get ~50 Gbps of total throughput). >> >> The weird thing is that what appears to be happening, is that cake >> somehow gets into a state where sch->q.qlen is >0 while all tin backlogs >> are 0. I have no clue how this happens; as far as I can tell, all >> changes to tin_backlog are paired with a change to q.qlen. The only >> thing outside of cake itself that modifies q.qlen is peek(), which is >> not being used here. > > I’m not sure I’ll be much help, but here are the thoughts I start having with > loop ‘i’: > > - 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... > - I’m assuming sparse_flow_count + bulk_flow_count wouldn’t be 0… 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. -Toke _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
