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 <[email protected]> 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
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
