From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from g1t0026.austin.hp.com (g1t0026.austin.hp.com [15.216.28.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.hp.com", Issuer "VeriSign Class 3 Secure Server CA - G3" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 991CA201251 for ; Mon, 21 May 2012 16:30:32 -0700 (PDT) Received: from g1t0039.austin.hp.com (g1t0039.austin.hp.com [16.236.32.45]) by g1t0026.austin.hp.com (Postfix) with ESMTP id 408D2C023; Mon, 21 May 2012 23:30:31 +0000 (UTC) Received: from [16.89.64.213] (tardy.cup.hp.com [16.89.64.213]) by g1t0039.austin.hp.com (Postfix) with ESMTP id A8B6634393; Mon, 21 May 2012 23:30:30 +0000 (UTC) Message-ID: <4FBAD015.4040907@hp.com> Date: Mon, 21 May 2012 16:30:29 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Tobias Diedrich References: <20120520212944.GK22418@yumi.tdiedrich.de> <20120521003115.GO22418@yumi.tdiedrich.de> <4FBA7A57.7010709@hp.com> <20120521214935.GA28713@yumi.tdiedrich.de> <4FBABEF8.7050002@hp.com> <20120521230950.GB28713@yumi.tdiedrich.de> In-Reply-To: <20120521230950.GB28713@yumi.tdiedrich.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: OpenWrt Development List , codel@lists.bufferbloat.net Subject: Re: [Codel] BQL support in Ethernet drivers (and Kathie Nichols and Van Jacobson's new AQM, codel) 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: Mon, 21 May 2012 23:30:32 -0000 On 05/21/2012 04:09 PM, Tobias Diedrich wrote: > Rick Jones wrote: >> On 05/21/2012 02:49 PM, Tobias Diedrich wrote: >>> Rick Jones wrote: >>>> On 05/20/2012 08:48 PM, Dave Taht wrote: >>>>> Thx for the numbers! >>>>> >>>>> Could you do a TCP_RR while under load from UDP_STREAM? >>>> >>>> If you want to generate pretty pictures while doing so, you can >>>> probably tweak >>>> http://www.netperf.org/svn/netperf2/trunk/doc/examples/bloat.sh >>> >>> How about this: >>> http://tdiedrich.de/~ranma/bufferbloat-rt3050/ >> >> They look pretty I suppose, but it also looks like I've got the >> vrules botched somehow. Though I cannot find the bug just yet in >> the repository copy. The red vertical line should be at the start >> of the UDP_STREAM test's results, and there should be a black one >> right after. They shouldn't be at the ends of the _RR test. Did >> you tweak that bit when you converted to a UDP_STREAM test? > > Ah, yes, I botched the vrules. > >> The other thing is it appears the scaling to make rrdtool look like >> it supports dual y-axes could use a bit of tweaking. I was pretty >> much guessing there :( > > Well, I tweaked the scaling myself since I wasn't happy with the > original result either. :) I think my original ones had the unfortunate effect of putting lines on top of one another. Your's seem to put them pretty far apart (at least sometimes). We aught to be able to find some reasonable medium in there somewhere. I'm thinking if latency is the metric of greatest interest, we want that to have the full y axis, and then the peak bandwidth of the STREAM test be about half-way up? > I reuploaded new images with correct vrules and your scaling. > > Anything above 100Mbit can be assumed to be dropped here (although > only the bridge seems to drop, the gige mac gets backpressure from > the switch I think and just delays transmitting the next packet I > suppose). > > I can do a TCP_STREAM test, but since the SoC lacks sufficient oomph > to saturate a 100Mbit link the results are going to be boring I > expect. I get about 3MiB/s, regardless of TCP_STREAM or TCP_SENDFILE. > Maybe TCP_SENDFILE would be a bit faster if the driver implemented > checksum offload. I'm fine with folks using UDP_STREAM, so long as they are aware of the issues involved. rick