NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/sys/sgi/18453

Internet Message Format | 1993-01-04 | 4.2 KB

Path: sparky!uunet!europa.asd.contel.com!gatech!usenet.ins.cwru.edu!agate!ames!olivea!sgigate!sgi!rhyolite!vjs
From: [e-mail] (Vernon Schryver)
Newsgroups: comp.sys.sgi
Subject: Re: NTP Time?
Message-ID: <[e-mail]>
Date: 4 Jan 93 19:37:50 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: Silicon Graphics, Inc.  Mountain View, CA
Lines: 69

In article <[e-mail]>, [e-mail] (Peter Shenkin) writes:
> In article <[e-mail]>
>  [e-mail] (Vernon Schryver) writes:
>
> >`xntpd` or `timeslave` can be used to synchronize the clock of one
> >machine to an external standard, such as machine on the Internet with a
> >good NTP connections, a radio receiver, or (with timeslave) just some
> >other machine offering standard TCP services that has a trusted clock.
> >Then `timed` can be used to synchronize a passle of IRIR's to the first
> >machine....
>
> I've been looking into this for our machines here.  I have several questions:
>
> 1.  If there's a trusted time-server, why not run timeslave on all machines,
>     rather than running timeslave on one and timed on the others?  What
>     is the difference between timeslave and timed -H?

Timeslave and (generally) (x)ntpd requires every particpating machine
to be manually configured.  With timed, things work "out of the box".
NTP and timeslave give you more control over things, more opportunities
to work around strange network arrangements, more adjustments to "improve"
time, and more chances to mess things up.

People with "system administrator" in their job titles or functions or
clock watching as a hobby almost always prefer timeslave and (x)ntpd to
timed.  There are more knobs to fiddle in timeslave and (x)ntpd than in
timed.  I prove that rule by violating it; I get my jollies fiddling
with the source.


> 2.  Would there be any advantage to someone in my position's running NTP
>     rather than timeslave/timed?  My position is as follows:  several
>     machines at Columbia will be running NTP synched to a Higher Authority;
>     as I understand it, several hosts will be NTP servers in some sense,
>     to provide redundancy.  We could synch to them either by means of
>     timeslave/timed or else by running NTP ourselves.  My understanding
>     so far is that the advantage of running NTP would be a smaller load
>     on system/network resources (though I find it hard to imagine that
>     timeslave/timed constitutes a heavy load), and possibly the ability
>     to make better use of the three-host redundancy.  For example, if we
>     were running timeslave or timed -H to some trusted host, and the
>     trusted host went down, there might be problems.  Maybe under NTP
>     we could put in the names of all three trusted hosts.  On the other
>     hand, why should I have to obtain and compile and maintain another
>     program if my native SGI (and ubiquitous UNIX) tools can do the job?
>     -- again, unless there's some compelling advantage.  So I guess that's
>     what I'm asking:  is there?

There is no significant difference among any of the programs in the
network or CPU resources they require.

The advantage of using NTP on all your IRIS's is the "three-host
redundancy" that you mention.  There is no other technical advantage to
using NTP instead of timeslave to link a `timed` master to the rest of
the Internet.  There is the non-technical trade-off of using a
non-standard protocol to synchronize one of the IRIS's (timeslave)
versus using a standard protocol with an (officially) unsupported
implementation (NTP).

In your position, using NTP everywhere (no timed or timeslave anywhere)
would give the most technically reliable time, but would require more
and more careful system administration.  For example, you would have to
remember to install and configure xntpd on any new machines or machines
with scrubbed disks.  The most reliable time in a practical sense in
your position is to `timeslave` the most reliable IRIS you have to your
best NTP box and timed linking the rest to the IRIS running timeslave.


Vernon Schryver,  [e-mail]