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

unruh unruh at invalid.ca
Sun Feb 12 21:01:20 UTC 2012

On 2012-02-12, Ron Frazier (NTP) <timekeepingntplist at c3energy.com> wrote:
> On 02/12/2012 05:45 AM, David Woolley wrote:
>> David Lord wrote:
>>> Ntpd does not interact with my systems RTCs. There are
>>> probably some utilities that can set the RTC to current
>>> time or set the time from the RTC but I don't know of
>>> any for my systems. Chrony on Linux is able to use the
>>> RTC and compensate for periods when the system is not
>>> running.
>> I don't think he wants to do this. He wants a time discipline system, 
>> that cannot be ntpd, that has a hard wired (pre-calculated) frequency 
>> correction that it never updates. Most of the time only the frequency 
>> correction should be applied. If the offset becomes too high, it 
>> should be rapidly cleared by something like the ntpd stepout 
>> mechanism, not the normal PLL.
> 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. 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.

The problem on windows is I believe that there is no way to alter the
system clock rate. On linux, one can permanantly alter the rate at which
the clock ticks, and ntpd can use that feature, so that the clock will
keep ticking at the corrected rate even when ntpd is not running.
(chrony always does that on Linux). Unfortunately if the operating
system does not offer that option, then whenever ntpd is not in there
altering the rate, it will tick at its usual bad rate. Go talk to Bill
Gates about that. 
Note that 1/6 sec per minute is 3000PPM. the computer's clock reaally
really should not be that far off (and ntpd cannot correct that large a
rate). Normal computers run with a rate error of a few 10s PPM. Ie, 1
sec/day rate errors. 

> 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 

Talk tot he manufacturers. I would expect that the cost of the rtc is on
the order of a few cents, so do not expect the highest accuracy from

> 1/2 sec / day of drift. 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. I 
> have to review all the replies on this thread when I have a bit more time.
> Sincerely,
> Ron

More information about the questions mailing list