Historic archive of defunct list bloat-devel@lists.bufferbloat.net
 help / color / mirror / Atom feed
From: Dave Taht <dave.taht@gmail.com>
To: Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr>
Cc: Baptiste Jonglez <baptiste.jonglez@ens-lyon.fr>,
	bloat-devel <bloat-devel@lists.bufferbloat.net>,
	"babel-users@lists.alioth.debian.org"
	<babel-users@lists.alioth.debian.org>
Subject: Re: [Babel-users] Follow-up on the new babel-rtt branch: µs resolution
Date: Wed, 30 Oct 2013 18:23:22 -0700	[thread overview]
Message-ID: <CAA93jw4uY-mWn2JJ7Cdxs2kque==3CQhAKT9X6WUKd2LWg08Bw@mail.gmail.com> (raw)
In-Reply-To: <87zjpqz45l.wl%jch@pps.univ-paris-diderot.fr>

On Wed, Oct 30, 2013 at 5:15 PM, Juliusz Chroboczek
<jch@pps.univ-paris-diderot.fr> wrote:
> Baptiste:
>
>> - Babel sees a RTT that is 400 µs higher than ping6.  The babel-rtt
>>   implementation timestamps outgoing message as late as possible, and
>>   timestamps incoming messages as early as possible, but it's not
>>   perfect.
>
> The good news, of course, is that the offset is pretty constant, so
> the samples computed by babeld are good enough to be input to the
> metric computation.  The smoothed samples would appear to have
> a precision of roughly 200us, which should be good enough for almost
> any application.

I will try to get an equivalent measurement on vastly weaker hardware
(ar71xx/ath9k) on my next set of builds (after ietf), ~2 weeks.

I would like measurements under various loads...

> Baptiste, I'm wondering if you can count the number of Ethernet
> switches that way.

In cut-through mode this switch claims 400ns or so latency.

http://ark.intel.com/products/76302/Intel-Ethernet-Switch-FM5224

Older models of this were better - 300ns or less.

>
>> I'm delighted to see this measurement as collected by babel
>
> I knew you would be :-)
>
>> my sekret plan was to be able to measure heavy traffic benchmarks vs
>> various qdiscs like the new "fq" and older fq_codel ones...
>
> Well, the reason we decided it's worthwile to improve the precision of
> our measurements is that, according to Jim, you had a secret plan to
> use RTT to measure link-layer congestion in Wifi meshes.

Yes, ~200us precision is nicely less than a txop. This will help.

> How many
> more secret plans do you have?

One or two. ;)

> -- Juliusz
>
> _______________________________________________
> Babel-users mailing list
> Babel-users@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

      reply	other threads:[~2013-10-31  1:23 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20131030183629.GB4316@ens-lyon.fr>
2013-10-30 19:29 ` Dave Taht
2013-10-31  0:15 ` Juliusz Chroboczek
2013-10-31  1:23   ` Dave Taht [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='CAA93jw4uY-mWn2JJ7Cdxs2kque==3CQhAKT9X6WUKd2LWg08Bw@mail.gmail.com' \
    --to=dave.taht@gmail.com \
    --cc=babel-users@lists.alioth.debian.org \
    --cc=baptiste.jonglez@ens-lyon.fr \
    --cc=bloat-devel@lists.bufferbloat.net \
    --cc=jch@pps.univ-paris-diderot.fr \
    /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