# 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.

```
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  :Smile: 

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.   :Confused: 

```
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

----------

