From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "e36.co.us.ibm.com", Issuer "GeoTrust SSL CA" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id D360121F14B for ; Mon, 26 Nov 2012 09:21:09 -0800 (PST) Received: from /spool/local by e36.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 26 Nov 2012 10:21:07 -0700 Received: from d03dlp01.boulder.ibm.com (9.17.202.177) by e36.co.us.ibm.com (192.168.1.136) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 26 Nov 2012 10:21:04 -0700 Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id EAD091FF0046; Mon, 26 Nov 2012 10:20:51 -0700 (MST) Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id qAQHKnSk209470; Mon, 26 Nov 2012 10:20:51 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id qAQHKnf6031012; Mon, 26 Nov 2012 10:20:49 -0700 Received: from paulmck-ThinkPad-W500 ([9.47.24.61]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id qAQHKnu1030981; Mon, 26 Nov 2012 10:20:49 -0700 Received: by paulmck-ThinkPad-W500 (Postfix, from userid 1000) id EE9F4EBED1; Mon, 26 Nov 2012 09:20:48 -0800 (PST) Date: Mon, 26 Nov 2012 09:20:48 -0800 From: "Paul E. McKenney" To: Toke =?iso-8859-1?Q?H=F8iland-J=F8rgensen?= Message-ID: <20121126172048.GF2474@linux.vnet.ibm.com> References: <20121123221842.GD2829@linux.vnet.ibm.com> <87a9u7amon.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87a9u7amon.fsf@toke.dk> User-Agent: Mutt/1.5.21 (2010-09-15) X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12112617-7606-0000-0000-000005C74184 Cc: Paolo Valente , Eric Raymond , codel@lists.bufferbloat.net, cerowrt-devel@lists.bufferbloat.net, bloat , David Woodhouse , John Crispin Subject: Re: [Cerowrt-devel] FQ_Codel lwn draft article review X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list Reply-To: paulmck@linux.vnet.ibm.com List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 17:21:10 -0000 On Sat, Nov 24, 2012 at 01:07:04AM +0100, Toke Høiland-Jørgensen wrote: > "Paul E. McKenney" writes: > > > I am using these two in a new "Effectiveness of FQ-CoDel" section. > > Chrome can display .svg, and if it becomes a problem, I am sure that > > they can be converted. Please let me know if some other data would > > make the point better. > > If you are just trying to show the "ideal" effectiveness of fq_codel, > two attached graphs are from some old tests we did at the UDS showing a > simple ethernet link between two laptops with a single stream going in > each direction. This is of course by no means a real-world test, but on > the other hand they show a very visible factor ~4 improvement in > latency. > > These are the same graphs Dave used in his slides, but also in a 100mbit > version. > > > Also, I know what ICMP is, but the UDP variants are new to me. Could > > you please expand the "EF", "BK", "BE", and "CSS" acronyms? > > The UDP ping times are simply roundtrips/second (as measured by netperf) > converted to ping times. The acronyms are diffserv markings, i.e. > EF=expedited forwarding, BK=bulk (CS1 marking), BE=best effort (no > marking). The UDP ping tests tend to not work so well on a loaded link, > however, since netperf stops sending packets after detecting > (excessive(?)) loss. Which is why you see only see the UDP ping times on > the first part of the graph. > > The markings are also used on the TCP flows, as seen in the legend for > the up/downloads. > > > All sessions were started at T+5, then? > > The pings start right away, the transfers start at T+5 seconds. Looks > like the first ~five seconds of transfer is being cut off on those > graphs. I think what happens is that one of the streams (the turquoise > one) starts up faster than the other ones, consuming all the bandwidth > for the first couple of seconds until they adjust to the same level. > These initial values are then scaled off the graph as outlier values. If > you zoom in on the beginning of the graph you can see the turquoise line > coming down from far off the scale in one direction, while the rest come > From off the bottom. > > > Please see attached for update including .git directory. > > I got a little lost in all the lists of SFQ, but other than that I found > it quite readable. The diagrams of the queuing algorithms are a tad big, > though, I think. :) Thank you, I have shrunk the figures and added the acronym expansions. Thanx, Paul > When is the article going to be published? > > -Toke > > -- > Toke Høiland-Jørgensen > toke@toke.dk >