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

Darren Dunham ddunham at redwood.taos.com
Thu Dec 2 00:34:28 UTC 2004

John Seal <sealj at indy.raytheon.com> wrote:
> So, here are a few questions I have:

> - Why weren't the two peer servers synced closer than a few seconds?

Did 'ntpq -p' show them as closer, but inspection showed them not to be,
or did the display show them to be far apart?  A display and the actual
ntp.conf files would help.

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

The daemon has a maximum amount of time that it will attempt to change
the time (something like 1000 seconds).  If it believes the current
clock and the "right" time are farther apart than this, it will log an
error and exit.  

You could potentially have a process look for the exit, and if it
occurs restart ntpd with -g which will resync.

> - Starting from a situation with the servers and clients in sync, would 
> large time changes on the server be propagated to the clients?

Only if they are within the 1000 second boundary.  However, NTP is
designed to keep clocks in very close sync, not distribute large jumps
in time quickly.  It will take some time to realize the jump is real
(and not an artifact of a network delay).  Only after the jump
determined to be "real" will it adjust the clock.

> - Why didn't it seem to make any difference whether the clients used 
> authentication keys or not?

Without configs, hard to tell.

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

It seems to be better than just letting it drift.  Given your previous
methods where each clock drifted apart over time, why do you care that
it takes over 5 minutes to distribute a change?

Darren Dunham                                           ddunham at taos.com
Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

More information about the questions mailing list