I'm trying to set up ntp on a new Core2 Duo box running Fredora Core9.
It appears that it's local clock runs several seconds an hour fast.  I'm
basing this on running ntpdate against the existing box I have running
ntp with pps.  It reports skewing the clock by seconds even after just
a few minutes.

Also, ntpq data shows the jitter as always 0.997, and the offset goes
nuts right away.  The poll and reach look like they are working, but
the time just gets away really fast.

I have another box with the same O/S install and ntp config, and it locks
up right away just fine, so I suspect it's a hardware issue, not a
config problem.

I've tried to read through the offical docs on the NTP web site on
diagnosing problems, but can't make sense of what some of the
instructions mean. What's missing are examples of what actually
needs to happen.

In any case, if the actual box's clock is that far off, is it a lost
cause as a time keeper?

Can I make ntptime correct the kernel's clock enough to get this
to work?  If so, how, and can this be done in the bootup scripts?

Thx, Chris

Chris Richmond wrote:
> I'm trying to set up ntp on a new Core2 Duo box running Fredora Core9.
> It appears that it's local clock runs several seconds an hour fast.  I'm
> basing this on running ntpdate against the existing box I have running
> ntp with pps.  It reports skewing the clock by seconds even after just
> a few minutes.
> 
> Also, ntpq data shows the jitter as always 0.997, and the offset goes
> nuts right away.  The poll and reach look like they are working, but
> the time just gets away really fast.
> 
> I have another box with the same O/S install and ntp config, and it locks
> up right away just fine, so I suspect it's a hardware issue, not a
> config problem.
> 
> I've tried to read through the offical docs on the NTP web site on
> diagnosing problems, but can't make sense of what some of the
> instructions mean. What's missing are examples of what actually
> needs to happen.
> 
> In any case, if the actual box's clock is that far off, is it a lost
> cause as a time keeper?
> 
> Can I make ntptime correct the kernel's clock enough to get this
> to work?  If so, how, and can this be done in the bootup scripts?
> 
> Thx, Chris
> 

What does your drift file say?  If the drift is greater than 500 PPM,
the clock is sufficiently bad that ntpd can't discipline it.  Depending 
on what O/S you are running, you MAY be able to correct this or maybe 
not.  A typical drift value is less than 50 PPM.

"Chris Richmond" <tomnykds@comcast.net> wrote in message 
news:Xns9B57BC0965C12tomnykdscomcastnet@74.209.131.18...
> I'm trying to set up ntp on a new Core2 Duo box running Fredora Core9.
> It appears that it's local clock runs several seconds an hour fast.  I'm
> basing this on running ntpdate against the existing box I have running
> ntp with pps.  It reports skewing the clock by seconds even after just
> a few minutes.
>
> Also, ntpq data shows the jitter as always 0.997, and the offset goes
> nuts right away.  The poll and reach look like they are working, but
> the time just gets away really fast.
>
> I have another box with the same O/S install and ntp config, and it locks
> up right away just fine, so I suspect it's a hardware issue, not a
> config problem.
>
> I've tried to read through the offical docs on the NTP web site on
> diagnosing problems, but can't make sense of what some of the
> instructions mean. What's missing are examples of what actually
> needs to happen.
>
> In any case, if the actual box's clock is that far off, is it a lost
> cause as a time keeper?
>
> Can I make ntptime correct the kernel's clock enough to get this
> to work?  If so, how, and can this be done in the bootup scripts?
>
> Thx, Chris
>


Chris,
May not be applicable in your case but I have multiple HP pc's and most were 
running fast. I replaced batteries in all my machines that were a few years 
old and it's amazing what a new battery will do.

In my case we bought them on-line for about a buck each in quantity and I 
changed batteries in all my electronics that used the 3-volt button 
batteries. It may not get the local oscillator on the proper frequency, but 
it should make it stable, a somewhat fixed drift rate. Just a thought.

Phil 

"Phil" <phil@xxxxxxxxx.xxx> writes:


>"Chris Richmond" <tomnykds@comcast.net> wrote in message 
>news:Xns9B57BC0965C12tomnykdscomcastnet@74.209.131.18...
>> I'm trying to set up ntp on a new Core2 Duo box running Fredora Core9.
>> It appears that it's local clock runs several seconds an hour fast.  I'm
>> basing this on running ntpdate against the existing box I have running
>> ntp with pps.  It reports skewing the clock by seconds even after just
>> a few minutes.
>>
>> Also, ntpq data shows the jitter as always 0.997, and the offset goes
>> nuts right away.  The poll and reach look like they are working, but
>> the time just gets away really fast.
>>
>> I have another box with the same O/S install and ntp config, and it locks
>> up right away just fine, so I suspect it's a hardware issue, not a
>> config problem.
>>
>> I've tried to read through the offical docs on the NTP web site on
>> diagnosing problems, but can't make sense of what some of the
>> instructions mean. What's missing are examples of what actually
>> needs to happen.
>>
>> In any case, if the actual box's clock is that far off, is it a lost
>> cause as a time keeper?
>>
>> Can I make ntptime correct the kernel's clock enough to get this
>> to work?  If so, how, and can this be done in the bootup scripts?
>>
>> Thx, Chris
>>


>Chris,
>May not be applicable in your case but I have multiple HP pc's and most were 
>running fast. I replaced batteries in all my machines that were a few years 
>old and it's amazing what a new battery will do.

You comment has to do with the on board Real Time Clock, not the system clock
which runs off the CPU/timer interrupt. He has trouble with the latter. 
It indicates problems with the clock calibration in his kernel. Or it could
have to do with "power saving" in which the CPU frequency is changed to
conserve power. As far as I know no operating system uses the RTC as the
timer, not least because it only has a 1 sec resolution.



>In my case we bought them on-line for about a buck each in quantity and I 
>changed batteries in all my electronics that used the 3-volt button 
>batteries. It may not get the local oscillator on the proper frequency, but 
>it should make it stable, a somewhat fixed drift rate. Just a thought.

It should be irrelevant to the system time, but not to the time set at
bootup.



>Phil 

Chris Richmond wrote:

> I'm trying to set up ntp on a new Core2 Duo box running Fredora Core9.
> It appears that it's local clock runs several seconds an hour fast.  I'm
> basing this on running ntpdate against the existing box I have running
> ntp with pps.  It reports skewing the clock by seconds even after just
> a few minutes.
> 
> Also, ntpq data shows the jitter as always 0.997, and the offset goes
> nuts right away.  The poll and reach look like they are working, but
> the time just gets away really fast.
> 
> I have another box with the same O/S install and ntp config, and it locks
> up right away just fine, so I suspect it's a hardware issue, not a
> config problem.
> 
> I've tried to read through the offical docs on the NTP web site on
> diagnosing problems, but can't make sense of what some of the
> instructions mean. What's missing are examples of what actually
> needs to happen.
> 
> In any case, if the actual box's clock is that far off, is it a lost
> cause as a time keeper?
> 
> Can I make ntptime correct the kernel's clock enough to get this
> to work?  If so, how, and can this be done in the bootup scripts?
> 
> Thx, Chris

I have a deja vu... again.

See the support twiki for some hints about linux, but I had similar trouble.
Try to configure your kernel with a 'clocksource=acpi_pm'
or 'clocksource=hpet' and see what happens. A lot of systems try to use the
TSC as clocksource, and the TSC frequency is not constant but varies due to
power management actions.

Have a look at the twiki
at 'https://support.ntp.org/bin/view/Support/KnownOsIssues#Section_9.2.4.2.8.'
-- 
juergen 'pearly' perlinger
"It's hard to make new errors!"