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

Dave Hart hart at ntp.org
Mon Feb 13 06:46:14 UTC 2012

On Sun, Feb 12, 2012 at 19:12, Ron Frazier (NTP)
<timekeepingntplist at c3energy.com> wrote:
> Hi all. I want to say thanks to all who responded to the threads I've
> posted, including this one. There were several good replies that I want to
> respond to later. I just had a couple of minutes right now. My thinking on
> this was as follows. I don't mind if NTP is sitting in the system running
> all the time and tweaking the clock. However, on my Windows machines, I
> notice the frequency wandering all over the place and responding to short
> term variances in the computer's usage.

I suspect your wandering frequency is a direct reflection of your
wandering NMEA end-of-line timestamps.  If you want good timekeeping,
my advice is stop screwing around with NMEA alone and get a PPS setup.
 For a hair over $100 there's a guy who will sell you a Garmin GPS 18x
LVC wired up for PC use with a USB cord to draw 5V power and a DB-9
RS-232 connector to get the NMEA sentences and PPS into the PC.  Or
for $35 plus parts and soldering skill, start with the SURE
electronics SkyNet reference design and wire up the PPS as explained
on David Taylor's website.

> So, by polling my GPS every 8
> seconds, I can maintain a few ms of offset without using PPS. I may use PPS
> later. I'm fine with that. However, if I stop NTP for any reason, to reboot,
> to configure, or for testing of other time related things, or for
> programming the GPS, based on my original post, the system clock drifted 1/6
> sec in about a minute of NTP downtime. (Chris Albertson said initial status
> reports from NTP may be invalid.) So, assuming the numbers were even valid,
> if you multiply that out, that's about 240 seconds / day of drift if NTP is
> not running. I was just thinking that, if the drift correction is set
> properly after a long period of testing, and if it persists when NTP is not
> running, even if NTP is not running for a while that it shouldn't drift more
> than a few seconds / day or a very few ms in a minute. So, when NTP is
> started again, there should be very little error that needs correcting. I
> don't know if that clarifies or clouds the water.

It clarifies that you need to do a little more homework IMO.  If you
let crank up the poll interval on your NMEA setup until the frequency
reported by ntpq -c "rv 0 frequency" stops wandering around
appreciably, you'll have a good estimate of the inherent drift of your
PC's clock.  Aside from the PC's (crystal's) inherent drift, the next
biggest factor in the frequency changing is the temperature of the
crystal, being warmed or cooled by changes in its environment, which
is often related to the machine's load causing it to throw off more
heat, and to the ambient temperature where your PC is.  If you can
figure out which crystal is driving Windows' clock and insulate it,
you'll tame the temperature-related variations quite a bit.  The
comment about homework is because PC's drift rate is by far most often
in the +-100 PPM range, usually less than half that.  As mentioned in
another reply there's no way that accounts for your 1/6 sec/min rate,
so you should not assume that's the native drift and let ntpd measure
it for you.  Moreover, when you stop ntpd on Windows (or on a unix
system with precision timekeeping, AKA kernel loop discipline) the
clock continues to be corrected from its native rate by whatever
frequency= correction ntpd was reporting at shutdown.  Only unix
systems lacking kernel loop support or with it disabled by
configuration revert to the PC's native rate after ntpd terminates.

> In terms of the RTC, it would be nice if the computer keeps as good time as
> a $ 10 wristwatch when the computer is shut down, that being, about 1/2 sec
> / day of drift.

That's a tall order.  A $10 wristwatch being worn is effectively an
oven-controlled crystal oscillator (OCXO), with your body being the
oven.  If your PC had an OCXO, it would have a very stable frequency
error allowing ntpd to perform remarkably well.  The next step down
would be if it had a temperature-compensated crystal oscillator

> I wasn't sure if there was any way to discipline the RTC,
> but it sounds like from some of the replies, that there is not. I wasn't
> sure when the RTC is set or read by the system or by NTP.

There's no way to discipline the rate of the RTC on PC that's turned
off.  At best you might be able to compensate for its rate error
shortly after startup, if you're willing to do the measurement and
software development work.  I don't know of a drop-in solution like
that.  The other replies are basically correct that ntpd doesn't
interact with the RTC at all, but there's an exception.  The Windows
port of ntpd has code which effectively sets the RTC to the software
clock when the OS is shut down with ntpd running as a service:

	 * Read the current system time, and write it back to
	 * force CMOS update, only if we are exiting because
	 * the computer is shutting down and we are already
	 * synchronized.
	 if (ntservice_systemisshuttingdown() && sys_leap != LEAP_NOTINSYNC) {
			msyslog(LOG_NOTICE, "system is shutting down, CMOS time reset.");

Dave Hart

More information about the questions mailing list