[ntp:questions] Strange behaviour

Martin Burnicki martin.burnicki at meinberg.de
Thu Apr 12 09:26:30 UTC 2007


Burkhard Schultheis wrote:
> ntpq -p <IP> on first machine:
>      remote           refid      st t when poll reach   delay   offset
> jitter
>
==============================================================================
>  LOCAL(0)        LOCAL(0)        10 l    3   64  377    0.000    0.000
>  0.008
> +192.53.103.104  .PTB.            1 u    8   64  377   32.460  3741.35
> 205.107
> *192.53.103.108  .PTB.            1 u    9   64  377   32.179  3737.53
> 201.231

Assuming <IP> is your time server which gets the time from the 2 PTB
servers, the command you mentioned above reports the status of your time
server, not the status of the Linux machine the ntpq command executes on.

The "offset" column indicates your time server's system time is about 3.7
seconds off the PTB time. Since the delay and offset values are pretty
similar for both NTP servers, the problem is at your time server.

> on second machine:
>      remote           refid      st t when poll reach   delay   offset
> jitter
>
==============================================================================
>  LOCAL(0)        LOCAL(0)        10 l   59   64    7    0.000    0.000
>  0.008
>  192.53.103.104  .PTB.            1 u   59   64    7   32.136  522.209
> 203.600
>  192.53.103.108  .PTB.            1 u   50   64    7   32.756  556.967
> 204.109

It should absolutely not matter if you run "ntpq -p" against your time
server on either of your Linux time clients, or directly on the time
server.

However, obviously something on your time server has changed between both
status displays: 

- reach has changed from 377 to 7
- offsets have changed from 37xx to 5xx

So ether the NTP daemon on the time server has recently been restarted, or
it has made a "time reset". Since the offset is still more than 500
milliseconds, the time server should do another "time reset" soon. You
should see those events in your time server's log files.

Your time server is not yet synchronized, so your Linux clients won't accept
it as time seource.

> The delay seams to be very high, or am I wrong? Another mystery: In both
> drift files I read 0.000!

The delay is 32 milliseconds, which is not too bad across an old (slow?)
internet connection. 

If the drift file contains 0 this means ntpd has not yet been able to
determine the drift correctly. 

First get your time server working correctly, then see how the clients
behave.
 
BTW, under which operating system is your time server running, and which
version of ntpd is running there? You can display this using:
ntpq -c rv <IP>

> Regards,
> Burkhard

Regards,

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany




More information about the questions mailing list