[ntp:questions] Re: NTP seems unsuitable for this application... what do you think?

John Seal sealj at indy.raytheon.com
Thu Dec 2 13:59:29 UTC 2004


Richard B. Gilbert wrote:

> If two peers differ by a few seconds, how is NTP supposed to correct the 
> time?  How is NTP supposed to know what the correct time is?   The 
> answer is that it can't!

But page 4 of Sun's "Using NTP to Control and Synchronize System Clocks 
- Part I: Introduction to NTP" says:

"if two NTP servers are synchronized to each other as peers, what 
actually happens is the clocks decide among themselves which is the 
better source of time, and both clocks attempt to synchronize to that".

I assume they do this by looking at drift rates, etc., and that can take 
a long time... maybe longer than our system is up at one time!

> I think you are right!  It sounds as if you don't really care what time 
> it is and really don't need to keep those systems synchronized.

It's true that we don't care so much about the time being absolutely 
correct; we care more about the hosts all having the SAME time. 
Synchronization is more important that accuracy, but we also have to 
guard against things like time going backwards, because it messes up 
Sybase and certain alarm-based scheduling algorithms we use.

Page 3 of the Sun NTP document says:

"Other schemes, such as DTS, are designed primarily for local area 
networks, while NTP is designed specifically for Internet environments."

This is another reason we think NTP might not be appropriate (since our 
system is not on the Internet).  Would DTS be appropriate?

> If you keep the systems powered on, the batteries should last 
> for at least four or five years and probably longer since no power is 
> drawn while the system is powered up.
> 
> If you really care what time it is, leave one of the GPS systems powered 
> up to act as a server.

That is not possible, as the system is powered by generators.  Also, for 
better or worse, field maintenance is such that the clock batteries will 
rarely, if ever, be replaced, so they WILL eventually go dead.

What we really want is to take a system that boots with absolutely no 
idea what time it is, and somehow get all hosts to agree on a time, even 
if it's just "wristwatch time" entered by an operator, no matter when or 
in what order the hosts are booted.

I can't paste the actual ntp.conf files in here, because the system is 
not networked outside its own LAN.  But they are fairly minor edits of 
the supplied templates, and I am reproducing them here from my notes. 
(I have changed the otherwise nondescript hostnames to something 
meaningful in context.)  All the hosts have a single alpha key defined 
in /etc/inet/ntp.keys, something like "1 M local_time".

The main GPS host has something like this in /etc/inet/ntp.conf:

server 127.127.1.0 prefer
peer backupGPS key 1
enable auth monitor
driftfile /var/ntp/ntp.drift
statsdir /var/ntp/ntpstats/
filegen peerstats file peerstats type day enable
filegen loopstats file loopstats type day enable
filegen clockstats file clockstats type day enable
keys /etc/inet/ntp.keys
trustedkey 1
requestkey 1
controlkey 1

(Actually, I don't know if the server line includes "prefer" or not.) 
This is intended to tell the main GPS host to use its local clock as the 
time reference (since an external program is keeping it synced to GPS), 
and to coordinate with the backup server (whose clock is NOT normally 
synced to GPS) as a peer.  Note that we are not using broadcast or 
multicast... should we be?  Interestingly, the peerstats and loopstats 
files are getting created, but not the clockstats file.  Why?

The backup GPS host has something like this:

server 127.127.1.0
peer mainGPS key 1 prefer
enable auth monitor
driftfile /var/ntp/ntp.drift
statsdir /var/ntp/ntpstats/
filegen peerstats file peerstats type day enable
filegen loopstats file loopstats type day enable
filegen clockstats file clockstats type day enable
keys /etc/inet/ntp.keys
trustedkey 1
requestkey 1
controlkey 1

This tells the backup GPS host to use its local clock as the time 
reference, to coordinate with the main GPS host as a peer, and to prefer 
its time.  This also seems to work, according to ntpq's "peer" command, 
subject to the anomalies I mentioned in my original posting.  I should 
point out that I only investigated this for several hours, during which 
time I was starting and stopping NTP servers and clients fairly often, 
so I definitely did not let NTP "cook" for an extended period of time, 
which I'm beginning to think might be necessary.

Some clients have this:

server mainGPS key 1 prefer
server backupGPS key 1
keys /etc/inet/ntp.keys
trustedkey 1
requestkey 1
controlkey 1

and some clients have just this:

server mainGPS prefer
server backupGPS

This tells them to prefer the main GPS host, but to use the backup GPS 
host too, if necessary.  This seems to work fine, the clients do switch 
as the servers are stopped and started, but I'm curious why it works 
even without authentication.  Is it because the servers don't have any 
"restrict" lines?

I appreciate all the responses I got.  Even though this is water under 
the bridge (since we've deciced not to use NTP at this time) I'd still 
like to get smart on it.

Thank you.



More information about the questions mailing list