[ntp:questions] Sub-millisecond NTP synchronization for local network

Kevin Oberman oberman at es.net
Fri Dec 5 17:40:13 UTC 2008


> Date: Thu, 4 Dec 2008 11:45:10 -0800
> From: "Jeremy Leibs" <leibs at willowgarage.com>
> Sender: questions-bounces+oberman=es.net at lists.ntp.org
> 
> Thanks for the response.
> 
> On Thu, Dec 4, 2008 at 11:13 AM, Unruh <unruh-spam at physics.ubc.ca> wrote:
> 
> > You donot tell us what operating system your robots run. ntpd is not
> > designed for rapid convergence. It was designed for long term stability,
> > and conceptual simplicity. It can take up to 10 hours to compensate for a
> > change in drift rate.
> >
> 
> The computers are running Ubuntu linux 8.04.  I definitely got the
> impression that it was designed for long-term stability over rapid
> convergence.  However, it seems in our case, it is not only converging
> slowly, but also has issues of stability under rapid changes in network
> latency.

If you want to know what time it REALLY is, you probably either need a
hardware clock or you need a better OS. (I only refer to the time
keeping capabilities when I say "better".) Recent changes in the Linux
kernel seem to be an attempt to make Linux useless for keeping good
time. The tickless kernel is a really cool thing, but not for
time. Other clocking changes for power efficiency make attaining good
accuracy difficult, too.

I use FreeBSD for timing and get excellent results. I have a system in
Denver. It gets its time from one of our stratum 1 clocks, all hundreds
of miles away. I restarted ntpd (not the system) about an hour ago and I
see an estimated error of 126 usec. Once the clock has been up for a few
hours, it will drop to under 50 usec. I don't see much jitter,
either. Worst case to any of the 17 stratum 1s I have in the network is
0.149 to Seattle. Of the "selected" clocks, the worst is 0.038. In the
bast case I see 8 ms. delay and jitter of 0.017.

I am puzzled by the reference to "rapid changes in network
latency". This is bad as it would seem to indicate network route
instability. Worse, it might mean that the path is sometimes
asymmetric. This is something NTPD can't handle.

Why the instability?

> I expect the delay over the wireless link is symmetric, but it is entirely
> plausible that it is not.  Are there any good utilities for analyzing the
> directional delays of the network?  Or would the existence of such a tool
> get rid of some of the problems in and of itself.

owamp (a one-way 'ping' system) developed by the Internet2, the main US
Research and Education network, is a good tool for this, but it requires
a tightly synchronized system at each end of the path. This is why we
have those hardware clocks all over the country and are so determined to
run software that keeps the time in sync. You can get owamp at
http://e2epi.internet2.edu/owamp/ 

With owamp, we can detect path changes of <100 usec. and usually
see changes of 10 usec. The higher number is for locations lacking a
hardware time reference.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 224 bytes
Desc: not available
URL: <http://lists.ntp.org/pipermail/questions/attachments/20081205/023e29ec/attachment.pgp>


More information about the questions mailing list