From: Dave Hart <davehart@gmail.com>
To: Jonathan Morton <chromatix99@gmail.com>
Cc: Otto Solares <solca@guug.org>,
bloat-devel <bloat-devel@lists.bufferbloat.net>
Subject: Re: [Bloat] Progress with latency-under-load tool
Date: Wed, 23 Mar 2011 22:32:49 +0000 [thread overview]
Message-ID: <AANLkTikTQr+P+2vkagiTRSmk_+AUAXMYcFppitygFJJc@mail.gmail.com> (raw)
In-Reply-To: <F66989ED-8082-40DA-90E6-08E0CEB7670A@gmail.com>
[Removed bloat@]
On Wed, Mar 23, 2011 at 8:40 PM, Jonathan Morton <chromatix99@gmail.com> wrote:
> I do plan to add the traditional units as a secondary output, but I want
> to finish proving that high-frequency networks actually do exist first.
> The existing units will remain primary for the reasons outlined below.
- Hide quoted text -
Hi Jonathan. Thanks for taking the time to develop this new tool in
the bufferbloat.net arsenal.
I have been hoping you would come around under the overwhelming
one-sided responses to your use of inverted statistics and save me
from weighing in, but no such luck, though I'm not sure there's been a
single expression of support for reporting only Hz.
I fail to see how reporting latency and max observed payload progress
stall time in both time and Hz would prevent the proof you seek, which
leaves me wondering what really underlies your rigidity.
The Hz representation is hiding useful information, because despite
our hopes, the latency and peak jitter do in fact often exceed 1s, and
your tool is limiting the display to so few significant digits the end
result is the summary numbers (0 Hz!) are _useless_ and any
information to be gleaned has to come from our own summary of the
individual test statistics. I also question using only the worst
result as the overall result -- I fear it will lead to the tool being
viewed as producing noisy numbers requiring many runs to validate
before drawing conclusions. I suggest min/max/avg/stddev for each.
Your apparent belief is that the people who must be convinced are not
clever enough to properly interpret lower-is-better. That is a
presumptive and condescending attitude. I suspect that's a big part
of why the response so far has been so one-sided.
Thanks again for producing your tool and enabling others to measure
and share what they see with it.
Cheers,
Dave Hart
prev parent reply other threads:[~2011-03-23 22:33 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <0D59AD34-AA64-4376-BB8E-58C5D378F488@gmail.com>
[not found] ` <4D829B58.1070601@swin.edu.au>
2011-03-20 10:45 ` Jonathan Morton
[not found] ` <AANLkTin1UwEqDiBHvWQ7xi4jP0O4ifhsoBWnWJjE7Byv@mail.gmail.com>
2011-03-20 14:33 ` Fwd: " Pedro Tumusok
2011-03-20 14:42 ` Jonathan Morton
2011-03-20 20:33 ` grenville armitage
2011-03-20 20:53 ` Dave Täht
2011-03-20 21:52 ` Jonathan Morton
2011-03-20 22:32 ` Dave Täht
2011-03-20 22:47 ` Dave Täht
2011-03-20 22:52 ` Jonathan Morton
2011-03-20 22:55 ` Dave Täht
2011-03-20 23:42 ` Dave Täht
2011-03-20 21:50 ` Some results of the latency under load tool Dave Täht
2011-03-20 22:24 ` Jonathan Morton
[not found] ` <m3d3llgln8.fsf@yahoo.com>
2011-03-21 6:43 ` [Bloat] Progress with latency-under-load tool Jonathan Morton
2011-03-23 10:33 ` Otto Solares Cabrera
2011-03-23 11:26 ` Jonathan Morton
2011-03-23 19:27 ` Otto Solares
2011-03-23 20:40 ` Jonathan Morton
2011-03-23 22:32 ` Dave Hart [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AANLkTikTQr+P+2vkagiTRSmk_+AUAXMYcFppitygFJJc@mail.gmail.com \
--to=davehart@gmail.com \
--cc=bloat-devel@lists.bufferbloat.net \
--cc=chromatix99@gmail.com \
--cc=davehart_gmail_exchange_tee@davehart.net \
--cc=solca@guug.org \
/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