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

David Woolley david at ex.djwhome.demon.co.uk.invalid
Sat Oct 13 12:46:18 UTC 2007

In article <OFF5A373C2.BA0F7918-ONC1257372.0035C376-C1257372.00420F5B at bang-olufsen.dk>,
BUP at bang-olufsen.dk (Bert Gøtterup_Petersen) wrote:

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

Are these in a single broadcast area?  If so, your application appears
to require timed, not ntpd.  Use of ntpd without a source of true time
(now commonly called an isolated time island) is considered a secondary use,
and ntpd is not optimised for that use, and doesn't have parameters to
tell it that it needs to operate any differently from when used for
its intended use.

> 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
> server iburst # local clock (LCL)

If this is typical of all of the machines, you have a potentially unstable
configuration.  The preferred method, these days, for running an isolated
time island, is to use orphan mode, with no local clocks defined at all.
If you do define local clocks, you should use a strict hierarchy, using
server, not peer, and set the stratum to differ by at least two between
hierarchy levels.

> fudge stratum 6 # LCL is unsynchronized flag1 0 flag2 0 flag3 

Unless you have a five (four?) level hierarchy, you should not set the
local clock stratum this low.  The reason you might want to set it this 
low is that you have something other than ntpd disciplining the system 
software clock.  You don't use zero in this case, because ntpd doesn't 
know when that something has failed, so clients need to have a chance to
use a server where ntpd directly accesses the reference clock, in preference.

The reason for setting high stratum numbers is to prevent your bogus time
accidentally being used by a machine that has access to traceable time.

One other thing to be aware of with this sort of configuration is that
the maximum safe static frequency error is halved, to somewhat under
250ms, because you may end up synchronising to something which is at
the maximum static error in the opposite sense to your static error.

You don't have a drift file.  Without a drift file, ntpd will do a full
time and frequency calibration whenever it starts.  That normally takes
15 minutes or more.  It doesn't recognize the use of the local clock as 
special, because using the local clock as source is considered abnormal.

If you do have a drift file, the standard ntpd configuration will accept
initial errors up to 128ms, so you will have to wait for those to be
removed from the system using the normal control loop (which has rather
a large time constant).  I think the very latest versions may have had
some changes in this area, for initial startup.

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

If this is the configuration file on all the servers, you are not using
the local clock as the fallback, you are using the local clock as the
primary reference.

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

The way the local clock is defined, it is *always* synchronised with its
local crystal!  What takes some time is for ntpd to believe the time well
enough for it to pass it on to clients and downstream servers.  ntpd 
doesn't know you are running an isolated time island, so doesn't make
a special case of the local clock.

In the intended usage, it would be very bad for ntpd to start serving time
from the local clock before having got reliable times from peers and 
servers, as it could end up serving a completely bogus time to the rest
of the network, and then, suddenly jumping to the correct time.

To get the master server to serve its local clock instantly, you would 
need a strict hiearchy, so that there was a clear master, and new option to
tell the server that its software clock was the definite time source for
the local time island.

More information about the questions mailing list