From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from g5t0007.atlanta.hp.com (g5t0007.atlanta.hp.com [15.192.0.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.hp.com", Issuer "VeriSign Class 3 Secure Server CA - G3" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 2212D21F1F0; Tue, 14 May 2013 15:26:25 -0700 (PDT) Received: from g5t0030.atlanta.hp.com (g5t0030.atlanta.hp.com [16.228.8.142]) by g5t0007.atlanta.hp.com (Postfix) with ESMTP id BC09B1408E; Tue, 14 May 2013 22:26:23 +0000 (UTC) Received: from [16.103.148.51] (tardy.usa.hp.com [16.103.148.51]) by g5t0030.atlanta.hp.com (Postfix) with ESMTP id 419451404C; Tue, 14 May 2013 22:26:23 +0000 (UTC) Message-ID: <5192BA0E.2000004@hp.com> Date: Tue, 14 May 2013 15:26:22 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Jesper Dangaard Brouer References: <20130514154838.2d9622b7@redhat.com> <20130514214841.1441c4b7@redhat.com> In-Reply-To: <20130514214841.1441c4b7@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: codel@lists.bufferbloat.net, bloat Subject: Re: [Codel] [Bloat] Network test tools for many parallel/concurrent connections? X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 22:26:25 -0000 It will not match what one can get from tcptrace, or commercial solutions, but netperf can be asked to emit a number of potentially "intersting" things. Using the "omni output selectors" one can request statistics for some interesting latencies: raj@tardy:~$ netperf -- -O ? | grep LAT RT_LATENCY MIN_LATENCY MAX_LATENCY P50_LATENCY P90_LATENCY P99_LATENCY MEAN_LATENCY STDDEV_LATENCY For a STREAM test those will be based on time in the send call. For a MAERTS test those will be time in the receive call. For an RR test those will be the round-trip times at the application layer. You can also ./configure --enable-histogram and if the verbosity is set to 2 or more, a histogram of the distribution will be emitted which will resemble: Histogram of time spent in send() call. UNIT_USEC : 0: 0: 434: 404912: 715323: 800663: 263305: 9336: 2439: 1522 TEN_USEC : 0: 2276: 41: 48: 97: 67: 79: 17: 5: 7 HUNDRED_USEC : 0: 28: 2: 2: 0: 2: 0: 0: 1: 1 UNIT_MSEC : 0: 3: 2: 0: 1: 0: 1: 0: 0: 0 TEN_MSEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0 HUNDRED_MSEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0 UNIT_SEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0 TEN_SEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0 >100_SECS: 0 HIST_TOTAL: 2200614 when running under Linux, netperf also knows how to report the number of TCP retransmissions encountered over the life of the data connection: raj@tardy:~$ netperf -- -O ? | grep -i retran LOCAL_TRANSPORT_RETRANS REMOTE_TRANSPORT_RETRANS And if you want to have an idea of what each individual netperf was doing in terms of mbit/s or trans/s over discrete points in its lifetime, you can ./configure --enable-demo and it will emit interim results at roughly the requested interval which can then be post-processed. An example of that being done can be found in doc/examples/runemomniaggdemo.sh script and doc/examples/post_proc.py happy benchmarking, rick jones