[ntp:questions] NTPD Sync. Problem
Richard B. Gilbert
rgilbert88 at comcast.net
Tue Dec 19 03:09:32 UTC 2006
Garrett wrote:
> Hello -
>
> I have a ntpd process running, but it never seems to update its local
> time to the primary time server. When I run "ntpq -pn" I get:
>
> bash-2.05# ntpq -pn
> remote refid st t when poll reach delay offset
> jitter
> ==============================================================================
> 127.127.1.1 .LOCL. 16 l 2 64 377 0.000 0.000
> 0.001
> 192.168.1.150 .LOCL. 1 u 5 64 0 0.000 0.000
> 0.000
>
Nothing is EVER going to synchronize to this! Its stratum is 16 which
is a code that means "I'm not synchronized." In principal, it could
mean that it is getting time from a stratum 15 server but few, if any,
servers operate at stratum 15.
It might, some day, synchronize to 192.168.1.150 but the "reach" field
shows that 192.168.1.150 has not responded to the last eight queries!!
> The system has been running for days like this, and neither server is
> ever prefixed with an "*" indicating the server time is being used.
>
> I am running this on a linux system which I want to serve time to other
> computers on my local network when the primary time server is
> unavailable. The linux system also should sync its time to the primary
> time server when that computer is available (it won't be always), and
> when it's not available it should serve it's local time to the other
> clients on the network.
>
> Primary Time Server: 192.168.1.150
> The linux server IP: 192.168.1.161
>
> Here's my ntp.conf for the linux server:
> server 127.127.1.1
> fudge 127.127.1.1 stratum 16
Don't use stratum 16! No one will ever synch to a server at stratum 16!
It is conventional to use a high stratum for the local clock when it is
being used to serve time to clients but stratum 16 is too high. Try 10
or 12.
> server 192.168.1.150
> driftfile /var/lib/ntp/drift
> restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap
>
> The other clients on the network are able to get time from the linux
> server, but it's serves the local time which is different from the time
> at 192.168.1.150. It never updates it's local time to that of
> 192.168.1.150 (primary time server).
>
> When I run "w32tm /monitor /computers:192.168.1.161" from a windows pc
> on the network I get:
> 192.168.1.161 [192.168.1.161]:
> ICMP: 0ms delay.
> NTP: -371.0058478s offset from local clock
> RefID: 'LOCL' [73.78.73.84]
>
> This at least indicates the linux server responds to ntp requests.
>
> What am I missing here? ANy help would be greatly appreciated!
>
The basic thing you seem to be missing is that NTP is a hierarchical
protocol designed to synchronize clocks to UTC. You seem to be trying
to synchronize clocks without a UTC reference. It's possible but your
time will be correct only by accident! Your time will be not only
incorrect but also will drift from day to day.
Your immediate problem seems to be that your "primary time server" is
not responding to queries. Either ntpd is not running, there is a
hardware problem, or you have used misconfigured your primary time
server. Restrict statements are always a likely suspect in such a case.
A "normal" NTP subnet would have at least one server getting its time
from four or five internet servers. That server would be serving time
to local clients. An alternative configuration would be at least one
server with a hardware reference clock (GPS Timing Receiver, HF receiver
tuned to a broadcast such as WWV or CHU (in Canada), JJY (in Japan) or a
VLF receiver tuned to WWVB (60 KHz), or an atomic clock.)
More information about the questions
mailing list