On 2008-06-06, stephan@newace.ca wrote:

> I have a very strange problem that started a few days ago. The server
> is running kernel 2.4.28 and has been running for several years
> without any issues.

Has anything changed on this system?

> When starting the ntp service, the time is initially set correctly
> using ntpdate but after a while, the time will be offset by several
> hours. The longer ntp is allowed to run, the larger the offset appears
> to be. It seems to level off around 6 hours offset.

[snip]

> After 1 minute:
> remote refid st t when poll reach delay offset jitter
>================================================== ===================
> LOCAL(0) .LOCL. 13 l 2 64 3 0.000 0.000 0.001
> pbx... time-a.nist.gov 2 u - 64 3 0.157 -20590. 19888.0

This ntpd is configured to use the Undisciplined Local Clock (or
LocalCLK) as a fake time source. Doing so is a bad idea unless this
ntpd needs to serve time to others even when no real time sources are
available.

What is most likely happening is this ntpd is syncing to the LocalCLK
and drifting away from the pbx. Please try running ntpd without the
LocalCLK and post the results here.

We need to see your ntpq -p billboard after this ntpd has synced to one
of those time sources (look for the '*' in the first column) or ~ 20
minutes, which ever comes first. Please condense the billboard lines as
I did above.

> I upgraded from 4.2.0 to 4.2.4b4, but the problem remains. The
> interesting thing to note is that our "pbx" server does not display
> this large jitter and is connected to the same network.
>
> Does anyone have any suggestions as to why this would be?

You may want to take a look at the Known Hardware Issues and Known
Operating System Issues sections of
http://support.ntp.org/bin/view/Supp...bleshootingNTP to see if
anything there addresses your problem system.

--
Steve Kostecke
NTP Public Services Project - http://support.ntp.org/

stephan@newace.ca writes:

>I have a very strange problem that started a few days ago. The server
>is running kernel 2.4.28 and has been running for several years
>without any issues.

You have LOCAL as a server why? Why in the world would you tell the system
to use itself as a time source. While this might be useful for a server, it
is not for a client.



>When starting the ntp service, the time is initially set correctly
>using ntpdate but after a while, the time will be offset by several
>hours. The longer ntp is allowed to run, the larger the offset appears
>to be. It seems to level off around 6 hours offset.

>When I start NTP and query it at several minute intervals, this is the
>result:

>After initial startup:
>[root@hydra src]# ntpq -p
> remote refid st t when poll reach delay
>offset jitter
>================================================== ============================
> LOCAL(0) .LOCL. 13 l - 64 1 0.000
>0.000 0.001
> pbx.... . INIT. 16 u - 64 0 0.000
>0.000 0.001

>After 30 seconds:
> remote refid st t when poll reach delay
>offset jitter
>================================================== ============================
> LOCAL(0) .LOCL. 13 l 24 64 1 0.000
>0.000 0.001
> pbx.... time-a.nist.gov 2 u 23 64 1 0.214
>-702.33 0.001

>After 1 minute:
> remote refid st t when poll reach delay
>offset jitter
>================================================== ============================
> LOCAL(0) .LOCL. 13 l 2 64 3 0.000
>0.000 0.001
> pbx.... time-a.nist.gov 2 u - 64 3 0.157
>-20590. 19888.0


>This problem occurs whether I initially sync to an internal server or
>NIST directly. The jitter always seems to become very large in a short
>period of time.

And time-a never becomes the server of reference, not does local.

So that looks like the natural very high drift of your clock.
It has lost 13 seconds in 30 sec. That is absolutely impossible for ntp to
correct, and indicates a HIGHLY defective system clock. Never mind the
jitter.



>I upgraded from 4.2.0 to 4.2.4b4, but the problem remains. The
>interesting thing to note is that our "pbx" server does not display
>this large jitter and is connected to the same network.

>Does anyone have any suggestions as to why this would be?

Your computer clock is completely screwed? Your kernel timer routines are
seriously defective?


>Any assistance would be greatly appreciated.

>Regards,

>Stephan.

Steve Kostecke writes:

>On 2008-06-06, stephan@newace.ca wrote:

>> I have a very strange problem that started a few days ago. The server
>> is running kernel 2.4.28 and has been running for several years
>> without any issues.

>Has anything changed on this system?

>> When starting the ntp service, the time is initially set correctly
>> using ntpdate but after a while, the time will be offset by several
>> hours. The longer ntp is allowed to run, the larger the offset appears
>> to be. It seems to level off around 6 hours offset.

>[snip]

>> After 1 minute:
>> remote refid st t when poll reach delay offset jitter
>>================================================== ===================
>> LOCAL(0) .LOCL. 13 l 2 64 3 0.000 0.000 0.001
>> pbx... time-a.nist.gov 2 u - 64 3 0.157 -20590. 19888.0

>This ntpd is configured to use the Undisciplined Local Clock (or
>LocalCLK) as a fake time source. Doing so is a bad idea unless this
>ntpd needs to serve time to others even when no real time sources are
>available.

>What is most likely happening is this ntpd is syncing to the LocalCLK
>and drifting away from the pbx. Please try running ntpd without the
>LocalCLK and post the results here.

It cannot. It is driftine at 130000 PPM, which is way way way outside of
NTP's range.


>We need to see your ntpq -p billboard after this ntpd has synced to one
>of those time sources (look for the '*' in the first column) or ~ 20
>minutes, which ever comes first. Please condense the billboard lines as
>I did above.

It will never sync with that kind of drift rate.


>> I upgraded from 4.2.0 to 4.2.4b4, but the problem remains. The
>> interesting thing to note is that our "pbx" server does not display
>> this large jitter and is connected to the same network.
>>
>> Does anyone have any suggestions as to why this would be?

>You may want to take a look at the Known Hardware Issues and Known
>Operating System Issues sections of
>http://support.ntp.org/bin/view/Supp...bleshootingNTP to see if
>anything there addresses your problem system.

>--
>Steve Kostecke
>NTP Public Services Project - http://support.ntp.org/

stephan@newace.ca wrote:

> When starting the ntp service, the time is initially set correctly
> using ntpdate but after a while, the time will be offset by several

The jitter is the result of the huge offsets, not the other way round.

> hours. The longer ntp is allowed to run, the larger the offset appears
> to be. It seems to level off around 6 hours offset.

You have a very weird mechanism if the system suddenly stops drifting,
although you maybe have a temperature dependent hardware fault.

Although your problem is not an ntpd one, I do agree with the comments
others have made about using the local clock, and would add that, where
its use is appropriate, you should arrange for it to be outvoted by
servers that are running with the correct time.

>