On Tue, 2012-09-04 at 11:35 -0700, Dave Taht wrote: > 2) New flows > > The next issue (at these 10 and 100Mbit rates) is the "new flow" idea > in fq_codel. It is VERY useful pushing sparse flows to the fore of the > queues, and also provided a boost to long RTT flows. However at high > levels of occupancy and low bandwidth, flows empty their queue > rapidly, become "new flows", and then mislead codel for that flow into > resetting itself again, since we end up with a short delay for the > re-entrance. This isn't a particularly horrible behavior, but as my > own hope for this feature was to make voip better primarily, and > everything else we got from it was a bonus. > > TSQ really made this oddity show up big. I think on routed traffic it > will be less of an issue.
This is simply not true, and based on misunderstanding on what does fq_codel. A flow never leaves the new flow list before doing a full RR cycle in old flow list (even without any packet in this flow) _IF_ we did a full RR cycle, then we accumulated a full quantum of credit, and lost our rank the 'fq_codel RR queue' (the combination of the 2 internal queues, new and old) Therefore, we allow the flow to be queued in 'new flow', to recover a bit of the lost rank in queue. Basically you dont interpret correctly the 'new_flow_count' counter. It means almost nothing at all, since for a given TCP flow, we _can_ increment this counter several time. _______________________________________________ Codel mailing list [email protected] https://lists.bufferbloat.net/listinfo/codel
