Red Hat Bugzilla – Bug 242621
timekeeping with ntp problematic
Last modified: 2007-11-30 17:12:06 EST
Description of problem:
The current 2.6.21 kernel has 100x worse timekeeping than previous 2.6.20 kernels.
Version-Release number of selected component (if applicable):
very. observed on i686 and x86_64 versions of the same kernel on 3 different
machines running f7.
Steps to Reproduce:
1. install and run ntp 4.2.4p0 on both the above kernel and the last fc6
2. Compare the ntp offsets with "ntpq -p" after half an hour. Notice the fc7
has 250ms offset while the fc6 system usually has 2ms. This is a 100x worse
and is pretty close to the 500ms that ntpd uses as the hard cut-off for
throwing in the towel. After that 500ms point ntp steps the clock and clears
lots of internal variables.
NTP skates around with +/- 250ms offsets.
NTP on the same hardware used to keep +/- 2ms offsets under previous kernels.
(This has been observed over the course of 2 years under many different
kernels from fc4-fc6.)
Please try booting FC7 kernel with parameters:
(In reply to comment #1)
> Please try booting FC7 kernel with parameters:
> highres=off nohz=off
I just did it. It will take 24 hrs or so for ntp to stabilize on a new drift
Just to do an apples to apples comparison I started running the last fc6 version
of ntpd on all the machines yesterday.
Before I rebooted with these boot flags I noticed that the drift values were the
highest they've ever been, but on two of the machines the offsets had
finally settled a bit. On the third one, a Compaq amd64 laptop, the offset and
drift were still swinging wildly with a 125ms offset.
Tyan 2865 - amd64 - local ntp server 197 PPM 3 ms offset
fc6: -85 PPM
Asus a7v - athlon-32 - leafnode 163 PPM 23 ms offset
Compaq v5000z - amd64 - leafnode 71 PPM
fc6: -19 PPM
Might the fc7 kernel be using the TSC? Both of the amd64 machines are running
cpuspeed and are typically running at half-speed with only brief burst of
Another kernel parameter to try is
This will prevent the tsc from being used. The boot log
(/var/log/dmesg) should show which one is used currently.
I see the above symptoms on my x86_64 F7 install. Using "clocksource=acpi_pm"
has "stabilized" ntp on my system (it would have high jitter and time resets say
every 10-20 minutes). It was originally using TSC. I have not tried "highres=off
Is this still a problem with the latest 2.6.22 update ?
I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the fedora kernel.
I am CC'ing myself to this bug and will try and assist you in resolving it if I can.
There hasn't been much activity on this bug for a while and I am therefore
closing it. If I have erred, please forgive me and re-open with any additional
information you are able to give. I will then try and assist you if I can.
If the problem no longer exists then please close this bug or I'll do so in a
few days if there is no additional information lodged.