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 D4DDA208AAD for ; Fri, 21 Dec 2012 09:50:47 -0800 (PST) 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 1Tm6kA-000Aly-SA; Fri, 21 Dec 2012 17:50:46 +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: U2FsdGVkX1+9GQVSQC8VoG6wXtY+HjwtUvzfUwQ4tfE= Message-ID: <50D4A195.1080702@pollere.com> Date: Fri, 21 Dec 2012 09:51:17 -0800 From: Kathleen Nichols User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Dave Taht References: <50D496FB.5090409@pollere.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: codel@lists.bufferbloat.net Subject: Re: [Codel] R: Making tests on Tp-link router powered by Openwrt svn 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: Fri, 21 Dec 2012 17:50:48 -0000 Oh, yes, my sfqcodel tests in the simulator are all per-packet rounding so performance will vary. On 12/21/12 9:43 AM, Dave Taht wrote: > On Fri, Dec 21, 2012 at 6:06 PM, Kathleen Nichols wrote: >> On 12/21/12 2:32 AM, Dave Taht wrote: >>> On Fri, Dec 21, 2012 at 5:19 AM, Alessandro Bolletta >>> wrote: > >> I don't understand why you are lowering the target explicitly as the use of >> an MTU's worth of packets as the alternate target appeared to work quite >> well at rates down to 64kbps in simulation as well as in changing rates. >> I thought Van explained this nicely in his talk at IETF. > > I call this the horizontal standing queue problem, and it's specific > to *fq*_codel (and to some extent, the derivatives so far). > > I figure codel, by itself, copes better. > > but in fq_codel, each (of 1024 by default) queue is a full blown codel > queue, and thus drops out of drop state when the mtu limit is hit. > > Worse, fq_codel always sends a full quantum's worth of packets from > each queue, in order, not mixing them. This is perfectly fine and even > reasonably sane at truly high bandwidths where TSO/GSO and GRO are > being used, but a pretty terrible idea at 100Mbit and below, and > results in moving rapidly back and forth through the timestamps in the > backlog on that queue... > > The original fq_codel did no fate-sharing at all, the current one (in > 3.6) does. > > I produced (several months ago) a couple versions of (e and n) > fq_codel that did better mixing at a higher cpu cost. It was really > hard to see differences. I just found a bug in my nfq_codel patch > today in fact... > > Also fiddled a lot with the per queue don't shoot me at MTU limit, in > one version shared amongst all queues, in another, set to the size of > the biggest packet to have hit that queue since the end of the last > drop interval. > > So I then decided to really look at this, hard, by working on a set of > benchmarks that made it easy to load up a link with a wide variety of > actual traffic. I'm really happy with the rrul related tests toke has > put together. > > I tried to talk about this coherently then, and failed, so once I had > good tests showing various behaviors, I figured I'd talk about it. I > would still prefer not to talk about until I have results I can trust > and finding all the sources of experimental error in the labs setup so > far have eaten most of my time. > > I didn't mean to jump the gun on that today, I have a few weeks left > to go, and to collate the analysis coherently with the lab results, > and for all I know some aspect of the lab implementations, the known > BQL issue (bytes rather than packets), or the fact that HTB buffers up > a packet, are all more key to the problem. If it's real. > > In the benchmarks I've been doing via toke's implementation of the > rrul test suite, *on a asymmetric link* fq_codel behavior gets more > stable (uses up the largest percentage of bandwidth) if you set target > above the size of the maximum size packet's delivery time at that > bandwidth. Another benchmark that will show bad behavior regardless is > to try pounding a line flat for a while with dozens of full rate > streams. > > in your sfq_codel (which I hope to look at next week), do you have a > shared MTU limit for all streams or do you do it on a per stream > basis? > >> >> Kathie >> _______________________________________________ >> Codel mailing list >> Codel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/codel > > >