CoDel AQM discussions
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@toke.dk>
To: Dave Taht <dave.taht@gmail.com>
Cc: codel@lists.bufferbloat.net, cerowrt-devel@lists.bufferbloat.net,
	bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Codel] plots
Date: Fri, 23 Nov 2012 10:50:20 +0100	[thread overview]
Message-ID: <87mwy8a9i4.fsf@toke.dk> (raw)
In-Reply-To: <CAA93jw5oXCxF7CFobayFzggUj_PX-EnXccJjd1WSwqm8aoFfWw@mail.gmail.com> (Dave Taht's message of "Fri, 23 Nov 2012 06:53:16 +0100")

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

Dave Taht <dave.taht@gmail.com> writes:


> The *.svg of high bandwidths is nice, the *.ps of low is not so much.

Yeah, I see your point.

> 1) I think the way to fix the upload plot is to use a larger sample
> interval, like 1 second, when dealing with low bandwidths.

Well, the reason for missing data is that netperf "misses its deadlines"
so to speak. I.e. we tell it to output intermediate results every 0.1
seconds, and it only does so every 0.5. As I understood Rick's
explanation of how netperf's demo mode works, the problem with missing
deadlines is that netperf basically tries to guess how much data it will
send in the requested interval, and then after having sent that much
data it checks the time to see if it's time to output an intermediate
result. So if the data transfer rate is slower than expected, the
deadline will be missed.

Using negative numbers for the interval makes it check the time every
time it sends something, but it still needs to send a bit of data
between every check, and if that takes too long the holes will appear.

Using a longer sampling interval for the entire plot might alleviate
this, I suppose, but since we're measuring bytes sent per second, doing
so amounts to averaging subsequent points; so is there any reason why we
can't just do the averaging over the data we already have (i.e. just
increase the interpolation interval)?

If we do want to increase the actual sampling interval, do you propose
to do so only for low-bandwidth tests? Because in this case we would
either need to detect when the bandwidth is low and adjust parameters,
or there would have to be two versions of the test: a low-bandwith and a
high-bandwith version.

> 2) I am really hating losing the outliers entirely. In particular,
>
> Getting a second ping plot that used a cdf would be more accurate and
> revealing.

I agree that this is not optimal, and I've been thinking that I would
like to decouple the data gathering part from the plotting part a bit.
I.e. making it possible to specify a test that gathers a lot of data
(could add in tc stats for instance) and saves it, and then specify
several sets of plots to do on that data. CDF would be one of them,
another one could be a simpler plot that plots the average (or total)
upload and download with just the ping, similar to the simple plots we
did with just two streams. And I'm sure we can come up with more. Export
would still be there, of course; in fact, I was planning to switch to
using json as the native storage format.

I still have a way to go on my project writing before I get to doing the
tests for myself, but I can try and interleave some work on
netperf-wrapper to get the above changes in there? :)


-Toke

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

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

       reply	other threads:[~2012-11-23 10:39 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <E1TbdvD-00062R-FH@shinybook.infradead.org>
     [not found] ` <CAA93jw5oXCxF7CFobayFzggUj_PX-EnXccJjd1WSwqm8aoFfWw@mail.gmail.com>
2012-11-23  9:50   ` Toke Høiland-Jørgensen [this message]
2012-11-26 19:12     ` 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/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=87mwy8a9i4.fsf@toke.dk \
    --to=toke@toke.dk \
    --cc=bloat@lists.bufferbloat.net \
    --cc=cerowrt-devel@lists.bufferbloat.net \
    --cc=codel@lists.bufferbloat.net \
    --cc=dave.taht@gmail.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