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

Steve Kostecke kostecke at ntp.org
Mon Oct 15 18:45:02 UTC 2007


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

> Thanks for the reply, and for the hint toward the ntp-dev version. It does 
> indeed synch to "the local clock" within 1s; GREAT!!!

The Undiciplined Local Clock merely allows an ntpd to claim to be an
authoritative time source in the absence of a real time source.

Systems using the Undiciplined Local Clock are not really synchronized
to anything.

> If I have two server products (s1 and s2) and one client (c1), and I want to 
> run them as an 'isolated island' yet locally synchronized (very well).

The stability of this time island will depend entirely upon the
stability of the servers' clocks.

All that ntpd can do in the case of a time island is to keep all
participating clocks "together".

> I this world of mine the products are more likely to be turned off than on. 
> Yet when they do start up the started server (e.g. s1) must become server 
> for the local 'cluster' including all clients other servers (e.g. s2). If 
> however s2 is started first it will become the local server. How do I do 
> this with orphan?

Orphan mode allows a group of clocks to autonomously select a leader in
the absence of a real time source. Nothing more.

Configuring your server products to operate in orphan mode merely
requires that you insert the 'tos orphan N' line in their ntp.conf
files. 'N' is the stratum that these systems will operate at in the
absence of a real time source and should be 5, or greater.

In addition to autonomous leader selection you will likely also want
autonomous configuration. This is where a mode such as broadcast,
multicast, or manycast is useful. The chief difference between these
modes is that broadcast/multicast servers send out a packet every 64
seconds and manycast clients establish persistant unicast associations
with the manycast servers.

This may seem like an insignficant difference. But it isn't.

When a broadcast/multicast client first receives a packet from
a new server it establishes a temporary association to exchange
authentication information and to determine the broadcast delay. Then
the broadcast/multicast client terminates the unicast association and
reverts to listening for the packets from the server. If the network
conditions change substantially after the broadcast delay is calculated,
the delay may no longer be correct.

Manycast clients actively look for manycast servers. Once a manycast
client receives a response from a server it establishes, and maintains,
a unicast association with that server. At each poll any variations in
network delay are compensated for.

Here are the core server product configurations for the various modes:

# Manycast IPv6
tos orphan 6
manycastclient ff05::101 key 1
manycastserver ff05::101

# Manycast IPv6
tos orphan 6
manycastclient 192.168.0.255 key 1
manycastserver 192.168.0.255

# Multicast
tos orphan 6
multicastclient 224.0.1.1
broadcast 224.0.1.1 key 1

# Broadcast
tos orphan 6
broadcastclient 192.168.0.255
broadcast 224.0.1.1 key 1

In addition to the mode configuration you would need to set up the symmetric
keys (unless you disabled authentication altogether), specify the driftfile,
etc.

The client products would use the the *client line for your chosen mode.

> This need for always having one and only one server was the reason for 
> chosing the 'peer' concept.

When a time source is declared as a "peer" ntpd will _exchange_ the time
with that time source.

When a time source is declared as a "server" ntpd will _poll_ (i.e. ask)
the time source for the time.

This may not be what you thought you were doing.

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




More information about the questions mailing list