From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-13-ewr.dyndns.com (mxout-072-ewr.mailhop.org [216.146.33.72]) by lists.bufferbloat.net (Postfix) with ESMTP id 253872E011F for ; Fri, 11 Mar 2011 16:45:48 -0800 (PST) Received: from scan-12-ewr.mailhop.org (scan-12-ewr.local [10.0.141.230]) by mail-13-ewr.dyndns.com (Postfix) with ESMTP id 6FA78A4BEE6 for ; Sat, 12 Mar 2011 00:45:48 +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-13-ewr.dyndns.com (Postfix) with ESMTP id 11F62A4BCC3 for ; Sat, 12 Mar 2011 00:45:47 +0000 (UTC) Received: by eydd26 with SMTP id d26so1282701eyd.16 for ; Fri, 11 Mar 2011 16:45:47 -0800 (PST) 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=3M+zqn2519GxqWz/QonyeWfWdbIItKGRdCW5AAZcdNo=; b=a7BXeCrkjUwRY9la5DxpgMIvS1m6wnugZzdBfQoU86zMG5mBjePhW8FCFxVzrhejkE MOOAwRWdT2Hm7eN2AJiTGmSva/OyDX1sbpEhLNbTfsWzbIjl9v/RQAL04pnE9y3GeafR 9cLgUh2f4cHZE0B1FL8O1kXxLJbrmN2hzCo8c= 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=l+u3eLL049Kd5sNhlznAcF0fWdTF3KN0nA45RV3r/u99wN9J1AuY8ShRPezfZNKbQH 23fKRD6UUH1uBLeTmDwWLnGdVu4HBiDrN39ia+3/yR+aQ/IgrZarhUrxFGQjsrUA7l0G UL1HA8kmzGUuNQatAOx4uTjMS6tPU+afRyTBo= Received: by 10.213.97.7 with SMTP id j7mr1666138ebn.112.1299890747260; Fri, 11 Mar 2011 16:45:47 -0800 (PST) Received: from [192.168.239.42] (xdsl-83-150-84-172.nebulazone.fi [83.150.84.172]) by mx.google.com with ESMTPS id x54sm3923470eeh.11.2011.03.11.16.45.46 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 Mar 2011 16:45:46 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jonathan Morton In-Reply-To: <1299888781.2087.2055.camel@tardy> Date: Sat, 12 Mar 2011 02:45:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <50E37E64-A21F-4503-83D8-DE81AA65F0C2@gmail.com> References: <16808EAB-2F52-4D32-8A8C-2AE09CD4D103@gmail.com> <1299888781.2087.2055.camel@tardy> To: rick.jones2@hp.com X-Mailer: Apple Mail (2.1082) Cc: bloat@lists.bufferbloat.net Subject: Re: [Bloat] Measuring latency-under-load consistently 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, 12 Mar 2011 00:45:49 -0000 On 12 Mar, 2011, at 2:13 am, Rick Jones wrote: > On Sat, 2011-03-12 at 02:00 +0200, Jonathan Morton wrote: >> I'm currently resurrecting my socket-programming skills (last used >> almost 10 years ago when IPv6 really *was* experimental) in the hope >> of making a usable latency-under-load tester. This could be run in >> server-mode on one host, and then as a client on another host could = be >> pointed at the server, followed by several minutes of churning and >> some nice round numbers. >>=20 >> It would need to make multiple TCP connections simultaneously, one of >> which would be used to measure latency (using NODELAY marked = sockets), >> and one or more others used to load the network and measure goodput.=20= >> It would automatically determine how long to run in order to get a >> reliable result that can't easily be challenged by (eg.) an ISP. >=20 > Why would it require multiple TCP connections? Only if none of the > connections have data flowing in the other direction, and your latency > measuring one would need that anyway.=20 Because the latency within a bulk flow is not as interesting as the = latency experienced by interactive or realtime flows sharing the same = link as a bulk flow (or three). In the presence of a re-ordering AQM = scheme (trivially, SFQ) the two are not the same. Suppose for example that you're downloading the latest Ubuntu DVD and = you suddenly think of something to look up on Wikipedia. With the = 30-second latencies I have personally experienced on some non-AQM links = under load, that is intolerably slow. With something as simple as SFQ = on that same queue it would be considerably better because the new = packets could bypass the queue associated with the old flow, but = measuring only the old flow wouldn't show that. Note that the occasional packet losses on a plain SFQ drop-tail queue = would still show extremely long maximum inter-arrival delays on the bulk = flow, and this is captured by the third metric (flow smoothness). > Also, while NODELAY (TCP_NODELAY I presume) might be interesting with > something that tried to have multiple, sub-MSS transactions in flight = at > one time, it won't change anything about how the packets flow on the > network - TCP_NODELAY has no effect beyond the TCP code running the > connection associated with the socket for that connection. I'm essentially going to be running a back-and-forth ping inside a TCP = session. Nagle's algorithm can, if it glitches, add hundreds of = milliseconds to that, which can be very material - eg. when measuring a = LAN or Wifi. I wouldn't set NODELAY on the bulk flows. Why ping inside a TCP session, rather than ICMP? Because I want to = bypass any specific optimisations for ICMP and measure what applications = can actually use. > You may be able to get most of what you want with a top-of-trunk = netperf > "burst mode" TCP_RR test. It isn't quite an exact match though. I don't really see how that would get the measurement I want. - Jonathan