[ntp:questions] Tricking NTP's driftfile

Steve Kostecke kostecke at ntp.org
Tue Jun 24 19:03:34 UTC 2008

On 2008-06-23, Steven <sed_facebook at vt.edu> wrote:

> At work, I am configuring a system which consists of six servers
> (master, slave1, ... slave5) networked together but kept isolated from
> any external network.
> The ONLY time requirement is that all the systems have the same time,
> which does NOT need to be accurate, just consistent.

NTP synchronizes clocks to a common time base across a LAN / WAN. UTC
is the most common time base; it's ubiquitous and relatively
inexpensive. A useful side effect of using UTC as a time base is that
the clocks are synchronized to the correct time.

NTP needs a time base so that there is a target towards which to steer
the clocks. The better the time base, the more stable and consistant the
clocks will be. Without a time base ntpd can do little more than act as
a glorified rdate.

If all you want to do is (periodically) set the clocks to some common
time, you might as well use rdate or timed.

BTW: A ~$70 timing GPS (Garmin GPS-18LVC) can add great stability and
consistancy to your time island.

> All systems: (all files owned by root unless specified)
>   /etc/ntp.conf 644
>     server

The only ntpd which should used the Undisciplined Local Clock is the one
that you have chosen as a master. Append 'minpoll 4 maxpoll 4' to reduce
the server's "self-sync time" to a bit under 60 seconds.

>     server master # LINE NOT INCLUDED ON master

You should append 'iburst' to this server line to speed up the client
sync from ~5 minutes to ~20 seconds (after the server becomes

>     driftfile /var/lib/ntp/drift
>     broadcastdelay 0.08

The broadcastdelay line is only useful for an ntpd that is a
broadcastclient. An ntpd in a unicast associatiion calculates the delay
at each poll.

> While the master goes through its synchronization routine (~10 mins), the slaves
> cannot obtain the time (see below).

If you use 'minpoll 4 maxpoll 4' as suggested above the server's initial
"self-sync time" is a bit under 60 seconds.

> Even after the master is responsive, the drift file is not written to.

The drift file contains the frequency correction that ntpd needs to apply
to the clock. Without a timebase ntpd has no reference to use to
calculate the frequency correction.

If you must use NTP in this time island, you should temporarily provide
the server with some real time sources for at least an hour; it will
take that long for the drift.file to be populated. This will provide
ntpd some information about how to control the server's clock.

> How do I 'trick' ntpd into thinking it has already performed the synchronization
> therefore not completing the routine?

Use 'minpoll 4 maxpoll 4' on the server as documented above to speed up
the intial "self-sync time". Or switch to the current ntp-dev which,
IIRC, "syncs" immediately to the Undisciplined Local Clock.

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

More information about the questions mailing list