> 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’m assuming sparse_flow_count + bulk_flow_count wouldn’t be 0… Dave’s point about the possibility of 0 length packets could also get sch->q.qlen and tin_backlog out of sync. I’ll still look at loop ‘l’, but it starting with while(1) does open a door of sorts… ;) _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
