On Wed, Jan 4, 2012 at 11:16 AM, Dave Taht <dave.t...@gmail.com> wrote: > > On Wed, Jan 4, 2012 at 4:25 PM, Jim Gettys <j...@freedesktop.org> wrote: > > > 1) since TCP is not "fair", particularly when given flows of > > different RTT's, how do we best deal with this issue? Do either/both > > SFQ/QFQ deal with this problem, and how do they differ? > > The reason why QFQ was outperforming SFQ here > > http://www.teklibre.com/~d/bloat/pfifo_sfq_vs_qfq_linear50.png > > was because SFQ was enqueuing the first packet of a new stream at the > end of the existing streams. > > After eric moved the SFQ enqueue to head, the two started performing > the same at light workloads. > > (keep in mind the comparison already to pfifo_fast - log scale) > > http://www.teklibre.com/~d/bloat/pfifo_fast_vs_sfq_qfq_log.png > > So, the net effect of either fq mechanism is that slower flows jump > forward in the queue. > RTT is not really relevant. [1]
I must have misinterpreted the 'new flows' discussion on netdev. Are these new flows in the sense of SYN/SYN-ACK, or new flows in the sense of "don't have any packets in the queue(s) right now"? > 1: the 'slower flows gain priority' question is my gravest concern > (eg, ledbat, bittorrent). It's fixable with per-host FQ. Meaning that you don't want to hand priority to stuff that is intended to stay in the background? How does the classification work you've been doing interact with these latest QFQ tests? Justin _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
