Bug 242621 - timekeeping with ntp problematic
timekeeping with ntp problematic
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2007-06-05 01:25 EDT by Wolfgang Rupprecht
Modified: 2007-11-30 17:12 EST (History)
6 users (show)

See Also:
Fixed In Version: 2.6.22
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-09-13 16:54:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Wolfgang Rupprecht 2007-06-05 01:25:28 EDT
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):
2.6.21-1.3194.fc7 x86_64

How reproducible:
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
   one (2.6.20-1.2952.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.

Actual results:

NTP skates around with +/- 250ms offsets.

Expected results:

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

Additional info:
Comment 1 Chuck Ebbert 2007-06-05 12:28:14 EDT
Please try booting FC7 kernel with parameters:

    highres=off nohz=off
Comment 2 Wolfgang Rupprecht 2007-06-06 19:24:42 EDT
(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
                                         fc6:  ??? 
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
Comment 3 Chuck Ebbert 2007-06-06 20:07:14 EDT
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.
Comment 4 Zing 2007-06-13 14:28:12 EDT
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
Comment 5 Dave Jones 2007-08-29 14:36:06 EDT
Is this still a problem with the latest 2.6.22 update ?
Comment 6 Christopher Brown 2007-09-13 16:54:26 EDT

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.


Note You need to log in before you can comment on or make changes to this bug.