If you're using ntpd on Windows synchonizing to a stable local source (whether refclock or simply ntpd on a heretofore more-stable platform for timekeeping) I would appreciate your help testing my 20090226 test version. The approach to interpolating time using a high-frequency counter has been reworked and on my machines with a precision source, has taken roughly 500us of jitter away.
I'm particularly interested in how it works on systems with 100 Hz system clock interrupts (10 msec period). All my test flock are 64 Hz. This version (and my prior test versions going back weeks) tells you your system clock period in the event log or configured log file: ntpd[30396]: Clock interrupt period 15.600 msec (startup slew 0.2 usec/ period) I'm hoping someone will try the 20090226 version of my code on a system that reports 10.000 msec clock interrupt period. If the new interpolation code falls down on such a system, setting environment variable NTPD_INT_INT=26 or some other value in the range of about 20-50 (milliseconds between counter samples) might tame it. If it works well you should see ntpq report jitter below 0.100 relative to your source after it settles down. ntpd[30396]: System time precision 1.000 msec, min. slew 6.410 ppm/s ntpd[30396]: using native clock directly Note the last line indicates your system will not use interpolation. If you are running on Vista or Windows 7, make sure you use -M (default with Meinberg's installer). That will ensure ntpd detects the fine-grained system time precision at startup and disables interpolation. This is different than 4.2.4p6 and seems to improve performance. See my prior thread mentioning a blunt object. I would have preferred to find an interpolation scheme that works on Vista/Win 7 as well, but neither my tweaks to the old interpolation approach nor experiments with the new one have yet worked at all on Vista. Compared to the released 4.2.4p6, my test version has substantial improvements for serial reference clocks on Windows, including support for PPS on the CD pin, with or without the use of the interrupt-time timestamps available with my patched serial.sys (serialpps.sys). I'm able to keep jitter of a Garmin GPS 18x LVC connected to a dual 400Mhz PII system typically under 20 usec, and probably at worst +/- 200 usec. The reduction in local clock jitter also helps LAN clients stay in better sync with a local server, though to measure how much better it helps if the server is stable. As a test I fiddled with the set of internet servers carefully to minimize clockhopping to generally cause 1 msec or less steps and overall manage to stay within +/- msec of the changing sources. With that machine (running my ntpd) as the relatively stable source, I installed the released 4.2.4p6 using Meinberg's convenient installer on a machine which had not previously run ntpd, and configured it to use only the (somewhat) stable source with maxpoll 6. Just before 1300 UTC I switched in my 20090226 build ntpd.exe and restarted. Take a look at the loopstats graph: http://davehart.net/ntp/refclock/loopstats-20090226-LAN-64s-vegasv2-vs-DLH-QPC-20090226.jpg shorter, equivalent URL: http://tinyurl.com/ao8bhm There's a 15 msec step when 4.2.4p6 is shut down caused by it setting the hardware clock by reading then setting the software clock as part of ntpd shutdown. My version improves on this by only setting the hardware clock when ntpd is stopping due to a computer shutdown when synchronized, so in the case of restarting to upgrade or change configuration, the clock is left finely-tuned. Ongoing slew is also left alone in my version rather than turned off at ntpd shutdown. There's a clear reduction in jitter visible on the right half of that chart. Zooming in on the transition at 1300 UTC makes the scale clearer: http://davehart.net/ntp/refclock/loopstats-20090226-LAN-64s-vegasv2-vs-DLH-QPC-20090226-zoom.jpg http://tinyurl.com/cx7d7l Peter Rosin originally discovered the 1 msec jitter bug in ntpd on Windows in 2003. Details available behind a certificate warning (unless you have the cacert.org root cert installed) at: https://support.ntp.org/bugs/show_bug.cgi?id=216 Enjoy, Dave Hart _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
