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