[ntp:questions] improving ntpd performance on Windows

Dave Hart davehart at gmail.com
Fri Feb 27 01:15:54 UTC 2009

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/

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:

shorter, equivalent URL:

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


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:


Dave Hart

More information about the questions mailing list