From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-12-iad.dyndns.com (mxout-121-iad.mailhop.org [216.146.32.121]) by lists.bufferbloat.net (Postfix) with ESMTP id 3C2292E0726 for ; Sun, 20 Mar 2011 15:32:39 -0700 (PDT) Received: from scan-11-iad.mailhop.org (scan-11-iad.local [10.150.0.208]) by mail-12-iad.dyndns.com (Postfix) with ESMTP id 937E73702DB for ; Sun, 20 Mar 2011 22:32:38 +0000 (UTC) X-Spam-Score: 0.1 () X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 75.145.127.229 Received: from gw.co.teklibre.org (75-145-127-229-Colorado.hfc.comcastbusiness.net [75.145.127.229]) by mail-12-iad.dyndns.com (Postfix) with ESMTP id C915F36FE1E; Sun, 20 Mar 2011 22:32:36 +0000 (UTC) Received: from cruithne.co.teklibre.org (unknown [IPv6:2002:4b91:7fe5:1::20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cruithne.co.teklibre.org", Issuer "CA Cert Signing Authority" (verified OK)) by gw.co.teklibre.org (Postfix) with ESMTPS id 1BA805E88A; Sun, 20 Mar 2011 16:32:36 -0600 (MDT) Received: by cruithne.co.teklibre.org (Postfix, from userid 1000) id 72CF8120889; Sun, 20 Mar 2011 16:32:27 -0600 (MDT) From: d@taht.net (Dave =?utf-8?Q?T=C3=A4ht?=) To: Jonathan Morton Organization: Teklibre - http://www.teklibre.com References: <0D59AD34-AA64-4376-BB8E-58C5D378F488@gmail.com> <4D829B58.1070601@swin.edu.au> <4D8664A9.5060805@swin.edu.au> Date: Sun, 20 Mar 2011 16:32:27 -0600 In-Reply-To: (Jonathan Morton's message of "Sun, 20 Mar 2011 23:52:18 +0200") Message-ID: <87k4fte83o.fsf@cruithne.co.teklibre.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: bloat , bloat-devel Subject: Re: [Bloat] Progress with latency-under-load tool 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: Sun, 20 Mar 2011 22:32:39 -0000 Jonathan Morton writes: > On 20 Mar, 2011, at 10:33 pm, grenville armitage wrote: > > Customers won't be asking for "more Hertz" - or at least, none that > have any sense. They'll be asking for "more smoothness" for their > video streams, or "more responsiveness" for their online games. They > already ask for "more bandwidth", not "more megabits per second". I think despite your quest for a marketing number, that also reporting actual RTT would be helpful (and horrifying, as I just got a .02HZ rating on the still ongoing test...). I still can't claim to fully understand what this test is measuring. Scenario 8: 2 uploads, 1 downloads... 4743 KiB/s up, 3422 KiB/s down, 0.02 Hz smoothness Scenario 9: 3 uploads, 0 downloads... 7558 KiB/s up, 1.39 Hz smoothness Scenario 10: 0 uploads, 4 downloads... 6719 KiB/s down, 2.08 Hz smoothness Scenario 11: 1 uploads, 3 downloads... 4372 KiB/s up, 4067 KiB/s down, 1.30 Hz smoothness The interesting outlier thus far is 8... I'm tempted to stop the test now and recompile for testing 3 u/l 3 d/l first.... Even better, we could use a different name for your usage of hz or smoothness here. Mortons? (There, I named it for you. You cannot be accused of ego for using this new unit now. Enjoy. ) > Hertz makes sense as a unit because, when talking about latency or > transmission delays, shorter times are better, but people understand > "bigger is better" much more easily. Hard drives used to measure > their seek times in milliseconds too, but now they are measured in > IOPS instead (a trend mostly associated with SSDs, which have IOPS > numbers several orders of magnitude better than mechanical drives). > > Let me manually translate that for you, though. That Responsiveness > rating of 2Hz means that the practical RTT went above 334ms - and this > on a switched Fast Ethernet being driven by good-quality 1996-vintage > hardware on one side and a cheap nettop on the other. It actually > reflects not pure latency as 'ping' would have measured it, but a > packet loss and the time required to recover from it. Your explanation here is good. Perhaps it could be an automated textual description. > And the "smoothness" rating actually contrived to be *worse*, at > somewhere north of 500ms. At Fast Ethernet speeds, that implies > megabytes of buffering, on what really is a very old computer. Txqueuelen = 1000 = ~1.5Mbyte (and I'm struggling with using consistent decimal or base 2 units this month) Mibibyte? Normal dma tx ring size ranges from 64 to 512, can be seen sometimes with ethtool -g device > It's a clear sign of something very broken in the network stack, > especially as I get broadly similar results (with much higher > throughput numbers) when I run the same test on GigE hardware with > much more powerful computers (which can actually saturate GigE). > > You really don't want to see what I got on my 3G test runs. I got > 0.09 Hz from a single flow, and these tests run all the way up to 32 > flows. I think the modem switched down into GPRS mode for a few > minutes as well, even though there was no obvious change in > propagation conditions. > -- Dave Taht http://nex-6.taht.net