Runaway clock

[Jaglover]

I trying to figure out why NTP can't keep correct time. As you can see I'm switching between clocksources and restarting openntp but it does not make any difference. What am I missing here? I have three clocksources available: tsc, hpet, acpi_pm, switching between them makes no difference.

Code: Select all

Feb  5 17:05:31 server ntpd[6255]: adjusting local clock by -7.758234s
Feb  5 17:09:15 server ntpd[6255]: adjusting local clock by -7.787028s
Feb  5 17:10:01 server cron[6321]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons)
Feb  5 17:13:38 server ntpd[6255]: adjusting local clock by -7.709431s
Feb  5 17:15:12 server ntpd[6255]: adjusting local clock by -7.787293s
Feb  5 17:18:58 server ntpd[6255]: adjusting local clock by -7.744719s
Feb  5 17:20:01 server cron[6341]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons)
Feb  5 17:21:01 server ntpd[6255]: adjusting local clock by -7.805891s
Feb  5 17:23:49 server kernel: Switching to clocksource acpi_pm
Feb  5 17:23:56 server ntpd[6256]: ntp engine exiting
Feb  5 17:23:56 server ntpd[6255]: Terminating
Feb  5 17:23:56 server ntpd[6385]: ntp engine ready
Feb  5 17:24:16 server ntpd[6385]: peer 192.168.2.250 now valid
Feb  5 17:25:12 server ntpd[6384]: adjusting local clock by -7.834412s
Feb  5 17:25:43 server ntpd[6384]: adjusting local clock by -7.841991s
Feb  5 17:28:57 server ntpd[6384]: adjusting local clock by -7.815725s
Feb  5 17:30:01 server cron[6403]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons)
Feb  5 17:31:03 server ntpd[6384]: adjusting local clock by -7.858843s
Feb  5 17:34:14 server ntpd[6384]: adjusting local clock by -7.867799s
Feb  5 17:37:22 server ntpd[6384]: adjusting local clock by -7.879406s
Feb  5 17:40:01 server cron[6498]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons)
Feb  5 17:40:32 server ntpd[6384]: adjusting local clock by -7.800904s
Feb  5 17:41:06 server ntpd[6384]: adjusting local clock by -7.852644s
Feb  5 17:41:40 server ntpd[6385]: ntp engine exiting
Feb  5 17:41:40 server ntpd[6384]: dispatch_imsg in main: pipe closed
Feb  5 17:41:40 server ntpd[6384]: Lost child: child exited
Feb  5 17:41:40 server ntpd[6384]: Terminating
Feb  5 17:41:40 server ntpd[6543]: ntp engine ready
Feb  5 17:41:58 server ntpd[6543]: peer 192.168.2.250 now valid
Feb  5 17:42:52 server ntpd[6542]: adjusting local clock by -7.925844s
Feb  5 17:43:23 server ntpd[6542]: adjusting local clock by -7.931544s
Feb  5 17:46:37 server ntpd[6542]: adjusting local clock by -7.904074s
Feb  5 17:48:47 server ntpd[6542]: adjusting local clock by -7.930368s
Feb  5 17:50:01 server cron[6576]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons)
Feb  5 17:51:27 server ntpd[6542]: adjusting local clock by -7.991160s

[wcg]

Does it ever actually make the adjustment, or is it simply
reporting approximately the same clock error that it
detected the first time it ran?

What happens if you stop ntpd and run some kind of
command line ntp client with a verbose option, connecting
to [your country code].pool.ntp.org?

(Does it succeed or does it report an error?)

[Jaglover]

Thanks for reply
Below you can see after I ran ntpdate it started drifting away (slowly but surely) again. I have to admit I do not understand openntpd messages. I think when it's printing 'adjusting' then it actually is an attempt to adjust, no telling wheter it was successful or not.

Code: Select all

Feb  8 16:06:29 server ntpd[11490]: adjusting local clock by -21.492489s
Feb  8 16:07:33 server ntpd[11490]: adjusting local clock by -21.516390s
Feb  8 16:09:10 server ntpd[11490]: adjusting local clock by -21.590783s
# at this point I ran ntpdate
Feb  8 16:12:32 server ntpd[11487]: clock is now synced
Feb  8 16:12:32 server ntpd[11490]: adjusting local clock by -0.052568s
Feb  8 16:14:05 server ntpd[11487]: clock is now unsynced
Feb  8 16:14:05 server ntpd[11490]: adjusting local clock by -0.058665s
Feb  8 16:18:55 server ntpd[11487]: clock is now synced
Feb  8 16:18:55 server ntpd[11490]: adjusting local clock by -0.088175s
Feb  8 16:20:01 server cron[5919]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons)
Feb  8 16:21:34 server ntpd[11487]: clock is now unsynced
Feb  8 16:21:34 server ntpd[11490]: adjusting local clock by -0.150751s
Feb  8 16:25:50 server ntpd[11490]: adjusting local clock by -0.058194s
Feb  8 16:26:54 server ntpd[11490]: adjusting local clock by -0.167966s
...
Feb  8 17:24:12 server ntpd[11490]: adjusting local clock by -0.279311s
Feb  8 17:26:22 server ntpd[11490]: adjusting local clock by -0.321602s
Feb  8 17:29:38 server ntpd[11490]: adjusting local clock by -0.333120s

[wcg]

That is a steady and persistent clock drift, but at least
you know the clock works and the adjtime() function
works. Could be the clock chip, could be the power supply,
could be software, but that particular software in the kernel
gets tested fairly thoroughly. You can try a different
power supply and run nptdate again to see if that
mitigates the clock drift any.

Otherwise, I suggest that you simply have to live with
frequent adjustments larger than you would like. I use
openrdate from cron, and one system would have
huge clock drift whenever the power supply was unplugged
from the motherboard, despite a new CMOS battery.
I had to lose the "-a" ("adjust in small increments") option
to openrdate and simply let it jump to the correct time
whenever I restarted it after unplugging the power supply
to install some different peripheral hardware or dram.

[your_WooDness]

Hey,

had a similar problem with an AMD based server and an CentOS where the clock had to resync very often. For me it fixed the problem by appending "disable_timer_pin_1" to the kernel in grub.

w00d