On 2008-06-23, Steven <[EMAIL PROTECTED]> wrote: > At work, I am configuring a system which consists of six servers > (master, slave1, ... slave5) networked together but kept isolated from > any external network. > > The ONLY time requirement is that all the systems have the same time, > which does NOT need to be accurate, just consistent.
NTP synchronizes clocks to a common time base across a LAN / WAN. UTC is the most common time base; it's ubiquitous and relatively inexpensive. A useful side effect of using UTC as a time base is that the clocks are synchronized to the correct time. NTP needs a time base so that there is a target towards which to steer the clocks. The better the time base, the more stable and consistant the clocks will be. Without a time base ntpd can do little more than act as a glorified rdate. If all you want to do is (periodically) set the clocks to some common time, you might as well use rdate or timed. BTW: A ~$70 timing GPS (Garmin GPS-18LVC) can add great stability and consistancy to your time island. > All systems: (all files owned by root unless specified) > /etc/ntp.conf 644 > server 127.127.1.0 The only ntpd which should used the Undisciplined Local Clock is the one that you have chosen as a master. Append 'minpoll 4 maxpoll 4' to reduce the server's "self-sync time" to a bit under 60 seconds. > server master # LINE NOT INCLUDED ON master You should append 'iburst' to this server line to speed up the client sync from ~5 minutes to ~20 seconds (after the server becomes available.) > driftfile /var/lib/ntp/drift > broadcastdelay 0.08 The broadcastdelay line is only useful for an ntpd that is a broadcastclient. An ntpd in a unicast associatiion calculates the delay at each poll. > While the master goes through its synchronization routine (~10 mins), the > slaves > cannot obtain the time (see below). If you use 'minpoll 4 maxpoll 4' as suggested above the server's initial "self-sync time" is a bit under 60 seconds. > Even after the master is responsive, the drift file is not written to. The drift file contains the frequency correction that ntpd needs to apply to the clock. Without a timebase ntpd has no reference to use to calculate the frequency correction. If you must use NTP in this time island, you should temporarily provide the server with some real time sources for at least an hour; it will take that long for the drift.file to be populated. This will provide ntpd some information about how to control the server's clock. > How do I 'trick' ntpd into thinking it has already performed the > synchronization > therefore not completing the routine? Use 'minpoll 4 maxpoll 4' on the server as documented above to speed up the intial "self-sync time". Or switch to the current ntp-dev which, IIRC, "syncs" immediately to the Undisciplined Local Clock. -- Steve Kostecke <[EMAIL PROTECTED]> NTP Public Services Project - http://support.ntp.org/ _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
