From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-13-iad.dyndns.com (mxout-094-iad.mailhop.org [216.146.32.94]) by lists.bufferbloat.net (Postfix) with ESMTP id D61B92E015C for ; Fri, 11 Mar 2011 16:13:08 -0800 (PST) Received: from scan-11-iad.mailhop.org (scan-11-iad.local [10.150.0.208]) by mail-13-iad.dyndns.com (Postfix) with ESMTP id 0BF2ABDD721 for ; Sat, 12 Mar 2011 00:13:04 +0000 (UTC) X-Spam-Score: -4.0 (----) X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 15.216.28.33 Received: from g1t0026.austin.hp.com (g1t0026.austin.hp.com [15.216.28.33]) by mail-13-iad.dyndns.com (Postfix) with ESMTP id A3407BDD0DF for ; Sat, 12 Mar 2011 00:13:03 +0000 (UTC) Received: from g1t0038.austin.hp.com (g1t0038.austin.hp.com [16.236.32.44]) by g1t0026.austin.hp.com (Postfix) with ESMTP id 40C51C2BB; Sat, 12 Mar 2011 00:13:03 +0000 (UTC) Received: from [16.89.244.213] (tardy.cup.hp.com [16.89.244.213]) by g1t0038.austin.hp.com (Postfix) with ESMTP id E80EC3022F; Sat, 12 Mar 2011 00:13:02 +0000 (UTC) From: Rick Jones To: Jonathan Morton In-Reply-To: <16808EAB-2F52-4D32-8A8C-2AE09CD4D103@gmail.com> References: <16808EAB-2F52-4D32-8A8C-2AE09CD4D103@gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 11 Mar 2011 16:13:01 -0800 Message-ID: <1299888781.2087.2055.camel@tardy> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit 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 Reply-To: rick.jones2@hp.com 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:13:09 -0000 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. > > 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. > 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. 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. 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. If you only ever have one transaction outstanding at a time, regardless of size, if TCP_NODELAY improves the latency, it means the TCP stack is broken wrt how to interpret the Nagle algorithm - likely as not it is trying to apply it segment by segment rather than by user send by user send. > The output metrics would be: > > 1) Average goodput for uplink and downlink, for single flows and > multiple flows, in binary megabytes per second. Just for laughs, I > might also add the equivalent gigabytes-per-month figures. > > 2) Maximum latency (in the parallel "interactive" flow) under load, > expressed in Hz rather than milliseconds. This gives a number that > gets bigger for better performance, which is much easier for laymen to > understand. > > 3) Flow smoothness, measured as the maximum time between sequential > received data for any continuous flow, also expressed in Hz. This is > an important metric for video and radio streaming, and one which CUBIC > will probably do extremely badly at if there are large buffers in the > path (without AQM or Blackpool). > > Any thoughts on this idea? 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. The idea is to ./configure netperf for burst mode and histogram, and probably the "omni" tests to get the more complete statistics on RTT latency, then run a burst mode TCP_RR test - if doing "upload" then with a large request size and a single byte response size. If doing "download" then with a single byte request size and a large response size. If you want to hear more, contact me off-list and I can wax philosophic on it. rick jones > - Jonathan > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat