General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@toke.dk>
To: bloat@lists.bufferbloat.net
Cc: codel@lists.bufferbloat.net
Subject: Re: [Bloat] [Codel] better testing, linux 3.6.1, cerowrt credits, other stuff
Date: Tue, 09 Oct 2012 21:35:46 +0200	[thread overview]
Message-ID: <87mwzvphf1.fsf@toke.dk> (raw)
In-Reply-To: <507454AA.9060206@hp.com>

[-- Attachment #1: Type: text/plain, Size: 3815 bytes --]

Rick Jones <rick.jones2@hp.com> writes:

Hi Rick

Thanks for your feedback.

> The script looks reasonable. Certainly cleaner than any Python I've
> yet written :) I might be a little worried about skew error though
> (assuming I've not mis-read the script and example ini file). That is
> why I use the "demo mode" of netperf in
> http://www.netperf.org/svn/netperf2/trunk/doc/examples/bloat.sh though
> it does make the post-processing rather more involved.

Ah, I see. I'll look into that. As far as I can tell from that script,
you're basically running it with the demo mode enabled, and graphing the
results with each line as a data point?

There's a comment about using negative values for -D to increase
accuracy at a cost of performance. Is this cost significant? And if it
is, would there be any reason why it wouldn't be possible to just use
positive values and then fix the error by interpolating values to be at
fixed intervals when graphing?

> I see you are running the TCP_RR test for less time than the
> TCP_STREAM/TCP_MAERTS test. What do you then do to show the latency
> without the bulk transfer load?

I ran the TCP_RR test by itself to get a baseline result. The idea with
the different lengths is to start the streams, wait two seconds, and
then run the roundtrip so that it finished two seconds before the
streams (i.e. the roundtrip test is only running while the streams are).
This is for my test setup, which is just a few computers connected with
ethernet; so no sudden roundtrip variances should occur. I can see how
it would be useful to get something that can be graphed over time; I'll
try to look into getting that working.

> I was thinking of trying to write a version of bloat.sh in python but
> before I did I wanted to know if python was sufficiently available in
> most folks bufferbloat testing environments. I figure in
> "full-featured" *nix systems that isn't an issue, but what about in
> the routers?

Is there any reason why it wouldn't be possible to run the python script
on a full-featured machine and run the netperf instances via an ssh
tunnel on the router (on a different interface than the one being
tested, of course)?


And since Dave replied while I was writing this, I'll just continue
straight on:

> That said, there is a start at lua wrappers as well as various
> post-processing scripts for things like gnuplot in my deBloat repo on
> github. The last time I got serious about getting something more
> conventionally publishable is in
> https://github.com/dtaht/deBloat/tree/master/test/results

I'll go digging in there for ideas for tests to add. And probably just
have a general look around.

> But: It became obvious fast that long RTT tests were needed, which
> I've been trying to establish the infrastructure to do

I assume that by "infrastructure" you mean "(netperf) servers far away"? What
would be needed for a test server in terms of resources (bandwidth and
otherwise)? I could try and persuade my university to let me setup a
test server on their network (which is in Denmark)...

> I'm tickled Toke is also dumping stuff into org-mode, which makes
> publishing content much easier from emacs.

Well, I'm keeping my notes in org mode, so it seemed like the thing to
do. My plan was (is) to add other output formatter(s) if I needed to
output to something different.

> Coherently tracking certain other variables (such as the actual tc
> qdisc line and sampling tc -s statistics across an interval) across
> tests is also needed.

This is on the router, I assume? Is that just running the tc command and
parsing the output? And if so, any ideas for a good way to timestamp it?
`date && tc -s` or?


-Toke

-- 
Toke Høiland-Jørgensen
toke@toke.dk

[-- Attachment #2: Type: application/pgp-signature, Size: 489 bytes --]

  parent reply	other threads:[~2012-10-09 19:36 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-09  3:21 [Bloat] " Dave Taht
2012-10-09 14:31 ` Toke Høiland-Jørgensen
2012-10-09 16:45   ` [Bloat] [Codel] " Rick Jones
2012-10-09 18:28     ` Dave Taht
2012-10-09 19:35     ` Toke Høiland-Jørgensen [this message]
2012-10-09 20:05       ` Rick Jones
2012-10-10 14:27         ` Toke Høiland-Jørgensen
2012-10-10 23:27       ` Michael Richardson
2012-10-10 23:29         ` Stephen Hemminger
2012-10-10 23:55           ` Luigi Rizzo
2012-10-10 23:32       ` Rick Jones

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/bloat.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87mwzvphf1.fsf@toke.dk \
    --to=toke@toke.dk \
    --cc=bloat@lists.bufferbloat.net \
    --cc=codel@lists.bufferbloat.net \
    /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