From: Rick Jones <rick.jones2@hp.com>
To: Jesper Dangaard Brouer <jbrouer@redhat.com>
Cc: codel@lists.bufferbloat.net, bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Codel] [Bloat] Network test tools for many parallel/concurrent connections?
Date: Tue, 14 May 2013 15:26:22 -0700 [thread overview]
Message-ID: <5192BA0E.2000004@hp.com> (raw)
In-Reply-To: <20130514214841.1441c4b7@redhat.com>
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
next prev parent reply other threads:[~2013-05-14 22:26 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-14 13:48 [Codel] " Jesper Dangaard Brouer
2013-05-14 14:46 ` [Codel] [Bloat] " Dave Taht
2013-05-14 19:48 ` Jesper Dangaard Brouer
2013-05-14 22:26 ` Rick Jones [this message]
2013-05-14 15:47 ` Stephen Hemminger
2013-05-14 17:01 ` Dave Taht
2013-05-14 18:13 ` Jim Gettys
2013-05-14 19:20 ` Jesper Dangaard Brouer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/codel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5192BA0E.2000004@hp.com \
--to=rick.jones2@hp.com \
--cc=bloat@lists.bufferbloat.net \
--cc=codel@lists.bufferbloat.net \
--cc=jbrouer@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox