On Thu, 2011-04-14 at 13:28 +0200, Simon Matter wrote:
> > On 4/14/2011 6:47 AM, Johnny Hughes wrote:
> >>
> >> Is it really true that the time is working perfectly with one of the
> >> other kernels (the older ones)?
> >>
> >>
> >>
> >
> > Johnny,
> >
> > Yes, As long as I run the older 5.5 kernel my time is perfect.
> > All clients can get from this machine with no issues. As soon as I run
> > new kernel, or Plus kernel for that matter. The time goes downhill.
> > "Uphill actually"
> >
> > To answer the previous question I do have the HW clock set to utc,
> > Everything is stock from initial install of the package.
>
> Did you check dmesg which timer is being used (I think it can also be seen
> somewhere in /proc but I don't remember). If it's hpet, you could try to
> disable it. That was for i686: 'hpet=disable' and for x86_64: 'nohpet',
> don't know how it is with current kernels.
>
> Simon
Forgive me if I've missed a later post but it looked like this thread
was stagnant...
You may have something here Simon. I was thinking about your suggestion
that it could be a timer issue. I'm wondering if the default clocksource
or some related timer kernel parameter has been changed between
2.6.18-194.17.4.el5 (5.5) and 2.6.18-238.5.1.el5 (5.6).
Timer related issues could very well account for this large,
inconsistent NTP drift as well as Florin Andrei's "bizarre" tar, scp,
and NTP issues in the " bizarre system slowness" thread. System
interrupts are based on the clocksource chosen by (or configured in) the
kernel. Any service or facility that uses these interrupts could be
experiencing problems.
Can anyone on the list confirm whether or not timer related kernel
parameters have changed in 5.6? I don't have source handy and I'm going
out the door in minutes.
Reading up on kernel timer options, I came across these articles.
# Discusses mis-detected timer frequency
9.2.4.2.7. Kernel 2.6 Mis-Detecting CPU TSC Frequency
http://support.ntp.org/bin/view/Support/KnownOsIssues#Section_9.2.4.2.7.
# Describes ntpd instability from some time sources
# Includes data and graphs from detailed study
http://www.ep.ph.bham.ac.uk/general/support/adjtimex.html
I checked clock sources on a few systems under my control to see what
came up. None are experiencing this problem. The CentOS and FC12
machines are isolated from the Internet while the FC14 laptop connects.
My sample CentOS 5.5 & 5.6 systems are different hardware platforms. The
5.6 box doesn't have the hpet timer available so it may just not be
susceptible to this problem. I'll be updating the 5.5 sample to 5.6
tomorrow which does have hpet available so I should know something more
then.
# Used these to get available and current clocksource:
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
# CentOS 5.5:
Available: acpi_pm jiffies hpet tsc pit
Current: tsc
# CentOS 5.6:
Available: acpi_pm jiffies tsc pit
Current: tsc
# Fedora 12:
Available: tsc hpet acpi_pm
Current: tsc
# Fedora 14: Using hpet
Available: hpet acpi_pm
Current: hpet
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
