From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pb0-f43.google.com (mail-pb0-f43.google.com [209.85.160.43]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id EA76021F0FB; Sat, 24 Nov 2012 11:58:12 -0800 (PST) Received: by mail-pb0-f43.google.com with SMTP id wz17so8867513pbc.16 for ; Sat, 24 Nov 2012 11:58:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=7g1fEIZdlvrI78OEx1EcoBW5PJ1mCdTEkYr/obUXuQo=; b=rFqyEh7cCWtVksbF7jx8SxJZvOUX45PvwuuGea+rGvqPMzcO2dqyhcaZUdOO1gFXSn vu+UYLjH+frGh3IenhM9n9gZD72JYo/qx5hI2jzLQhQHLo6IAanL/35WDhu0TEf7mGzH rEBZSJcJj6LBt11QGp+qa5Y6/Lb1aTDWhES0nUp+TsD2aS7FqJZpOHm0Xop7dcnDZwWN 6vCjLolXLEqilMIQ0nKRsR1yzi41AwtG7EDuYlr8vNElG3me+8qgbJOYnpBx/xCT8w6H zplXs16Gtz2JfnvXUk/IxB6uTcx1ZzCz6R8PBnD2kn9cZddkRj8xoo1fViBVLlSBETtc T/BA== Received: by 10.68.238.34 with SMTP id vh2mr25313042pbc.6.1353787092326; Sat, 24 Nov 2012 11:58:12 -0800 (PST) Received: from ?IPv6:2406:e000:61fc:1:8ce3:c3f6:219f:2898? ([2406:e000:61fc:1:8ce3:c3f6:219f:2898]) by mx.google.com with ESMTPS id j4sm5831121pax.31.2012.11.24.11.58.07 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 24 Nov 2012 11:58:11 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Andrew McGregor In-Reply-To: Date: Sun, 25 Nov 2012 08:57:58 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121123221842.GD2829@linux.vnet.ibm.com> <87a9u7amon.fsf@toke.dk> To: Dave Taht X-Mailer: Apple Mail (2.1499) X-Mailman-Approved-At: Mon, 26 Nov 2012 16:52:29 -0800 Cc: Paolo Valente , =?iso-8859-1?Q?Toke_H=F8iland-J=F8rgensen?= , codel@lists.bufferbloat.net, cerowrt-devel@lists.bufferbloat.net, bloat , paulmck@linux.vnet.ibm.com, John Crispin Subject: Re: [Bloat] [Codel] FQ_Codel lwn draft article review X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2012 19:58:13 -0000 On 25/11/2012, at 5:19 AM, Dave Taht wrote: > On Sat, Nov 24, 2012 at 1:07 AM, Toke H=F8iland-J=F8rgensen = wrote: >> "Paul E. McKenney" writes: >>=20 >=20 > Indirectly observing the web load effects on that graph, while timing > web page completion, would be good, when comparing pfifo_fast and > various aqm variants. Indeed >>> 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? >>=20 >> The UDP ping times are simply roundtrips/second (as measured by = netperf) >> converted to ping times. The acronyms are diffserv markings, i.e. >> EF=3Dexpedited forwarding, BK=3Dbulk (CS1 marking), BE=3Dbest effort = (no >> marking). >=20 > The classification tests are in there for a number of reasons. >=20 > 0) I needed multiple streams in the test anyway. >=20 > 1) Many people keep insisting that classification can work. It > doesn't. It never has. Not over the wild and wooly internet. It only > rarely does any good at all even on internal networks. It sometimes > works on some kinds of udp streams, but that's it. The bulk of the > problem is the massive packet streams modern offloads generate, and > breaking those up, everywhere possible, any time possible. >=20 > I had put up a graph last week, that showed each classification bucket > for a tcp stream being totally ignored... >=20 > 2) Theoretically wireless 802.11e SHOULD respect classification. In > fact, it does, on the ath9k, to a large extent. However, on the iwl I > have, BE, BK traffic get completely starved by VO, and VI traffic, > which is something of a bug. I'm certain that due to inadaquate > testing, 802.11e classification is largely broken in the field, and > I'd hoped this test would bring that out to more people. 802.11e doesn't prevent a station from starving itself, nor does it help = the AP at all when there is contending traffic to deliver to the same = station... all it does for you is prevent one station with high priority = traffic to send/receive from getting completely starved by another = station with low priority. It's not at all a complete solution, and we = need something like the mythical mfq_codel to sort out the rest. > 3) I don't mind at an effort to make classification work, particularly > for traffic clearly marked background, such as bittorrent often is. > Perhaps this is an opportunity to get IPv6 done up right, as it seems > the diffserv bits are much more rarely fiddled with in transit Doesn't look that hard, to be honest. >> 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. >=20 > Netperf stops UDP_STREAM exchanges after the first lost udp packet. > This is not helpful. >=20 > I keep noting that the next phase of the rrul development is to find a > good pair of CIR one way measurements that look a bit like voip. > Either that test can get added to netperf or we use another tool, or > we create one, and I keep hoping for recommendations from various > people on this list. Come on, something like this > exists? Anybody? nmap -PU? >> 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. >=20 > I'm not willing to draw this conclusion from this graph, and need > to/would like someone else to/ setup a test in a controlled > environment. the wrapper scripts > can dump the raw data and I can manually plot using gnuplot or a > spreadsheet, but it's tedious... I may have some code that will help here, including CDFs and a rarely = seen in the wild exponential weighted moving variance. >> These initial values are then scaled off the graph as outlier values. >=20 > Huge need for cdf plots and to present the outliers. In fact I'd like > graphs that just presented the outliers. Another way to approach it > would be, instead of creating static graphs, to use something like the > ds3.js and incorporate the ability to zoom > in, around, and so on, on multiple data sets. Or leverage mlab's = tools. >=20 > I am no better at javascript than python. Run interactively, python matplotlib stuff lets you zoom. I don't know = if that can be made into a zoomable web page though. Andrew=