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

Richard B. Gilbert rgilbert88 at comcast.net
Sun Feb 12 22:52:22 UTC 2012

On 2/12/2012 2:03 PM, Chuck Swiger wrote:
> On Feb 12, 2012, at 9:36 AM, unruh wrote:
>> On 2012-02-12, Ron Frazier (NTP)<timekeepingntplist at c3energy.com>  wrote:
>>> It is my understanding that NTP is continuously making small changes to
>>> the software clock to keep the timing accurate while the os is running.
>>> 95% of the time, my computers are doing the same thing and 95% of the
>>> time, I'm doing the same thing with the computers.  Therefore, over a
>>> long time interval, the interrupt usage should be similar, and over a
>>> long time interval, the correct clock frequency to maintain accuracy
>>> should be similar.
>> That above paragraph is not comprehensible to me. Yes, ntp is making
>> small changes to the software clock frequency.
>> What does your doing with the computer have to do with interrupt usage?
> I also found it a bit difficult to understand the concern being asked, but:
> - some operating systems have or had bugs where they will miss timer interrupts and cause the kernel "clock" to run more slowly (ie, a firewall/router running at high packets-per-second and seeing a huge # of network interrupts)
> - doing some long, max-CPU activity like "transcoding a movie" will heat up the system and the crystal
>> The clock crystal ages, and suffers internal crystal "cracks"
>> migrations, etc, which change the frequency of the crystal. Thus even in
>> a temperature controlled oven, the crystal frequency will change, but
>> much of the crystal frequency change is driven by temperature changes.
> Agreed, temperature swings will have a major impact on the crystal frequency.
>>> I also would like to understand how ntp interacts with the Real Time
>>> Clock.  I think I've read that either NTP or the OS (I don't know which)
>> It depends. ntp itself does not intereact with the real time clock at
>> all. However, under Linux, if the system clock thinks it is synced, it
>> resets te real time clock every 11 min to the system clock. also, in the
>> OS, hwclock is run at the end to reset the real time clock to the system
>> clock.
> Yes, ntpd does not interact with the hardware TOY/RTC at all.  Whether the system
> itself updates the BIOS/firmware/EFI RTC is both operating system specific and
> hardware specific.
>>> will save the time to the RTC when shutting down and retrieve the time
>>> from the RTC when booting up.  I'd like to know if this is true, first
>>> of all, and I'd like to know if it makes any corrections to the clock
>>> rate of the RTC so it is more accurate.
>> No. it does not, especially with that 11 minute mode, it cannot figure
>> out the rate of the clock. If you switch off the 11 min mode, by
>> constantly telling the system clock it is not in sync, then you can use
>> some versions of hwclock to measure the drift rate of the rtc.
>> But there is absolutely no way of altering the rate of the rtc without
>> unsoldering your clock crystal from the motherboard and putting in a new
>> one, or putting in a trimming capacitor, and adjusting it by hand.
> You might be able to improve the stability of the crystal by ensuring good
> airflow and cooling via HVAC as needed.  And I suppose you could adjust the
> rate by changing the HVAC set-point, but I don't think the benefit is worth it.

Rather than cooling the crystal it's customary to to put the crystal in 
an "oven".  This is not the oven usually used for cooking.  What it does 
is to heat the crystal to a temperature that can be maintained 24x7
and will be a little warmer than the highest temperature that can be 
expected naturally.  A value in the range 120 to 130 degrees F could be 


More information about the questions mailing list