From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from g1t0027.austin.hp.com (g1t0027.austin.hp.com [15.216.28.34]) (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 C5F3121F1B1 for ; Wed, 15 May 2013 09:38:03 -0700 (PDT) Received: from g1t0039.austin.hp.com (g1t0039.austin.hp.com [16.236.32.45]) by g1t0027.austin.hp.com (Postfix) with ESMTP id 6388D382EC; Wed, 15 May 2013 16:38:02 +0000 (UTC) Received: from [16.103.148.51] (tardy.usa.hp.com [16.103.148.51]) by g1t0039.austin.hp.com (Postfix) with ESMTP id 97C4F342A6; Wed, 15 May 2013 16:37:59 +0000 (UTC) Message-ID: <5193B9E7.2060302@hp.com> Date: Wed, 15 May 2013 09:37:59 -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> <5192BA0E.2000004@hp.com> <20130515122728.2702e47b@redhat.com> In-Reply-To: <20130515122728.2702e47b@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "bloat@lists.bufferbloat.net" Subject: Re: [Bloat] [Codel] Network test tools for many parallel/concurrent connections? 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, 15 May 2013 16:38:04 -0000 On 05/15/2013 03:27 AM, Jesper Dangaard Brouer wrote: > Hi Rick, > > Thanks for your input :-) > > I will definitely look into all these advanced options that netperf > provide (which is didn't know of). Netperf is definitely my favorite > benchmarking tool, but I don't think it supports concurrent connections? Not explicitly, no. It is left as a scripting exercise to the benchmarker :) The manual describes a few mechanisms for "synchronization" of tests to mitigate issues of skew error. My "favorite" at this point is to post-process demo-mode output (which presumes reasonably well-synchronized clocks). > (Perhaps a stupid question:) I'm curr using netperf 2.x, any reason I > should switch to netperf 3.x ? Netperf 3.x was something of an experimental dead-end. It did have the idea of launching multiple threads in the netperf side, but retained the process-per-connection model on the netserver side. I would suggest sticking with net[perf 2.x. happy benchmarking, rick > > Thanks you for developing netperf, And to the *many* people who have contributed to it over the years. > --Jesper > > > On Tue, 14 May 2013 15:26:22 -0700 > Rick Jones wrote: > >> 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 > > >