From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 29AC321F0B6 for ; Tue, 4 Sep 2012 13:02:15 -0700 (PDT) Received: from c-24-4-217-203.hsd1.ca.comcast.net ([24.4.217.203] helo=kmn.local) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72) (envelope-from ) id 1T8zK9-000Dc5-PG; Tue, 04 Sep 2012 20:02:13 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.4.217.203 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX189U7jF+YQeqz05ssKVEr6FgZAwIR2qJuQ= Message-ID: <50465E63.4000606@pollere.com> Date: Tue, 04 Sep 2012 13:02:43 -0700 From: Kathleen Nichols User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: codel@lists.bufferbloat.net References: <1346784623.13121.65.camel@edumazet-glaptop> In-Reply-To: <1346784623.13121.65.camel@edumazet-glaptop> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Codel] fq_codel: revenge of the standing queue X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 20:02:15 -0000 I can't keep up with the pace here, but I'm compelled to express puzzlement at the notion that fq_codel gives *longer* standing queues than codel. The opposite happens with sfq_codel which is, I believe, doing the same basic things as fq_codel (a similar approach to that below for queues/bins that go empty) except for being packet scheduled rather than byte scheduled. I see this wonderful, well-controlled behavior without "reverse traffic" issues. This is why I think Eric's work on this rocks. imho, Kathie On 9/4/12 11:50 AM, Eric Dumazet wrote: > 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 > Codel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/codel >