[ntp:questions] Synchronizing to LOCAL(0): Startup time

Steve Kostecke kostecke at ntp.org
Fri Oct 12 16:55:53 UTC 2007

On 2007-10-12, Bert Gøtterup Petersen <BUP at bang-olufsen.dk> wrote:

> I am trying to use NTP to synchronize embedded audio-video products
> (running Linux).

Linux and B&O ... interesting.

> Once the products are synchronized everything is working very well,
> but I have a problem at start up. I use a set of products to work as
> peers, as can be see in the example of an ntp.config file:

Why peers?

> peer  iburst burst prefer minpoll 4 maxpoll 4 prefer
> peer  iburst burst prefer minpoll 4 maxpoll 4 prefer
> peer iburst burst prefer minpoll 4 maxpoll 4

ntpd intelligently manages the poll interval. Why do you need to clamp
it down?

The last time I tested peer associations (as opposed to server
associations) I noted that iburst had no effect on speeding up
synchronization with the peers.

burst (as noted elsewhere) merely multiplies the number of poll packets
by 8; it does not speed up the association.

> server iburst # local clock (LCL)
> fudge stratum 6 # LCL is unsynchronized flag1 0 flag2 0 flag3 
> 0 flag4 0 stratum 0

Orphan Mode is the suggested replacement for the Undiciplined Local
Clock (127.127.1.x). I'll discuss it more at the end of this article.

> In addition a set of products are used which are only NTP clients.

Are they reflected in the ntp.conf shown above (e.g as the peers) ?

> As can be seen I use the local crystal as fall back, and this is were
> the problem arises.

The Undiciplined Local Clock (LocalCLK) does not _poll_ the local crystal
as such.

> When the first of the peers is started it takes about 4 minutes before is 
> has synchronized with to its local crystal

It's not actually synchronized to the "local crystal".

ntpd will not select the LocalCLK (or a real ref-clock, for that matter)
until enough data has been collected. For the purposes of this
discussion "enough data" means 4 polls. The first poll occurs shortly
after ntpd starts up. The remaining three polls occur at the minpoll
(which defaults to 64 seconds) and take 3x64 = 192 seconds or 3.2
minutes. Add 10 seconds for ntpd to start up and make the first
poll and you're at 202 seconds or 3.36 minutes.

If you set the maxpoll for the LocalCLK to 4 (16 seconds) the initial
polls will be complete in approximately (3x16)+10 or 58 seconds.

If this isn't fast enough you could always modify the source code.

> and further 3 minutes before a clients can see that the server is in
> synch, i.e. starting its synch process.

That's because the clients need to collect enough data from the server
before selecting it as the sys_peer.

> How can I get the initial synchronization to a local crystal down from 
> several minutes to a few seconds?

I just ran some tests which showed that a client can "sync" to an Orphan
Mode server in roughly 7 seconds after both ntpds are simultaneously

Here's stripped down versions of the configuration I used:

# Server (named 'my_server')
driftfile /path/to/the/driftfile
tos orphan 6

# Client
driftfile /path/to/the/driftfile
server my_server iburst minpoll 4


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

More information about the questions mailing list