From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-14-ewr.dyndns.com (mxout-051-ewr.mailhop.org [216.146.33.51]) by lists.bufferbloat.net (Postfix) with ESMTP id A4C022E04AC for ; Tue, 8 Feb 2011 08:41:40 -0800 (PST) Received: from scan-11-ewr.mailhop.org (scan-11-ewr.local [10.0.141.229]) by mail-14-ewr.dyndns.com (Postfix) with ESMTP id 0F7639D06C5 for ; Tue, 8 Feb 2011 16:41:39 +0000 (UTC) X-Spam-Score: 0.0 () X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 76.96.59.212 Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by mail-14-ewr.dyndns.com (Postfix) with ESMTP id CDBC99D0686 for ; Tue, 8 Feb 2011 16:41:38 +0000 (UTC) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta14.westchester.pa.mail.comcast.net with comcast id 5UgB1g00417dt5G5EUhfpN; Tue, 08 Feb 2011 16:41:39 +0000 Received: from [192.168.1.119] ([98.229.99.32]) by omta13.westchester.pa.mail.comcast.net with comcast id 5Uhf1g0030hvpMe3ZUhfWd; Tue, 08 Feb 2011 16:41:39 +0000 Message-ID: <4D517242.3040608@freedesktop.org> Date: Tue, 08 Feb 2011 11:41:38 -0500 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: bloat@lists.bufferbloat.net References: <4D4ECF74.9080305@freedesktop.org> <1297012917.21875.26.camel@amd.pacdat.net> <20110206210317.GC3004@thyrsus.com> <20110208160900.GD2448@tuxdriver.com> In-Reply-To: <20110208160900.GD2448@tuxdriver.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Bloat] How do we shift the market? 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: Tue, 08 Feb 2011 16:41:41 -0000 On 02/08/2011 11:09 AM, John W. Linville wrote: > On Sun, Feb 06, 2011 at 04:03:17PM -0500, Eric Raymond wrote: >> richard: >>> We should probably come up with a list of key words/phrases that such >>> tests and comments and complaints and such can be easily categorized >>> under - terms that can be used in a marketing sense. >>> >>> Things like "multi-mode stress test" or "bandwidth-latency test" >>> Or how about a set of classifications of equipment based on what they >>> can deal with: 1-user throughput, family-capable throughput or??? >>> >>> How about "twitch latency" for the gamer market? >>> >>> It's hard to talk cohesively about the problem if we don't all use the >>> same terms with the same implied (and defined) words. Getting at least >>> some of them nailed down now will make a difference in the long run. >>> >>> I see wiki.bufferbloat.net has the "It Works" up on it - a page here on >>> terms would be a good thing. >> >> I am *so* there! :-) >> >> I'll start a glossary page. > > (Not strictly direct at Eric...) > > Is there any sort of standard metric for "latency under load"? > If not, should we define one? > > What would be meaningful? If you achieve a low latency at some > high percentage of bandwidth usage, does that always imply you can > expect similarly low latencies with lower bandwidth usage? If not, > how should our "LUL" metric account for such variance? > > Sorry if these are dumb questions -- remember, I'm an L2 > knuckle-dragger... :-) > Hi John, I don't think anyone here has tried to define a formal metric; mine has been just measure latency when a link is fully saturated; I've generally just used scp to saturate most links, for convenience, though I used nttcp when testing 100Mbps switches to ensure I had enough bandwidth. I generally use ICMP ping myself, being of similarly low level frame of mind. Given all the FUD around ICMP ping, however, I worked with Folkert VanHeusden to get persistent connections implemented in httping so that a TCP based ping would be available to confirm the results (so far, it has in my tests). And indeed, jitter is as important as latency for many applications, as latency + some sort of metric for jitter is generally the minimum latency you can run most real time applications at. Jitter is, of course, a statistical measurement. But since the expected outcome for latency is depends (slightly) on the number of flows (e.g. how many packets might typically be ahead of you competing for a link), a more formal definition is in order. Let me check around and see if we can get someone from the internet measurement community to get involved and give us something well understood for formal testing. - Jim