Major Clock Drift

[gaf at blu.org (Jerry Feldman)]

On Mon, 30 Aug 2004 10:58:56 -0400
Josh Pollak <pardsbane at offthehill.org> wrote:

> Yeah, NFS, Make, and our source control (AccuRev) are all super
> grumpy. I started running ntpd, which has 'fixed' the problem.
All computer clocks drift. As I mentioned, every system using the same
source control should be fully synchronized. Even if your clock did not
drift, if you manually set it, other systems could be off by small
amounts. All code management systems are very picky about time. 
 
> I don't know if I can afford the time to leave the PC in CMOS, but 
> checking hwclock should have the same effect, no?
Linux should not update or sync with the hwclock unless there is
something that causes it to do so. While I have not looked at the clock
module in Linux specifically, in general it is a counter that is updated
based on clock ticks. There are a couple of different tests you can use:
1. With ntpd running: Sample hwclock. If there is a discrepancy over
time, then the RTC is off.
2. With ntpd not running: Sample hwclock, and if there is a discrepancy,
it is the clock tick. 

Just remember that the RTC is used on boot and normally set at shutdown,
but is not generally used while the system is running. I suspect that
the RTC is probably ok, but the clock interrupt mechanism is causing the
drift. 
-- 
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/b18a2e7f/attachment.sig>