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.
Cheers, Magnus _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
