[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