From: Dave Taht <dave.taht@gmail.com>
To: cerowrt-devel@lists.bufferbloat.net,
"Toke Høiland-Jørgensen" <toke@toke.dk>,
"Rick Jones" <rick.jones2@hp.com>
Subject: [Cerowrt-devel] advanced charting of realtime response under load
Date: Mon, 5 Nov 2012 07:29:50 +0100 [thread overview]
Message-ID: <CAA93jw5=4W5i3JvL-ZGQrwOw4dNONSbThbWsViEEF+RiOSKOKQ@mail.gmail.com> (raw)
I've been working with Toke Høiland-Jørgensen for the past few days on
trying to come up with useful plots of more complex workloads than we
currently have, in particular trying to come up with something that
would test over longer RTTs, against multiple packet classifications.
A start is at:
apt-get install python-matplotlib
build and install netperf-2.6 if you don't have it
git clone git://github.com/tohojo/netperf-wrapper.git
cd netperf-wrapper
python netperf-wrapper.py -o rrul.ps -f plot rrul
The rrul test is the nastiest one I've been able to devise...
Please note that "rrul" presently talks to a netperf netserver in
redwood city, california, and if you can find/setup a closer
netserver, the results will be less noisy and possibly more
interesting. You can override the test server on the command line. I'd
love to get some graphs back from y'all with simple_qos on and off,
and over wifi and ethernet.
(before my talk on thursday)?
Testing THROUGH the router is more useful than testing TO the router,
so setting up netperf's netserver on another box close by is more
useful.
There are a bunch of other tests in the test dir that are less extreme
than this one. For example time_ping_tcp_stream closely resembles the
classic bufferbloat tests...
https://raw.github.com/tohojo/netperf-wrapper/master/sample_plots/10m_pfifo_fast.png
https://raw.github.com/tohojo/netperf-wrapper/master/sample_plots/10m_fq_codel.png
Note that most of the non-rrul tests are not set to run long enough to
get useful results at longer rtts. I'd run them for 60 seconds or
more.
PS I'd like to get to where we had an avg line on the bandwidth graph,
and a CDF plot of "ping" times, in the long run...
PPS
IF you have a 3800 router, you have sufficient memory to run
sufficient copies of netserver on it if you modify /etc/xinetd.conf to
allow for 16 instances. More performant is to disable netserver in
/etc/xinet.d/netserver, then killall -1 xinetd, and then run netserver
standalone.
--
Dave Täht
Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
reply other threads:[~2012-11-05 6:29 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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/cerowrt-devel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAA93jw5=4W5i3JvL-ZGQrwOw4dNONSbThbWsViEEF+RiOSKOKQ@mail.gmail.com' \
--to=dave.taht@gmail.com \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=rick.jones2@hp.com \
--cc=toke@toke.dk \
/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