[ntp:questions] Are there algorithm differences between 4.2.4 and 4.2.5?

Dave Hart davehart at gmail.com
Mon Mar 30 07:57:35 UTC 2009


David J Taylor has hit on an apparent regression in timekeeping
between 4.2.4 and 4.2.5.  He's posted some graphs at:

http://www.satsignal.eu/ntp/V4.2.4.vs.V4.2.5.html

While I encourage interested parties to read the entire page, I draw
your attention in particular to the three large graphs at the bottom
of the page, showing a PC of mine running one of my later 4.2.4-DLH-
QPC builds with new Windows interpolation code, which also bypasses
interpolation on Vista machines where the native clock precision is
too fine for the interpolation approach to work.  Toward the end of
the day, I switched it to a 4.2.5-based build with my interpolation
code.  Both versions disabled interpolation and used the native
Windows clock directly in ntpd.  Typically on this machine I see
"precision = 500.100 usec" logged at startup, which was true for the
4.2.5 run started during this graphed period.  The 4.2.4 run preceding
it had logged "precision = 1000.000 usec"  I don't believe the
difference is important here, as David J Taylor's Vista box showed the
same deterioration in timekeeping and his had logged around 1 msec
precision for both 4.2.4 and 4.2.5 runs graphed on that page.

The deterioration is pronounced.  In contrast, the rest of David J
Taylor's machines (all but Gemini on that page) which are running with
much higher precision (a few microseconds instead of a millisecond)
the performance looks pretty much the same between 4.2.4 and 4.2.5.
I'm guessing a precision as low as 2**-10 is rarely tested with -dev
ntpd.  If you have a non-Windows machine that reports precision = 500
usec or higher (in syslog at startup) or precision=-10 or lower (ntpq -
c rv), I would love to hear if you see a similar difference in
performance switching between recent 4.2.4 and 4.2.5 releases.

Since the release of 4.2.4 over two years ago, Dr. Mills substantially
churned the protocol code in ntpd clearing weeds, including renaming a
number of identifiers in the source.  I'm all in favor of the changes,
but they do complicate tracking down this regression, as diffs fail to
hone in on functional differences buried among the larger churn.
Harlan Stenn mentioned the NTP simulator to me privately when I
pointed out the deterioration.  I appreciate the suggestion, and I
suspect if I manage to find a regression myself, the simulator will
play a big role.

Cheers,
Dave Hart




More information about the questions mailing list