[ntp:questions] Re: Clock skew too great

Sabrina Lautier slautier at amadeus.com
Wed Nov 16 10:22:18 UTC 2005


Hi Richard,

I found the solution in the HP article below:
http://h18023.www1.hp.com/support/files/server/us/download/23170.html

It is indeed about CPU's frequency.
I quote: "When HP Power Regulator is disabled, Demand Based Switching may
be enabled under the operating system to provide processor performance
states. The operating system will modify the CPU's frequency and voltage
based on CPU Utilization. This feature can be enabled under Microsoft
Windows 2003 Service Pack 1, RedHat Enterprise Linux (RHEL) 4, RHEL4 Update
1, and SUSE Linux Enterprise Server (SLES9) Service Pack 1. However, due to
a "clock skew" issue (where system time is not kept correctly) HP
recommends that PowerNow be disabled in RHEL4 (64-bit), RHEL4 Update 1
(64-bit), and SLES9 Service Pack 1 (64-bit). These operating systems do not
have a work-around for the time corruption issues."

I solved the issue by disabling Power Regulator as described here:

set:
POWERSAVE_CPUFREQD_MODULE="off" in the
/etc/sysconfig/powersave/common file and reboot the server.

Thanks for your help.

Rgds,
Sabrina


                                                                           
                                                                           
                                                                           
                                                                        To 
                                      questions at lists.ntp.isc.org          
                                                                        cc 
                                                                           
                                                                           
                                                                           
    "Richard B. Gilbert"                                           Subject 
    <rgilbert88 at comcast.net>          [ntp:questions] Re: Clock skew too   
                                      great                                
                                                                           
    Sent by:                                                               
    questions-bounces at lists.n                                              
    tp.isc.org                                                             
    15/11/2005 13:56                                                       
                                                                           




Sabrina Lautier wrote:

>First of all thanks a lot for your help.
>Sorry for the late delay but I was off yesterday.
>
>
>
>>How large is the clock skew?
>>
>>
>Huge... to give you an idea last Thursday around 5pm I synchronized the
>date and time and today at 11:30am the time on the machine is 14:23.
>
>
>
>>What is your kernel parameter "HZ" set to ?
>>
>>
>To nothing, the variable is not set.
>
>Would there be a link with the processor clock frequency ?
>
>$ dmesg | grep -i hz
>time.c: Using 1.193182 MHz PIT timer.
>time.c: Detected 2405.495 MHz processor.
>Detected 12.528 MHz APIC timer.
>ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
>powernow-k8:    0 : fid 0x10 (2400 MHz), vid 0x6 (1400 mV)
>powernow-k8:    1 : fid 0xe (2200 MHz), vid 0x8 (1350 mV)
>powernow-k8:    2 : fid 0xc (2000 MHz), vid 0xa (1300 mV)
>powernow-k8:    3 : fid 0xa (1800 MHz), vid 0xc (1250 mV)
>powernow-k8:    0 : fid 0x10 (2400 MHz), vid 0x6 (1400 mV)
>powernow-k8:    1 : fid 0xe (2200 MHz), vid 0x8 (1350 mV)
>powernow-k8:    2 : fid 0xc (2000 MHz), vid 0xa (1300 mV)
>powernow-k8:    3 : fid 0xa (1800 MHz), vid 0xc (1250 mV)
>
>
>
>>If it's set to 1000, try changing it to 100.
>>
>>
>Should I set it to 100 ?
>In which file to you set it ?
>
>What surprises me is that ntp does not report any error (file /var/log/ntp
>is empty).
>
>Rgds,
>Sabrina
>
>
>
>
HZ is clearly not your problem even if your version of Linux implements
it!   HZ governs the rate at which clock interrupts are generated.   The
higher rate increases the probability that clock interrupts will be lost
on systems that exhibit that behavior.   Your clock is fast, not slow.

Multiple processors with different speeds could be part of the problem.
Can you force ntpd to run on only one of those processors?

It would be interesting to see the output of ntpq -p. It would also be
interesting to know the value in the drift file at several different
times; I believe that a new value is recorded once per hour.

_______________________________________________
questions mailing list
questions at lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions





More information about the questions mailing list