Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I using an old version of RHEL that I have recently upgraded from 5.4 to 5.8, with a customised 2.30.9 kernel.

The system clock drifts wildly (> 5 seconds/day) unless it is controlled using an external time source such as NTP.

The hardware clock on the BIOS appears to be much more accurate (< 1 second/week).

I have several Linux boxes available, and if I inspect /etc/adjtime I find that the drift is measured as 0.000004, -0.000050, 10.000107 and -0.000234 seconds / day on different machines with identical Hardware, OS & Applications.

We need to minimise the clock drift when the externel time source is not available.

I have tried various kernel boot options with varying success to improve things:

Initially kernel set up line in /boot/grub/grub.conf

kernel /vmlinuz-2.6.30.9 ro root=LABEL=/ pmtr=0x608 acpi_pm_good clocksource=acpi_pm noapic ide_core.noprobe=1.1 mem=512M ramdisk_size=262144

The clocksource files contain:

cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc acpi_pm jiffies

cat /sys/devices/system/clocksource/clocksource0/current_clocksource
acpi_pm

This drifts at more than 5 seconds/day!

First I tried to enable the HPET:

kernel /vmlinuz-2.6.30.9 ro root=LABEL=/ pmtr=0x608 acpi_pm_good hpet=enable clocksource=hpet noapic ide_core.noprobe=1.1 mem=512M ramdisk_size=262144

The clocksource files contain:

cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc acpi_pm jiffies

cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc

This still seems to drift but at only about 4 seconds/day.

Next I tried turning off tsc: kernel /vmlinuz-2.6.30.9 ro root=LABEL=/ pmtr=0x608 acpi_pm_good notsc divider=10 acpi_pm_good clocksource=acpi_pm noapic ide_core.noprobe=1.1 mem=512M ramdisk_size=262144

The clocksource files contain:

cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc acpi_pm jiffies

cat /sys/devices/system/clocksource/clocksource0/current_clocksource
acpi_pm

This has been running for about a day and there is no noticable drift.

My questions are these:

1) According to this website http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006427 the divider=10 clocksource=acpi_pm requirement was removed at RHEL 5.3, so why does it improve things for RHEL 5.8?

2) What are the effects of the kernel parameters that I have been changing?

3) How accurate is the drift in /etc/adjtime?

4) Is it possible to set up to update hwclock when ntp is working?

5) Is there a better way of achieving what I am trying to do?

thanks

share|improve this question
2  
If this is a production server, I'd rather understand what I'm doing before implementing changes. And if you need accuracy, I'd go with a local NTP server. –  schaiba Mar 13 '13 at 14:27
1  
If the hardware clock is accurate, can't you just call hwclock --hctosys periodically? –  goldilocks Mar 13 '13 at 14:28
2  
To clarify, is this a happening on a guest machine (a virtual machine)? The link to the VMware KB article makes me thing so, but in the rest of the question, it sounds like its not... –  derobert Mar 13 '13 at 16:00
1  
@derobert No, it's not a VM. I have two servers. –  DanS Mar 14 '13 at 9:31
1  
@schaiba This is not yet a deployed system. I am trying to understand the implications beforehand. The requirement is to minimise drift when NTP (including a local server) is unavailable. –  DanS Mar 14 '13 at 9:33
add comment

1 Answer 1

You may want to try a different kernel. The custom-made kernel may have some issues with time-keeping.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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