4

My current system drifts from the hwclock and ntpd dramatically. I've looked at many forums and posts online and on SF, but haven't found a suitable solution.

Here is my ntpq -pn output:

   remote           refid      st t when poll reach   delay   offset  jitter
=============================================================================
 122.226.192.4   66.220.9.122     2 u   30   64    3   53.734  146507. 127822.
 120-88-46-10.sn 158.43.128.33    2 u   33   64    3  150.373  12823.5 127821.
 suisho.attritio 133.100.9.2      2 u   29   64    3   34.351  148556. 133910.
 123.146.124.27  61.153.197.226   3 u   27   64    3   21.123  152572. 133909.
 114.80.81.1     204.152.184.72   2 u   29   64    3   55.605  148520. 129851.

As of now my 'hwclock' says:

Fri 25 Mar 2011 03:27:06 PM CST -0.048504 seconds

My 'date' says:

Fri Mar 25 15:21:17 CST 2011

They are off by about 6 minutes and I just did an ntpdate -u about 10 minutes ago...

Also, I'm currently running Centos 5.5 32-bit with kernel 2.6.18-194.32.1.el5

What should I do to fix the system clock? The hardware clock seems to be working fine.

EDIT: Added the new values in my kernel boot line as described by Sacx. Though the delay is a lot better after reboot, but after 16 hours the time is still slow by 35 minutes. Just checked my current_clocksource and it says tsc still. I tried changing it to acpi_pm but it doesn't work. Looking at my available_clocksource, it shows: jiffies tsc pit

1

Add this parameters at kernel boot line

notsc divider=10 clocksource=acpi_pm

and restart your system. This is related to RHEL 5 Hyper-V Guest - Cannot sync with NTP after kernel upgrade

  • This seems to be a viable solution so far. The system clock hasn't had any noticeable drift yet. I will wait until tomorrow to see if everything stays normal; then come back and pick your answer as the correct answer :) Thanks! – samxli Mar 25 '11 at 9:08
  • It's been 16 hours and the time drifted about 35 minutes. NTP still has not synced with any of the servers. My current /sys/devices/system/clocksource/clocksource0/current_clocksource shows tsc. – samxli Mar 26 '11 at 2:16
  • finally got it working after tweaking some more parameters in the boot line :) – samxli Mar 26 '11 at 13:14
  • @samxli how come you didn't post what those parameters were? I've been trying to find a solution to clock drift for a long time now, and still nothing has worked. fc17-32bit – insaner Oct 13 '17 at 22:01
0

You can try using another NTPd, such as OpenBSD's one: openntpd

0

Maybe this helps someone. We had the same problem recently and got the drifting into a reasonable range after having installed adtimex.

aptitude install adjtimex

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.