> Date: Thu, 4 Dec 2008 11:45:10 -0800 > From: "Jeremy Leibs" <[EMAIL PROTECTED]> > Sender: [EMAIL PROTECTED] > > Thanks for the response. > > On Thu, Dec 4, 2008 at 11:13 AM, Unruh <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
pgp0reUTBheFp.pgp
Description: PGP signature
_______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions