[time-nuts] Tracking NTP displacement and correlationbetweentwo clients.

Magnus Danielson magnus at rubidium.dyndns.org
Fri Oct 5 18:38:48 EDT 2012

On 10/05/2012 08:23 PM, Christopher Brown wrote:
> That is his point.
> Initial time comes from MB clock.
> System (OS) time is set from that at boot.
> During NTP startup for a client it is normal to do a "ntpdate" to hard
> set the OS clock (direct one time set).
>  From there ntpd would track and adjust.
> HOWEVER, there are limits to how much ntpd will skew the clock to keep
> it in sync.  If the OS clock is drifting faster than this amount ntpd
> will not be able to adjust it fast enough.
> Think bad hardware or buggy BIOS, OS clock ends up running too fast or
> too slow for ntpd to compensate for.

Buggy OS has been known to do this before. Lack of kernel support is a 
real killer. What are you running?

There is another point to make for servers. Since NTP will not trust 
clocks being more than +/- 15 min away from the system time, if the HW 
clock drifted to far away over the months and maybe years since boot, 
then when it initiate the system time on next boot it may lock the NTP 
training out. A good way to mitigate this is to have a cron job to 
transfer system time over to HW clock time regularly, maybe once a week 
or once a month. That way, if the server goes down uncontrolled (at 
which time it is expected to do this, if you are lucky) the HW clock 
won't be too far off anyway for things to resolve itself by automagic.

Oh, I learned this the hard way when we had a power failure in the 
computer hall.


More information about the time-nuts mailing list