From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-03-iad.dyndns.com (mxout-043-iad.mailhop.org [216.146.32.43]) by lists.bufferbloat.net (Postfix) with ESMTP id BF7372E06FF for ; Wed, 23 Mar 2011 13:40:56 -0700 (PDT) Received: from scan-02-iad.mailhop.org (scan-02-iad.local [10.150.0.207]) by mail-03-iad.dyndns.com (Postfix) with ESMTP id E8CA5835053 for ; Wed, 23 Mar 2011 20:40:57 +0000 (UTC) X-Spam-Score: -1.0 (-) X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 209.85.215.43 Received: from mail-ew0-f43.google.com (mail-ew0-f43.google.com [209.85.215.43]) by mail-03-iad.dyndns.com (Postfix) with ESMTP id 43D75835050; Wed, 23 Mar 2011 20:40:57 +0000 (UTC) Received: by ewy20 with SMTP id 20so2808621ewy.16 for ; Wed, 23 Mar 2011 13:40:54 -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=U38kH6QihZac3pMXDPD4aUuHHccSy6OVpWJQ35MAUvg=; b=LfN80duzWsn+62++mE1NjIVo+Bq1we1XSeTsq4+cRs78Bmh4UYv9ixGJ0sjGd9RpSf ryDHdmOB1YYVj/Q24jzv3R8PdQUzDjBhx5pOtJ9XRvruZ3jbT+YI7FJY/pvL+oOkcUvS U/nkVmnEKLCyFyw5DVvEwDe7lSQ6DAdfCnXks= 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=aVE6/KdNBWZsTP4XzhLLrgteSeWJDG9WTewprMe9Y4A1vZDKYif+S/RWFcc3zftWu5 UxIQ61P4zO7rdnqjkNQK6hwf6iR5rtv9F5AWkezQtZt9F7ypxbMyy2RkUX2I5KasapLq YlAnNFqEq+qm1Bc9bX2ChSkKj5fen3ANdugec= Received: by 10.213.105.206 with SMTP id u14mr3347610ebo.48.1300912854197; Wed, 23 Mar 2011 13:40:54 -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 u45sm3967685eeh.2.2011.03.23.13.40.51 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 23 Mar 2011 13:40:53 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jonathan Morton In-Reply-To: <20110323192740.GI30600@guug.org> Date: Wed, 23 Mar 2011 22:40:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0D59AD34-AA64-4376-BB8E-58C5D378F488@gmail.com> <4D829B58.1070601@swin.edu.au> <20110323103357.GG30600@guug.org> <20110323192740.GI30600@guug.org> To: Otto Solares X-Mailer: Apple Mail (2.1082) 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: Wed, 23 Mar 2011 20:40:57 -0000 On 23 Mar, 2011, at 9:27 pm, Otto Solares wrote: >> Unfortunately that patch will not work - it completely breaks part of = the on-wire protocol. It is much better to simply convert the final = results for an auxiliary display.=20 >=20 > Yeah, after hours of running some results seems wrong, hopefully is = not > broken on my missing part of converting a float to network byte order. Well, it was that incorrect endianness-conversion which finally made me = throw my hands up in despair. I didn't bother reading to the end of the = patch. By contrast, changing the random-number generator has only a minor = impact on the program, namely how fast it can generate traffic and = whether a network compression engine might find compressible weaknesses = in it (the default UNIX rand() function is potentially weak enough for = that). I could quite happily drop in a standalone Mersenne Twister = implementation, so long as I could still show it was fast enough on my = old Pentium-MMX. >> I should also point out that I have very strong reasons for providing = the measurements in non-traditional units by default. I'm measuring = characteristics as they matter to applications and users, who measure = things in bytes and frames per second, not bits and milliseconds. It is = also much easier to get nontechnical people (who tend to be in charge of = budgets) to respond to bigger-is-better numbers.=20 >=20 > Understood your PoV, sadly even my bosses (who lacks any degree of > technicallity) knows that the Internet is sold to us in Mb/s (decimal) > and delay (as he call it) is measured in ms. I do plan to add the traditional units as a secondary output, but I want = to finish proving that high-frequency networks actually do exist first. = The existing units will remain primary for the reasons outlined below. > Good luck doing that nontechnical people use a CLI tool! ;) That is also a valid point, though I expect the tool to be used by at = least moderately technical people, and the results to be usable by less = technical people. It's also possible that it might eventually be = developed into a GUI tool. At the moment, the length of time it takes = to run a test creates a substantial selection for patience - but this is = partially deliberate, because it takes time to be sure of exercising the = network's worst-case performance modes. The real point is that applications don't care one jot about = bits-per-second, which is universally contaminated by overheads such as = packet headers, error correction and retransmissions. What they care = about is the bytes in the payload, so that's what I'm measuring. Even = if the Internet is *sold* in Mbps, it is *used* in KiB/s, and the usual = conversion factors between the two are routinely found to be inaccurate = (not least when the weasel-words "up to" are involved). Similarly, games run in frames-per-second, so comparing the = Responsiveness number to the performance of your graphics card let you = know how many frames of lag are induced purely by network conditions. = Equivalently, the Smoothness number compared to the framerate of a = typical video (30fps =3D 30Hz) tell you how many frames the video player = needs to buffer before it can reliably let you see anything. There is = not such an obvious link between the network and the application if you = measure the network in milliseconds, although the smoothness of current = networks is so poor that you can often see it in a Web browser's = download progress bar. The smoothness and responsiveness numbers I'm getting over Ethernet are = both absurdly low, suggesting that packet loss due to queue overstuffing = is endemic, even with packet buffers that are already far too large in = attempt to stave it off. In some cases I am even seeing connections = dropping due to complete starvation - multiple consecutive = retransmissions are being dropped. This is not how people think of a = modern network, especially not the wired, full-duplex, switched Ethernet = that I'm measuring right now. - Jonathan