[ntp:questions] Re: NTP seems unsuitable for this application... what do you think?
fredb at immanent.net
Thu Dec 2 15:06:52 UTC 2004
In article <N0rrd.7$%55.0 at dfw-service2.ext.ray.com>,
John Seal <sealj at indy.raytheon.com> writes:
> There is another special GPS host, but its local clock is not normally
> kept synced to GPS time. It is for backup use, and the GPS sync
> functionality must be manually started when required.
> We configured both of the special GPS hosts as servers, with their local
> processor clocks as the reference (127.127.1.0), as peers of each other,
> and using authentication keys. Even though ntptrace and ntpq showed
> pretty much what I expected, I consistently saw 3-5 seconds difference
> in their times. The clients were configured to use both servers, but to
> prefer the main one. Interestingly, it didn't seem to matter whether
> the clients were configured to use authentication keys or not.
> - Why weren't the two peer servers synced closer than a few seconds?
OK, now why should the two GPS hosts have the same time? What kind of
backup can the second host be, if it isn't synced to anything? It seems
to me that all you'd have to do to fix this configuration, is to run the
special app on the backup host all the time.
> - If a server started out at the epoch, then changed to the right time
> on the wrong date, then changed to the right date and time, how would
> NTP react? In other words...
There's no such thing as "right time and wrong date". The "time" is
a count of the seconds since the start of the epoch, so if the date is
wrong, the time is wrong.
> - Starting from a situation with the servers and clients in sync, would
> large time changes on the server be propagated to the clients?
Yes, if by "large" you mean hours or days. If you mean "years", no.
> - Why didn't it seem to make any difference whether the clients used
> authentication keys or not?
What difference would you expect it to make? The "ntpd" that ships with
your OS probably doesn't support authentication anyway. (Authentication
is new to NTP 4.2.0, IIRC.)
> Our decision, as of this morning, is that NTP really isn't suitable to a
> system like this that's not ON for long periods of time, not on the
> internet, has hosts that boot with wildly different local times, and
> lacks direct connection to a GPS. What do you think?
My organization still has a lot of micro-Vax's running VMS 5.5 doing
process control for a mail sorting machine (about one thousand
nation-wide). A couple of years ago, the package was modified to run
"ntpdate" at boot-up to a local time server at each site. This saves
people all the trouble of typing in a date at boot-up, and eliminates
major guffaws in the statistics reporting. The time probably drifts
between boot-ups (which could be months), but no one cares about that.
This was a very popular change with the technicians.
More information about the questions