Major Clock Drift

[gaf at blu.org (Jerry Feldman)]

On Mon, 30 Aug 2004 09:24:27 -0400
Josh Pollak <pardsbane at offthehill.org> wrote:

> Thats over a full minute of drift in one week. I find that hard to 
> believe. Perhaps the RTC is inaccurate as a trade off for providing so
> many ticks per second, but I've never seen a computer's clock drift
> this quickly, even when we weren't running NTP.
There are two issues involved. The RTC clock in your computer starts the
time when booted, but the OS maintains its own time based on a clock
tick interval that drives interrupts. Linux sometimes can store its
concept of time on shutdown. 

Take a look at the hwclock(8) command. 

One definitive method to really check the clock is to leave your
computer in the CMOS setup mode or boot an OS that does not muck with
the clock, like (ugh) MS-DOS. The CMOS setup will display the hardware
clock. So, figure out what your drift is over a fixed period of time,
bring it up under setup or DOS, record the time, and take a sample at
some later time. It could be that the RTC is reasonable, but the clock
tick interval is off causing the drift.

The bottom line is if you are doing some shared development, it is
important to sync the shared systems otherwise code management systems
and Make(1) have trouble.  
-- 
Jerry Feldman <gaf at blu.org>
Boston Linux and Unix user group
http://www.blu.org PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.blu.org/pipermail/discuss/attachments/20040830/ff3aaba5/attachment.sig>