General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Jonathan Morton <chromatix99@gmail.com>
To: Fred Baker <fred@cisco.com>
Cc: bloat@lists.bufferbloat.net
Subject: Re: [Bloat] Measuring latency-under-load consistently
Date: Sun, 13 Mar 2011 16:24:21 +0200	[thread overview]
Message-ID: <9F62E180-9379-4567-BA19-87C9F96B6F7E@gmail.com> (raw)
In-Reply-To: <EC6ABAE3-8C60-41BC-BFFE-2473BA900ADA@cisco.com>


On 13 Mar, 2011, at 8:54 am, Fred Baker wrote:

>>> At the risk of sounding like someone mentioning a product, let me mention a product. This assumes, of course, that you're using Cisco equipment. But it allows you to measure delay (how long does it take to get from here to there), jitter (first derivative of delay/dt), and packet loss.
>> 
>> Ping does most of this, and is available on your actual computer.  A little post-processing of the output gives you jitter, if it doesn't supply that natively.
>> 
>> The point is, the existing tools don't typically measure latency *under load*.
> 
> Actually, SAA uses ping, and is intended precisely to do it under load. Ping is part of the existing traffic, and measures the RTT as experienced by traffic following the same path that the ping does.
> 
> Not sure exactly where you're going with that...

While you, and I, and other professional researchers and administrators are quite capable of generating a consistent, relevant load and then measuring around it...  we're the exceptional people.  Most people don't know jitter from a hole in the ground, they just know that Skype doesn't work.

The tool I'm working on does it in an integrated fashion, so the potential for user errors (or plain old marketing BS) creeping into the measurement is reduced.  That is, it generates the load and measures the effect on latency in one step.  The ability to measure some interesting things about the bulk flows at the same time is icing on the cake.

I do have consumer-grade connections in mind for this, though no doubt it will also be useful on professional-grade networks - especially wireless ones.  The consumer space is where the worst problems are currently visible.

 - Jonathan


      reply	other threads:[~2011-03-13 14:24 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-12  0:00 Jonathan Morton
2011-03-12  0:13 ` Rick Jones
2011-03-12  0:45   ` Jonathan Morton
2011-03-12  1:09     ` Rick Jones
2011-03-12  1:44       ` Jonathan Morton
2011-03-12  3:19 ` richard
2011-03-12  3:52   ` Jonathan Morton
2011-03-12  4:04     ` richard
2011-03-12 21:57       ` Jonathan Morton
2011-03-12 22:23         ` richard
2011-03-12 23:58           ` Jonathan Morton
2011-03-12 22:21 ` Fred Baker
2011-03-12 23:03   ` Jonathan Morton
2011-03-13  6:54     ` Fred Baker
2011-03-13 14:24       ` Jonathan Morton [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

  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=9F62E180-9379-4567-BA19-87C9F96B6F7E@gmail.com \
    --to=chromatix99@gmail.com \
    --cc=bloat@lists.bufferbloat.net \
    --cc=fred@cisco.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