[ntp:questions] avoiding large steps (on time island)

Steve Kostecke kostecke at ntp.isc.org
Thu May 17 17:29:51 UTC 2007


On 2007-05-17, seanjlangford at gmail.com <seanjlangford at gmail.com> wrote:

> I'm having some trouble with a 'time island' type configuration;
> I have a number of ntp clients connecting to one ntp server using
> its local clock driver (127.127.1.0). This network is isolated from
> the rest of the world, and for this application, having universally
> correct time is far less important than having 'node-relative'
> accurate time.

You need to have a stable time base to have good node-relative time.

Synchronizing to UTC can be a fairly inexpensive means of acquiring a
good time base. Generating a stable local time base is almost always
considerably more expensive. 

> I have a problem scenario where the client starts *before* the server
> and misses the opportunity to do the one time sync to the server (ntp
> -g). Then sometime after the server boots, the clients clocks make
> large steps to correct the difference (with a 'time reset' ntp log
> message).

This is the correct behavior for ntpd. It simply can't set the time
until it is able to poll some time sources.

Your time sensitive services should not be started until the system
clock is set.

Once solution is to make the client boot process block until the client
ntpd is at state 4. The 'ntp-wait' script in the distribution is
intended to be used for this purpose.

Another is to make the client boot process wait for the server ntpd to
be in state 4. Doing so is a trivial exercise in shell script.

> Is there a way to limit the size of a step? or spread it out over time
> more slowly?

A step is a step.

> Client config:
>
> tinker panic 0

This tells your ntpd to accept any offset with out aborting (in a
panic). However this will not solve your intial synchronization
problem.

> logfile /var/log/ntpd.log
> driftfile /var/lib/ntp/drift
> server 192.168.2.163 prefer

Using 'prefer' here is not gaining you anything because you have only
one time source.

You should use 'iburst' to speed up the initial syncronization (from ~ 5
minutes to ~ 20 seconds).

> fudge 192.168.2.163

What exactly are you trying to do here?

> Server config:
>
> logfile /var/log/ntpd.log
> driftfile /var/lib/ntp/drift
> server  127.127.1.0 iburst minpoll 4

'iburst' has no effect on ref-clocks.

> fudge 127.127.1.0 stratum 10 prefer

Using 'prefer' here is not gaining you anything because you have only
one time source.

-- 
Steve Kostecke <kostecke at ntp.isc.org>
NTP Public Services Project - http://ntp.isc.org/




More information about the questions mailing list