Time running too fast - uhm??

[Geert Janssens]

I've heard that sometimes it's the onboard battery. If it's dead, time 
loses accuracy.

Maybe worth to check.

Geert

Alexander Holst wrote:
> Hi List,
> 
> I did post this issue a few days ago, but never saw any reaction to it.
> 
> I still find my log file on only _one_ particular machine full of 
> entries like:
> 
> Jan 30 09:36:08 wwwsvr02 ntpd[5356]: time reset -1.123347 s
> Jan 30 09:36:08 wwwsvr02 ntpd[5356]: synchronisation lost
> Jan 30 09:40:33 wwwsvr02 ntpd[5356]: time reset -0.856180 s
> Jan 30 09:40:33 wwwsvr02 ntpd[5356]: synchronisation lost
> Jan 30 09:49:16 wwwsvr02 ntpd[5356]: time reset -1.427873 s
> Jan 30 09:49:16 wwwsvr02 ntpd[5356]: synchronisation lost
> Jan 30 09:54:49 wwwsvr02 ntpd[5356]: time reset -0.965880 s
> Jan 30 09:54:49 wwwsvr02 ntpd[5356]: synchronisation lost
> Jan 30 10:03:39 wwwsvr02 ntpd[5356]: time reset -1.282842 s
> Jan 30 10:03:39 wwwsvr02 ntpd[5356]: synchronisation lost
> Jan 30 10:14:23 wwwsvr02 ntpd[5356]: time reset -0.460586 s
> Jan 30 10:14:23 wwwsvr02 ntpd[5356]: synchronisation lost
> Jan 30 10:18:50 wwwsvr02 ntpd[5356]: time reset -1.657446 s
> Jan 30 10:18:50 wwwsvr02 ntpd[5356]: synchronisation lost
> 
> My /etc/ntp/drift looks like:
> [user@host user]$ cat /etc/ntp/drift
> -262.668
> 
> I have never seen values like that in a drift file. My question is: why 
> is the systemtime running that fast?
> 
> Funny enough, the hardware clock runs pretty normal as you can see:
> 
> [holale@wwwsvr02 holale]$ hwclock -r; date
> Thu 30 Jan 2003 04:46:22 PM CET  -0.276448 seconds
> Thu Jan 30 15:46:21 CET 2003
> [holale@wwwsvr02 holale]$ hwclock -r; date
> Thu 30 Jan 2003 04:46:36 PM CET  -0.610453 seconds
> Thu Jan 30 15:46:35 CET 2003
> [holale@wwwsvr02 holale]$ hwclock -r; date
> Thu 30 Jan 2003 04:46:39 PM CET  -1.010177 seconds
> Thu Jan 30 15:46:38 CET 2003
> [holale@wwwsvr02 holale]$ hwclock -r; date
> Thu 30 Jan 2003 04:46:42 PM CET  -0.970197 seconds
> Thu Jan 30 15:46:41 CET 2003
> [holale@wwwsvr02 holale]$ hwclock -r; date
> Thu 30 Jan 2003 04:46:44 PM CET  -0.297311 seconds
> Thu Jan 30 15:46:43 CET 2003
> [holale@wwwsvr02 holale]$ hwclock -r; date
> Thu 30 Jan 2003 04:46:48 PM CET  -0.072218 seconds
> Thu Jan 30 15:46:47 CET 2003
> [holale@wwwsvr02 holale]$ hwclock -r; date
> Thu 30 Jan 2003 04:46:50 PM CET  -0.361500 seconds
> Thu Jan 30 15:46:49 CET 2003
> [holale@wwwsvr02 holale]$ hwclock -r; date
> Thu 30 Jan 2003 04:46:52 PM CET  -0.623877 seconds
> Thu Jan 30 15:46:51 CET 2003
> [holale@wwwsvr02 holale]$ hwclock -r; date
> Thu 30 Jan 2003 04:46:54 PM CET  -0.151135 seconds
> Thu Jan 30 15:46:53 CET 2003
> [holale@wwwsvr02 holale]$ hwclock -r; date
> Thu 30 Jan 2003 04:46:57 PM CET  -0.848402 seconds
> Thu Jan 30 15:46:56 CET 2003
> [holale@wwwsvr02 holale]$ hwclock -r; date
> Thu 30 Jan 2003 04:46:59 PM CET  -0.802279 seconds
> Thu Jan 30 15:46:58 CET 2003
> 
> The gap increases quite noticably, untill ntpd tries to slew the time 
> again - but somehow can't keep up with that, so roughly every five 
> minutes it has to force the time back.
> 
> I have several other Macs (G3, 7500, ANS) that do not show this 
> behaviour (the machine in question is a PM8200). What parameters are 
> responsible for keeping the systemtime accurate? What makes the machine 
> miscalculate the systemtime, so ntpd has to reset the clock almost every 
> five minutes?
> 
> If it wasn't a host that receives logging info from other hosts, I 
> wouldn't mind the time issue.
> 
> Any ideas appreciated,
> Alex
> 
> Alexander Holst
> Pforzheim University of Applied Sciences
> <holst@fh-pforzheim.de>
> ph: +49 [0]7231 28-6837
> fx: +49 [0]7231 28-6040
> 
> _______________________________________________
> yellowdog-general mailing list
> yellowdog-general@lists.terrasoftsolutions.com
> http://lists.terrasoftsolutions.com/mailman/listinfo/yellowdog-general
> 
>