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

Dave Taht dave.taht at gmail.com
Wed Oct 30 15:29:18 EDT 2013

On Wed, Oct 30, 2013 at 11:36 AM, Baptiste Jonglez
<baptiste.jonglez at ens-lyon.fr> wrote:
> Dear Babel hackers,
> I'm currently testing my new babel-rtt code, which uses 32-bits
> timestamps to achieve a µs-resolution on RTT.
> A graph showing the RTT between two directly-connected hosts (Gigabit
> Ethernet) can be found in [1].
> The two hosts are laptops, directly connected with an Ethernet cable.
> Both have Gigabit interfaces.  One has a fast Intel Core2 duo CPU (2.4
> GHz), while the other has a slow AMD E2-1800 APU (1.7 GHz).
> Do note that the RTT is expressed in µs, not ms.  A few comments,
> prompted by a discussion with Juliusz and Matthieu:

I am pretty curious if you can tell the difference between 10GigE,
GigE, and 100Mbit under various loads.

> - 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

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...

> - 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)

> 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.

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

> Further comments are welcome.
> [1] http://ze.polyno.me/babel/32bits-rtt-ethernet.pdf
> _______________________________________________
> Babel-users mailing list
> Babel-users at 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

More information about the Cerowrt-devel mailing list