>>> your solution significantly hurts performance in the common case >> >> I'm sorry - did someone actually describe such a case? I must have >> missed it. > > I started this whole thread by pointing out that this behaviour results > in the delay of the TCP flows scaling with the number of active flows; > and that for 32 active flows (on a 10Mbps link), this results in the > latency being three times higher than for FQ-CoDel on the same link.
Okay, so intra-flow latency is impaired for bulk flows sharing a relatively low-bandwidth link. That's a metric which few people even know how to measure for bulk flows, though it is of course important for sparse flows. I was hoping you had a common use-case where *sparse* flow latency was impacted, in which case we could actually discuss it properly. But *inter-flow* latency is not impaired, is it? Nor intra-sparse-flow latency? Nor packet loss, which people often do measure (or at least talk about measuring) - quite the opposite? Nor goodput, which people *definitely* measure and notice, and is influenced more strongly by packet loss when in ingress mode? The measurement you took had a baseline latency in the region of 60ms. That's high enough for a couple of packets per flow to be in flight independently of the bottleneck queue. Therefore, the most severe effects of fq_codel's configuration (and Cake's old configuration) are less obvious, since TCP is still kept operating in a regime where its behaviour is vaguely acceptable. Aggregate goodput remains high anyway, due to the large number of flows involved, but I would expect the goodput of individual flows to show odd behaviour under fq_codel. I would take this argument more seriously if a use-case that mattered was identified. So far, I can't even see a coherent argument for making this tweak optional (which is of course possible), let alone removing it entirely; we only have a single synthetic benchmark which shows one obscure metric move in the "wrong" direction, versus a real use-case identified by an actual user in which this configuration genuinely helps. And I've tried to explain why I believe this to be the Right Thing to do in general, contrary to Dave's opinion. - Jonathan Morton _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
