[ntp:questions] NTP vs RADclock?

Rick Jones rick.jones2 at hp.com
Fri Jun 8 17:19:13 UTC 2012

unruh <unruh at invalid.ca> wrote:
> On 2012-06-08, Ron Frazier (NTP) <timekeepingntplist at techstarship.com> wrote:
> > I cannot speak to the advanced structure of clock algorithms, but,
> > regarding wifi performance (of ntp), I can testify that it ranges
> > from ok to terrible. I've seen machine to machine ping times on my
> > wifi lan range from a few ms to almost a second. The worst is when
> > 6 or so devices are all communicating on the same wifi channel and
> > my wife's computer is connected to her remote access vpn tunnel
> > for work. I have 3 machines acting as ntp clients and synching to
> > a gps based server every 8 seconds. Those machines generally
> > maintain accuracy of + / - 3 - 10 ms versus the server. That's
> > plenty good for my purposes, but it's nowhere near as good as a
> > gigabit hardwired lan running through a good switch. I could wire
> > all these things up together, but for my purposes, it's not worth
> > the trouble. I prefer the convenience of wifi. However, I'm not
> > sure if it's even possible to do meaningful testing on wifi since
> > the performance can be so variable.

> Actually 100MB ethernet is probably better than gigabit. The gigabit
> stuff has interrupt coallescing which adds random delays to packets,
> which really messes up ntp. I used to have really stable 20us timing
> across the network when I ran 100MB. Now that the switches are
> gigabit and some of the cards are gigabit, I get really really
> terrible behaviour ( sometimes 10ms round trip delays, when the
> minimum is 120us) Gigabit is almost as bad as wireless for timing
> purposes.

In the Linux world at least, ethtool can be your friend, and be used
to disable the interrupt coalescing.  I would expect other
environments to have similar mechanisms.

That said, 10ms for an interrupt coalescing-induced delay seems
unlikely to me - it is possible that some driver/NIC combination has a
really bad setting that high, but it seems unlikely.  Again, if in the
Linux world, ethtool can be your friend, this time showing you the
interrupt coalescing settings for a given NIC.

I doubt that gigabit switches do such coalescing.  And the coalescing
(like JumboFrames) is an "after market" implementation detail (not
part of the IEEE standard) thing.  As such, it might be more accurate
to say that Gigabit Ethernet NICs can be almost as bad as wireless.
It is entirely possible/likely that a "Gigabit" NIC, operating in 100
Mbit/s mode, will still do the interrupt coalescing.

>From what little I know about wireless, it will probably always be
something of a mess, but bufferbloat doesn't make it any better.

rick jones
Process shall set you free from the need for rational thought. 
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

More information about the questions mailing list