Hide Forgot
This is RHEL 6.1 with ntp-4.2.4p8-2.el6.x86_64 on an IBM x3550 M3. The ntp config is the default config plus additional local ntp servers. The log file reports "kernel time sync status 2040" - Which translates to NANO and UNSYNC. Also ntpdc reports the problem: [root@kvm000 ~]# ntpdc -c kerninfo pll offset: 0 s pll frequency: 0.000 ppm maximum error: 0.090016 s estimated error: 1.6e-05 s status: 2040 unsync nano pll time constant: 0 precision: 1e-09 s frequency tolerance: 500 ppm And ntptime agrees: [root@kvm000 ~]# ntptime ntp_gettime() returns code 5 (ERROR) time d260f02f.d3c9039c Sun, Nov 6 2011 12:38:23.827, (.827286475), maximum error 107516 us, estimated error 16 us, TAI offset 0 ntp_adjtime() returns code 5 (ERROR) modes 0x0 (), offset 0.000 us, frequency 0.000 ppm, interval 1 s, maximum error 107516 us, estimated error 16 us, status 0x2040 (UNSYNC,NANO), time constant 0, precision 0.001 us, tolerance 500 ppm, A workaround is, to rebuild the newest NTP package source from Fedora 15:ntp.x86_64 0:4.2.6p3-4. With the newer NTP and identical configuration, the problem goes away: [root@kvm000 ~]# rpm -q ntp && ntptime ntp-4.2.6p3-4.el6.x86_64 ntp_gettime() returns code 0 (OK) time d260f0d3.af4655e4 Sun, Nov 6 2011 12:41:07.684, (.684667799), maximum error 33016 us, estimated error 16 us, TAI offset 0 ntp_adjtime() returns code 0 (OK) modes 0x0 (), offset 0.000 us, frequency 0.000 ppm, interval 1 s, maximum error 33016 us, estimated error 16 us, status 0x2001 (PLL,NANO), time constant 3, precision 0.001 us, tolerance 500 ppm,
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. If you would like it considered as an exception in the current release, please ask your support representative.
Was ntpd synchronized when ntptime was called? What does "ntpq -pn" print? Zero offset in the ntptime output indicates it wasn't not synchronized yet. The older ntpd clears UNSYNC on first update, the Fedora ntpd clears it on start.
The machines have been running for some time. Here is an example: [root@host001 ~]# ntpq -pn && ntptime remote refid st t when poll reach delay offset jitter ============================================================================== *10.11.12.13 129.132.2.21 3 u 17 64 377 0.286 1.871 0.169 127.127.1.0 .LOCL. 5 l 21h 64 0 0.000 0.000 0.000 ntp_gettime() returns code 5 (ERROR) time d2625fab.bb89e730 Mon, Nov 7 2011 14:46:19.732, (.732573975), maximum error 16000000 us, estimated error 16 us, TAI offset 0 ntp_adjtime() returns code 5 (ERROR) modes 0x0 (), offset 0.000 us, frequency 0.000 ppm, interval 1 s, maximum error 16000000 us, estimated error 16 us, status 0x2041 (PLL,UNSYNC,NANO), time constant 3, precision 0.001 us, tolerance 500 ppm,
That's odd. Do you see any time resets reported by ntpd in syslog? Is this on a real hw or virtual machine? Is it possible something else running on the system is touching the clock? "ntpq -c rv" output might help too.
From the available information I don't see what's wrong here. I'm closing this bug. The current ntp version in RHEL6 is ntp-4.2.6p5, which according to the comment #0 doesn't have the problem. Please reopen if you can still see it and have more information.