Following the update this morning, NTP is failing with the same symptoms that I saw several years ago (pre-CentOS, I believe) when Anaconda mistakenly blessed my ASUS A7N8X, Athlon (CPU: AMD Athlon(tm) XP 2600+ stepping 00) based system with an SMP kernel. The symptom is that NTPD never establishes sync with a server, showing over the top jitter values.
[root@mavis log]# uname -r 2.6.9-55.EL [root@mavis log]# ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== decimal.lib.ci. .STEP. 16 u 35 64 0 0.000 0.000 4000.00 dewey.lib.ci.ph 206.223.0.15 2 u 33 64 17 51.733 -725.97 858.187 clock.fmt.he.ne .GPS. 1 u 96 64 16 150.603 -1252.6 996.045 clock.sjc.he.ne .CDMA. 1 u 34 64 17 59.286 -70.022 1301.68 bigben.ucsd.edu .GPS. 1 u 30 64 17 96.343 -1280.8 850.955 ntp1.tummy.com 129.6.15.28 2 u 30 64 17 27.178 -1888.0 1283.07 ntp-0.gw.uiuc.e 128.174.38.133 2 u 29 64 17 38.694 -1324.4 850.348 ntp3.tamu.edu 128.194.254.7 2 u 27 64 17 16.334 -1328.6 847.372 ntp-1.cns.vt.ed 198.82.247.40 2 u 24 64 17 54.344 -777.83 842.443 *LOCAL(0) LOCAL(0) 10 l 26 64 17 0.000 0.000 0.004 [root@mavis log]#
So, sometime around 4-5 minutes after starting ntpd, it had given up and synced with the local pseudo-source. Rebooting into the previous kernel restores the operation this machine has enjoyed for the last couple years, quickly settling on an external source. (The following was copied after an extended period of time but the fact is that I have to really rush to boot, startx, open a root terminal and enter the commands before ntp stabilizes like this.)
[root@mavis log]# uname -r 2.6.9-42.0.10.EL [root@mavis log]# ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== decimal.lib.ci. .STEP. 16 u 961 1024 0 0.000 0.000 4000.00 -dewey.lib.ci.ph 198.153.152.52 2 u 45 1024 377 61.775 -9.729 50.560 -clock.fmt.he.ne .GPS. 1 u 49 1024 375 144.312 40.998 46.828 *clock.sjc.he.ne .CDMA. 1 u 96 1024 377 58.245 0.159 0.468 -bigben.ucsd.edu .GPS. 1 u 33 1024 337 96.754 24.580 0.351 -ntp1.tummy.com 129.6.15.28 2 u 36 1024 377 27.690 9.328 1.335 +ntp-0.gw.uiuc.e 128.174.38.133 2 u 40 1024 377 39.836 1.047 0.143 -ntp3.tamu.edu 128.194.254.7 2 u 88 1024 377 16.901 2.814 0.005 +ntp-1.cns.vt.ed 198.82.247.40 2 u 94 1024 377 54.954 0.666 0.069 LOCAL(0) LOCAL(0) 10 l 54 64 377 0.000 0.000 0.004 [root@mavis log]#
Has anyone else seen this behavior with kernel-2.6.9-55 ?
Robert wrote:
Following the update this morning, NTP is failing with the same symptoms that I saw several years ago (pre-CentOS, I believe) when Anaconda mistakenly blessed my ASUS A7N8X, Athlon (CPU: AMD Athlon(tm) XP 2600+ stepping 00) based system with an SMP kernel. The symptom is that NTPD never establishes sync with a server, showing over the top jitter values.
Several years ago with a Gentoo installation I experienced an identical problem with an ASUS A7N8X-E Deluxe motherboard, also with an AMD Athlon XP 2600+. After a lot of experimenting, I discovered that if the FSB Spread Spectrum feature was enabled with ACPI, spurious timer interrupts were generated, causing the system (Linux) clock to tick fast and ntpd to fail to sync with any time source.
Who knows whether a BIOS update will fix this problem, but a quick test would be to disable the FSB Spread Spectrum feature and see if that fixes the problem.
Cheers, Michael
Michael D. Kralka wrote:
Robert wrote:
Following the update this morning, NTP is failing with the same symptoms that I saw several years ago (pre-CentOS, I believe) when Anaconda mistakenly blessed my ASUS A7N8X, Athlon (CPU: AMD Athlon(tm) XP 2600+ stepping 00) based system with an SMP kernel. The symptom is that NTPD never establishes sync with a server, showing over the top jitter values.
Several years ago with a Gentoo installation I experienced an identical problem with an ASUS A7N8X-E Deluxe motherboard, also with an AMD Athlon XP 2600+. After a lot of experimenting, I discovered that if the FSB Spread Spectrum feature was enabled with ACPI, spurious timer interrupts were generated, causing the system (Linux) clock to tick fast and ntpd to fail to sync with any time source.
Who knows whether a BIOS update will fix this problem, but a quick test would be to disable the FSB Spread Spectrum feature and see if that fixes the problem.
Cheers, Michael
YES! I changed the FSB Spread Spectrum from "0.50%" to "disabled", saved, rebooted and the problem is gone. Thanks for the help! BTW, I had already checked for a BIOS update.
Best regards, Robert