Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
DescriptionMiroslav Lichvar
2018-04-10 10:59:14 UTC
Description of problem:
There is a long-standing issue with the kernel's internal steering of the system clock according to adjustments made by NTP/PTP daemons. As the updates of the clock may be irregular due to nohz, the frequency is changed slowly and in a limited range to avoid an instability, which was an issue in the past. The slow response may prevent the NTP/PTP daemons from controlling the system clock with a better stability/accuracy than few tens or hundreds of nanoseconds.
Recent changes in the upstream code fix the issue by using a division to determine the clock multiplier directly from the frequency set by the NTP/PTP daemons and simplifying the error correction to a +1/0 adjustment of the multiplier. This requires the GENERIC_TIME_VSYSCALL_OLD code to be removed from the kernel. For powerpc there is bug #1131131.
Upstream commits:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c2cda2a5bda9f1369c9d1ab54a20571c13cf2743https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=78b98e3c5a66d569a53b8f57b6a698f912794a43
Version-Release number of selected component (if applicable):
kernel-3.10.0-857.el7.x86_64
How reproducible:
always
Steps to Reproduce:
1. make sure /sys/devices/system/clocksource/clocksource0/current_clocksource shows tsc
2. stop any services controlling the clock (e.g. ntpd, chronyd, ptp4l, phc2sys)
3. compile and run tools/testing/selftests/timers/freq-step.c from the upstream kernel tree (you may need to increase MAX_PRECISION or disable KPTI)
Actual results:
Step 1st interval 2nd interval
Freq Dev Max Freq Dev Max
40960 +0.146 1 3 +0.146 1 2 [OK]
40960 +0.001 5 35 +0.000 1 2 [OK]
40960 +3.346 25352 172950 +0.045 1 5 [OK]
40960 +0.161 2 12 +0.161 1 3 [OK]
40960 +3.897 23014 156184 +0.136 1 4 [OK]
640 +0.104 1 2 +0.103 3 16 [OK]
640 -0.119 4 28 -0.010 19 64 [OK]
640 +0.153 1 2 +0.118 50 128 [OK]
640 +0.029 1 3 +0.029 1 2 [OK]
640 +0.102 1 3 +0.102 1 2 [OK]
10 +0.006 9 28 -0.000 2 5 [OK]
10 +0.009 20 76 +0.000 2 5 [OK]
10 +0.000 2 5 -0.000 2 4 [OK]
10 -0.000 1 4 -0.000 1 4 [OK]
10 +0.001 3 10 +0.000 2 5 [OK]
Expected results:
Much smaller errors like this:
Step 1st interval 2nd interval
Freq Dev Max Freq Dev Max
40960 +0.000 2 5 -0.000 2 5 [OK]
40960 -0.000 2 5 -0.000 3 8 [OK]
40960 -0.000 3 7 +0.000 3 6 [OK]
40960 +0.000 3 6 -0.000 2 6 [OK]
40960 -0.000 2 5 +0.000 3 7 [OK]
640 +0.001 2 9 -0.000 2 5 [OK]
640 -0.000 3 6 +0.000 2 5 [OK]
640 -0.001 2 4 +0.000 1 3 [OK]
640 -0.000 2 5 +0.000 2 4 [OK]
640 +0.000 3 6 -0.000 3 6 [OK]
10 -0.000 2 5 +0.000 2 5 [OK]
10 -0.000 2 5 +0.000 2 5 [OK]
10 +0.000 2 5 +0.000 2 5 [OK]
10 +0.000 2 5 +0.000 2 5 [OK]
10 +0.000 3 12 +0.000 4 11 [OK]
------- Comment From seg.com 2019-05-30 20:16 EDT-------
Not clear to me whether this is already fixed and we should close or not already fixed and we're not going to bother for RHEL 7, at a minimum.
We cannot fix this without bug #1131131, which was closed as WONTFIX. The nohz=off kernel option is recommended as a workaround for a highly accurate synchronization.