On 2008-11-25, Cal Webster <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> NTP Public Services Project - http://support.ntp.org/ _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
