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 _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
