🚀 go-pugleaf

In article <vdk8hdg@zola.esd.sgi.com>, olson@anchor.esd.sgi.com (Dave Olson) writes:
> In <C1I61s.5Jz@demon.co.uk> pettsj@visigoth.demon.co.uk (James Petts) writes:
> 
> | The best way to sync clocks on a small network is to use timed(1M). The 
> | man page for this is quite lucid. You will need to make sure timed is 
> | turned on using chkconfig. The actual command which turns timed on is in 
> | /etc/init.d/network, which is executed at boot.
> 
> Or large networks.  Most of the > 2000 systems on the SGI campus
> on about 100 Class C nets use timed to keep the clocks in sync.
> Another big chunk use xntp (including most of our WAN, but that
> is as much because of the group responsible for WAN sites as anything
> else, timed does work fine on WANs).


I think they use NTP to fix the clock of a single machine on each
network (i.e. "broadcast domain"), and also turn on timed with
"-F localhost" in /etc/config/timed.options.

Care must be exercised with "-F localhost" to ensure that at most one
machine on each network is so officious.  Two or more will fight and
keep the time from being syncrhonized, not to mention corrected.

You can use timeslave in the same was as xntpd to make a local time
master.  Timeslave is said to use far fewer CPU cycles, and I think it
takes less configuring than xnptd.  Timeslave does not require that the
remote time machine be running anything but common Internet Protocol
time services, while xntpd requires the remote machine to support NTP.
On the other hand, timeslave does not use an officially sanctioned or
publically reviewed synchroniziation protocol.


For most purposes, the out-of-the-box configuration of timed works for
most situations.  That default configuration is to have all machines
run `timed`, with no special forcing of the moderator.  (The `timed`
"master" is really more of a moderator that averages all of the clocks
on the network.)  To synchronize such a default network of IRIS's to
the correct time, simply use the `date` command on one of them daily or
twice daily for a month or so to correct the time.  This will cause
each machine to compute a good "timetrim value" or figure for its long
term drift in /usr/tmp/.timetrim.  A gaggle of machines all with good
timetrim values, at least one of which is always powered on, should
keep time almost as well as a $3 electronic clock.


Vernon Schryver,  vjs@sgi.com