[Babel-users] Follow-up on the new babel-rtt branch: µs resolution

[Baptiste Jonglez]

On Wed, Oct 30, 2013 at 12:29:18PM -0700, Dave Taht wrote:
> > - the ping6 result is surprising, as two groups of points clearly
> >   appear, separated by about 200 µs.  It seems that interrupts might
> >   be responsible for this, but it's still somewhat unclear.
> 
> It could be caused by napi. There is also some parameter to ethtool
> (?) to tell it to return pings more immediately (that I recall was
> specific to the e1000e network card). I'm pretty sure it was the
> --coalesce some_option

Ok, I'll give it a try.

> You might find it easier to verify your measurement with owamp and gps
> synced clocks.
> 
> I'm delighted to see this measurement as collected by babel as my
> sekret plan was to be able to measure heavy traffic benchmarks vs
> various qdiscs like the new "fq" and older fq_codel ones...

The new code should be finalised and merged in babeld by the end of
the week.

> > - 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.
> 
> Did you try hardware timestamping on rx? (this is a kernel compile option)

Nope, nor kernel timestamping.  This has low priority, I'd like to
finalise and merge the current version first.

> > Context-switching and syscalls can probably account for
> >   these 400 µs: a quick test, on the slower laptop, showed that
> >   calling the gettimeofday() syscall takes about 100 µs.

Err, I mixed figures up.  My basic measurement (running gettimeofday()
many times in a loop) indicates each gettimeofday() takes 100 ns, not
100 µs.

> Kernel version? This was sped up in some fairly recent kernel version (?)

Here are the actual results on various hardware:

  http://paste.debian.net/63080/

The code used is there:

  http://paste.debian.net/63079/

There doesn't seem to be any big difference between the tested kernel
version.  However, the measured system time is 0 in all cases, except
with the VM.  There may be some optimisations preventing the actual
syscall to happen.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/babel-users/attachments/20131031/832ad720/attachment.sig>