[ntp:questions] Isolated Network Drift Problem

Steve Kostecke kostecke at ntp.org
Wed Nov 26 18:06:11 UTC 2008


On 2008-11-25, Cal Webster <cwebster at ec.rr.com> wrote:

> On Tue, 2008-11-25 at 21:10 +0000, Steve Kostecke wrote: [...]
>
>> > Unfortunately, connection to the Internet is not an option I'm
>> > allowed to consider.
>>
>> Another option you could consider is the dumbclock driver. This uses
>> a serial link to transfer time stamps from one system to another.
>
> Thanks but I'm afraid this would be of little use to me since most of
> the systems are separated by brick and mortar, connected to each other
> through DSL links on site.

This was a suggestion of a means of getting timestamps to the primary
time server in your time island. Distribution of the time to other ntpds
would occur over the network.

> So, if I wanted to setup my 4 NTP servers to look to the one with the
> best local clock as the master (if you've been following this thread)
> but fall back to Orphan mode when it became unreachable, could you
> give me an example of how the configs might look? I could later point
> them to the one with the GPS time reference as master when I get it
> setup.
>
> My main concern is to continue to have an NTP server available in
> each of 3 buildings even if they loose connectivity with each other
> for some reason. I currently have at least one NTP service running in
> each building, serving clients on MS Windows, Linux, and various Unix
> flavors.

You need to set up the time servers for the orphan group in a "mesh"
(i.e. they all need to poll each other for the time). You may use any
NTP association mode for this purpose.

The following examples are incomplete; you need to add the drift file,
any desired restrictions, etc.

*** Unicast:

# Master Time Server *
# setting minpoll 4 makes this ntpd available to clients
# approximately 50 seconds after startup
server 127.127.1.0 minpoll 4
fudge  127.127.1.0

# Bldg A Time Server
tos orphan 10
server master.server.ip.address iburst
server bldg.B.ip.address iburst
server bldg.C.ip.address iburst

# Bldg B Time Server
tos orphan 10
server master.server.ip.address iburst
server bldg.A.ip.address iburst
server bldg.C.ip.address iburst

# Bldg C Time Server
tos orphan 10
server master.server.ip.address iburst
server bldg.A.ip.address iburst
server bldg.B.ip.address iburst

If you have additional time servers create similar ntp.conf files and
make sure that each servers knows about the others. 

*** Manycast:

This mode provides automatic server discovery and creates unicast
associations. To use Manycast your server must be configured for to
support Multicast addresses _or_ you need a site-wide broadcast address
(i.e. every one on the same subnet). You also need to be comfortable
with setting up symmetric keys.

One advantage to using Manycast mode is that you can drop in additional
time servers without reconfiguring all of your existing time servers.

# Master Time Server *
# setting minpoll 4 makes this ntpd available to clients
# approximately 50 seconds after startup
server 127.127.1.0 minpoll 4
fudge  127.127.1.0
manycastserver broadcast.or.multicast.address

# Bldg Time Servers
# each "building time server" uses this file
tos orphan 10
manycastclient broadcast.or.multicast.address key N
manycastserver broadcast.or.multicast.address

* Note:

I am suggesting the use of the Undisciplined Local Clock on your Master
Time Server primarily beacuse The Undisciplined Local Clock has some
"knobs" which may be used to interactively trim its performance through
ntpdc. Orphan Mode, on the other hand, does not provide these knobs.

There is also a rootdispersion issue with Orphan Mode for stable
releases up to 4.2.4p5 and for development releases before 4.2.5p101. I
am currently conducting some tests.

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




More information about the questions mailing list