5

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

Improve this question
4

3 Answers 3

Reset to default
2

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

Improve this answer
4
  • 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, 2011 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, 2011 at 2:16
  • finally got it working after tweaking some more parameters in the boot line :)
    – samxli
    Mar 26, 2011 at 13:14
  • 1
    @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, 2017 at 22:01
1

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

Improve this answer
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
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .