[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