From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-12-ewr.dyndns.com (mxout-083-ewr.mailhop.org [216.146.33.83]) by lists.bufferbloat.net (Postfix) with ESMTP id 3C4292E03FA for ; Sun, 20 Mar 2011 14:52:23 -0700 (PDT) Received: from scan-11-ewr.mailhop.org (scan-11-ewr.local [10.0.141.229]) by mail-12-ewr.dyndns.com (Postfix) with ESMTP id 3C1CD93281B for ; Sun, 20 Mar 2011 21:52:22 +0000 (UTC) X-Spam-Score: -1.0 (-) X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 209.85.215.171 Received: from mail-ey0-f171.google.com (mail-ey0-f171.google.com [209.85.215.171]) by mail-12-ewr.dyndns.com (Postfix) with ESMTP id 796D993269B; Sun, 20 Mar 2011 21:52:21 +0000 (UTC) Received: by eydd26 with SMTP id d26so1625872eyd.16 for ; Sun, 20 Mar 2011 14:52:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=BTjhVkSdF7XZmlpb/yrMOlcEQU86dLQJ5a93rUYQFg0=; b=iz63mYHjuXp54m+ISEATIONQwWVp/+RuRNukZZ1JuRK3KiMOYWv3QYibeTGbexkus1 GaOFFe8UwNeQT0zghRJYJxvJLGZFTK5ELPpS4wZM/u1kxOTpzD2JBHhO1UFFfY0UHTuM aBCNTKeKI9TMujX1EIII8aUYwpGZwklUvNtww= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=vkWldwjgSkUUBWHybkw7MqPqCN70znNa0a83H+Ut3duFtDO9biyJoj2IunsjDVkjMS M+n3Rfhkmv0dkh1SysdA4UxJ868DwSJCb+/1hGoxU+62AHJTUzxIwe7S+F3SobmjMYCU lIfi/w7wjzxYnBPuBsSJevocfx4wuuI307fpE= Received: by 10.14.137.201 with SMTP id y49mr844937eei.244.1300657940726; Sun, 20 Mar 2011 14:52:20 -0700 (PDT) Received: from [192.168.239.42] (xdsl-83-150-84-172.nebulazone.fi [83.150.84.172]) by mx.google.com with ESMTPS id w59sm1472681eeh.17.2011.03.20.14.52.19 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 20 Mar 2011 14:52:20 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jonathan Morton In-Reply-To: <4D8664A9.5060805@swin.edu.au> Date: Sun, 20 Mar 2011 23:52:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0D59AD34-AA64-4376-BB8E-58C5D378F488@gmail.com> <4D829B58.1070601@swin.edu.au> <4D8664A9.5060805@swin.edu.au> To: grenville armitage X-Mailer: Apple Mail (2.1082) Cc: bloat-devel , bloat 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 21:52:23 -0000 On 20 Mar, 2011, at 10:33 pm, grenville armitage wrote: >> Here are some numbers I got from a test over a switched 100base-TX = LAN: >>=20 >> Upload Capacity: 1018 KiB/s >> Download Capacity: 2181 KiB/s >> Link Responsiveness: 2 Hz >> Flow Smoothness: 1 Hz >>=20 >> Horrible, isn't it? I deliberately left these machines with standard = configurations in order to show that. >=20 > Perhaps a tangential 2 cents from me, but I'm unclear how helpful = Hertz is as > a unit of measurement for the challenge of raising awareness of = bufferbloat. 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". 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. 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. 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. > And resolution past 3 significant digits from there seems > possible with posix timers. If the latency was staying in the single-digit milliseconds as it should = be on a LAN, you'd have three s.f. with just integers. I do print the = smoothness numbers out to 2 decimal places for the individual scenarios, = though - these are the numbers meant for investigating problems: Scenario 1: 0 uploads, 1 downloads... 1343 KiB/s down, 31.52 Hz = smoothness Scenario 2: 1 uploads, 0 downloads... 3670 KiB/s up, 22.24 Hz smoothness Scenario 3: 0 uploads, 2 downloads... 2077 KiB/s down, 19.70 Hz = smoothness Scenario 4: 1 uploads, 1 downloads... 2855 KiB/s up, 322 KiB/s down, = 6.44 Hz smoothness That's from a different test, where you can see the effect of a WLAN and = having Vegas on one side of the connection. With that said, since the single-digit results are so ubiquitous, = perhaps some extra precision is warranted after all. Perhaps I can take = the opportunity to squash some more minor bugs, and add an = interpretation of the goodput in terms of gigabytes per month. > How'd they do debloated? I'm still investigating that, partly as the older hardware wasn't yet = set up with kernels capable of running advanced qdiscs. It takes a = while to compile a kernel on a Pentium-MMX. I'm also really not sure = where to get debloated drivers for a VIA Rhine or a Sun GEM. ;-) Mind = you, such a thing may not be needed, if the device drivers are already = slim so that cutting txqueuelen is sufficient. I can't run debloated 3G tests - I don't have access to the buffer = controls on the base tower. :-( - Jonathan