[time-nuts] Tracking NTP displacement and correlationbetweentwo clients.
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
More information about the time-nuts