[Babel-users] us vs ns resolution in babel rtt branch

[Baptiste Jonglez]

Dave, this may interest you:

  https://blog.cloudflare.com/how-to-achieve-low-latency/

TL;DR : sending small packets between 2 high-end servers with 10G NIC
takes about 50 µs RTT (and they get down to 20 µs with heavy optimisations)

It looks to me as though µs granularity is still enough in this case.
Anyway, at these scales, I doubt you can use latency to guess the
link capacity.

On Thu, Apr 02, 2015 at 02:52:12PM -0700, Dave Taht wrote:
> I think my overall point regarding precision and granularity is that I
> am thinking in terms of babel in high speed switch/routers at 100+GigE
> and implemented in hardware, with timestamping even more accurate than
> what even ptp can achieve.
> 
> but I will wait til babel 3.0. :)
> 
> On Thu, Mar 19, 2015 at 7:45 PM, Dave Taht <dave.taht at gmail.com> wrote:
> > On Thu, Mar 19, 2015 at 2:36 PM, Juliusz Chroboczek
> > <jch at pps.univ-paris-diderot.fr> wrote:
> >>> I still kind of like getting down to ns resolution here. A single 64
> >>> byte packet at 10gigE takes like 64ns.
> >>
> >> Dave,
> >>
> >> As Baptiste mentioned, babeld measures latencies with a granularity of
> >> 1盜, and a precision of a few hundred 盜.  That means we have two to three
> >> orders of magnitude to grow.  We've already changed the protocol once to
> >> reduce the granularity, at your prompting, and there's no point doing that
> >> again until the precision becomes comparable to the granularity.
> >
> > I'll live with it as it is. Sorry for the noise. I note that I think
> > you tried to type in us above, and it shows up as cute little houses
> > on my mailer. :)
> >
> >> Dave, if you'd like this to happen, you'll want to produce experimental
> >> data that show that the timestamps' granularity is an actual limitation.
> >
> > Well, I'd have to rope in some 10GigE users of babel to try it fully
> > and produce patches that did what I wanted to autosense capacity and
> > utilization. Those are still quite feasible, and I figure I could
> > treat long term averages below 1us as a means of better sensing the
> > higher bandwidths.
> >
> > I had done some measurements using other tools (isoburst and some
> > kernel stuff) and got WAY better precision than you got. Jesper got
> > even better, as noted on this thread earlier.
> >
> > So it would be best for me to finally sink the time into doing up high
> > speed network RTT based routing metrics the way I envisioned them 1.5
> > years ago, and perhaps I'll have time this summer to try that,
> > piecemeal, whilst we test the upcoming deployment of all the other
> > stuff.
> >
> > I am happy that 10GigE seems likely to become more common in the
> > future, with dual 10GigE nics on the latest intel socs. I have
> > delusions of connecting up rings of machines again without a central
> > switch, but I guess it's saner to bridge them all together.
> >
> >> -- Juliusz
> >
> >
> >
> > --
> > Dave Täht
> > Let's make wifi fast, less jittery and reliable again!
> >
> > https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/babel-users/attachments/20150701/92b7cb3f/attachment.sig>