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

Richard B. Gilbert rgilbert88 at comcast.net
Fri Dec 3 00:27:58 UTC 2004


John Seal wrote:

> 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!
>

The Sun document is not authoritative!   See RFC1305 
<http://www.eecis.udel.edu/%7Emills/database/rfc/rfc1305/rfc1305a.pdf>

Briefly, I don't think that what the Sun document says is even possible 
with only two peers.   Each could measure the drift of the other with 
respect to its own clock but both systems are drifting.  How do you 
determine how much of the aggregate drift is due to each system? 

>> 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?
>
The internet is not required to run NTP.   You can use a server with a 
hardware reference clock; e.g. GPS, and operate in an isolated LAN.  If 
you don't really care about accuracy or tight synchronization the 
reference clock is optional too;  just designate one system as the 
"master clock" and the others will follow it.   I would not be surprised 
if the various system clocks differed in their opinion of time by 50 
milliseconds or more.

If DTS refers to DTSS, it's a protocol developed by the late Digital 
Equipment Corporation and implemented in DECnet/OSI.  Unless someone has 
re-implemented the algorithms in a Sun/Solaris environment I don't 
believe it will do you any good.

>> 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.
>
You don't need NTP to do that.  Given the restrictions you are working 
under, your "complicated dance" is probably the best you can do.

> 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?
>
It works without authentication because you didn't tell the clients to 
authenticate!  Authentication simply tries to guarantee that the packet 
you received actually came from the server that you requested it from.  
Authenticated or not, the NTP packets contain an unencrypted timestamp 
that anybody receiving it can use.

> 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