On Mon, Feb 13, 2012 at 07:13, David J Taylor <david-tay...@blueyonder.co.uk.invalid> wrote: > "unruh" <un...@invalid.ca> wrote in message > news:AMVZq.14470$9j5....@newsfe09.iad... > >> The problem on windows is I believe that there is no way to alter the >> system clock rate.
I know there's a popular religious belief among some techies that Windows is automatically inferior to unix in every way, but let's stick to facts, not religion, please. Fact: Most unix systems have far superior timekeeping to Windows, thanks largely to PHK and DLM's works. DLM for ntpd and for precision kernel timekeeping (AKA microkernel, nanokernel), and PHK for high-precision system clocks built on one of several high-frequency counters available on most systems as well as his work identifying problems with the original microkernel code and his collaboration with DLM on the nanokernel work. Also fact: Windows is superior to a few unix systems out there in a much less dramatic fashion, in that its API SetSystemTimeAdjustment alters the system clock rate persistently (as does precision kernels' ntp_adjtime, which at least one person here is constantly referring to as adjtimex, due to a baffling renaming of the syscall, which is exposed by glibc as both adjtimex and ntp_adjtime). Inferior unix systems having only adjtime are likely to suffer a 1 s. period sawtooth error due to the interface of adjtime being "slew away X microseconds by running your clock 500 PPM fast or slow until completed", which is used by ntpd's daemon loop once per second, resulting in a too-fast correction for a bit, then a too-slow (natural rate) remainder of each second. Harlan and I have been talking about an alternative to adjtime() for non-precision kernels which would set an ongoing clock rate correction a la Windows, curing the sawtooth and allowing the clock to freewheel at the last corrected rate after ntpd terminates, as with the precision kernel timekeeping extensions. Such an alternative would be far easier to implement and audit than the full kernel loop discipline, so might find utility in embedded systems, for example. Sad fact: No matter how well ntpd is able to discipline the clock on Windows, other apps are generally stuck with a low-precision system clock. It may be sync'd to within less than 100 usec to UTC, but when apps read the clock using Windows APIs, it's truncated to a precision between 0.5 and 15.6 msec. Higher resolution clock reading means requiring ntpd be running and querying it in SNTP fashion. I've reached out to Microsoft repeatedly on this issue trying to improve the situation, but the response so far has been mostly disappointing. The last response I got was promising but the person seemed to feel so fearful of their losing their job they wouldn't tell me anything at all about future plans, and by personal experience I know once they're far enough along the product cycle for the next Windows to feel at liberty to start talking it's too late to hope for any changes in that next release. I don't have much optimism, because it's easy to be a chickenshit wimp and say "our customers aren't demanding this, and we don't want to invest resources and/or risk breakage for some few time nuts." > Directly on Windows, no, but this facility /does/ exist in the Windows port > of NTP to address clocks which are stable, but near or outside the 500 ppm > error allowed: > > "Set the system environment variable: NTPD_TICKADJ_PPM to the value you > need. On Windows XP, this is through the Control Panel. System..., System, > Advanced..., Environment variables button, System variables. Add a New > system variable, with the name NTPD_TICKADJ_PPM and the value 500 (or -500 > if your ntp.drift was limiting at its negative extreme)." The same facility is available on many unix systems via the tickadj utility provided by the NTP project, and/or other programs accessing the same functionality. NTPD_TICKADJ_PPM is more fine-grained but as the name implies is intended to provide tickadj-like capability. Cheers, Dave Hart _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions