[ntp:questions] how do I lock in average frequency correction

Dave Hart hart at ntp.org
Mon Feb 13 08:04:16 UTC 2012


On Mon, Feb 13, 2012 at 07:13, David J Taylor
<david-taylor at blueyonder.co.uk.invalid> wrote:
> "unruh" <unruh at invalid.ca> wrote in message
> news:AMVZq.14470$9j5.828 at 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


More information about the questions mailing list