On 05/28/12 15:25, Zi Loff wrote:
OK, let me try this again:

Old x86 desktop box (Pentium III @ 500MHz) running 5.0. Machine has been
on 24/7 for the past few years (minus the occasional PSU replacement),
serving mail and http under very light loads.

Its local clock is drifting. A lot.


Without ntpd running:

# date; rdate -nv ntp.phistat.com; sleep 1200; date; rdate -nv \
        ntp.phistat.com
Mon May 28 17:12:07 WEST 2012
Mon May 28 17:11:36 WEST 2012
rdate: adjust local clock by -30.124462 seconds
Mon May 28 17:31:37 WEST 2012
Mon May 28 17:30:59 WEST 2012
rdate: adjust local clock by -37.912744 seconds

So that's about a 38s offset in 20 minutes.


When running ntpd:

# ntpd -sdv
ntp engine ready
reply from 10.17.16.2: offset -293.664414 delay 0.001944, next query 8s
set local clock to Mon May 28 20:01:01 WEST 2012 (offset -293.664414s)
reply from 10.17.16.2: offset -0.253115 delay 0.001728, next query 6s
reply from 10.17.16.2: offset -0.442993 delay 0.001704, next query 5s
peer 10.17.16.2 now valid
reply from 10.17.16.2: offset -0.601451 delay 0.001323, next query 5s
reply from 10.17.16.2: offset -0.759521 delay 0.001758, next query 7s
reply from 10.17.16.2: offset -0.980987 delay 0.001775, next query 6s
reply from 10.17.16.2: offset -1.170839 delay 0.001795, next query 33s
reply from 10.17.16.2: offset -2.213734 delay 0.001826, next query 32s
adjusting local clock by -0.601451s
reply from 10.17.16.2: offset -2.626567 delay 0.002090, next query 34s
reply from 10.17.16.2: offset -3.732722 delay 0.001811, next query 34s
reply from 10.17.16.2: offset -4.802128 delay 0.001883, next query 32s
reply from 10.17.16.2: offset -5.812614 delay 0.001804, next query 32s
adjusting local clock by -0.158070s
clock is now synced
reply from 10.17.16.2: offset -6.666142 delay 0.001363, next query 30s
adjusting local clock by -6.666142s
reply from 10.17.16.2: offset -0.948669 delay 0.001233, next query 30s
reply from 10.17.16.2: offset -1.896441 delay 0.001815, next query 31s
reply from 10.17.16.2: offset -2.876058 delay 0.001887, next query 31s
reply from 10.17.16.2: offset -3.887582 delay 0.001791, next query 34s
reply from 10.17.16.2: offset -4.956985 delay 0.001778, next query 30s
reply from 10.17.16.2: offset -5.904974 delay 0.001913, next query 31s
reply from 10.17.16.2: offset -6.884482 delay 0.002125, next query 34s
reply from 10.17.16.2: offset -7.959015 delay 0.001858, next query 34s
adjusting local clock by -6.359810s
clock is now unsynced
reply from 10.17.16.2: offset -8.084752 delay 0.001801, next query 31s
adjusting local clock by -10.198126s
reply from 10.17.16.2: offset -5.056171 delay 0.001622, next query 34s
reply from 10.17.16.2: offset -6.162315 delay 0.001810, next query 30s
reply from 10.17.16.2: offset -7.105366 delay 0.001770, next query 32s
reply from 10.17.16.2: offset -8.116619 delay 0.001682, next query 30s
adjusting local clock by -14.619296s
...


While the ntpd client was running,

        $ while true; do date; sleep 1; done

showed a steady sequence of seconds, albeit the 'adjustments' claimed by
the ntpd client, although I'm not sure if this is normal or not.

Nevertheless, the offset seems to shrink after each 'ajusting local
clock', judging from the ntpd output, but it just keeps growing in a
kind of a sawtooth pattern.

Is the clock drift just to large for ntpd/adjtime/adjfreq to handle
properly? If so, is there any 'cure' on the software side?

And for extra points:
Any clues on why this is happening? Ageing harware? Faulty PSU?

Many thanks
Ze' Loff

Going way back to my i386 and i486 days, clock drift was sometimes the result of the battery that backed up the bios losing its charge. Some early clocks were like old pre quartz electrical watches. If the battery ran down, the watch ran slowly. You seem to mention that your problem is that the clock is running too fast. I would suspect that this is a hardware issue that you do not want to spend any money on. If you can fix it via a software setting change such as an incredibly frequent cron job, wonderful. If the machine is at all critical, you may want to spend a minimal amount of money to replace it with a new machine.
Ralph Ellis

Reply via email to