Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!snorkelwacker!bloom-beacon!athena.mit.edu!jik
From: jik@athena.mit.edu (Jonathan I. Kamens)
Newsgroups: comp.unix.wizards
Subject: Re: timed problems?
Keywords: timed
Message-ID: <1990May25.184349.4289@athena.mit.edu>
Date: 25 May 90 18:43:49 GMT
References: <103@bohra.cpg.oz> <1990May25.141139.14193@phri.nyu.edu>
Sender: news@athena.mit.edu (News system)
Reply-To: jik@athena.mit.edu (Jonathan I. Kamens)
Organization: Massachusetts Institute of Technology
Lines: 43

In article <1990May25.141139.14193@phri.nyu.edu>, roy@phri.nyu.edu (Roy
Smith) writes:
|> 	The real problem with timed is that you have no control over who
|> ends up being the master clock.  On our net, it usually ended up being an
|> Iris in another building 4 blocks away that I had no control over, and
|> which generally had its clock set to some totally random time.  I
|> eventually got pissed at having people come into my office complaining
|> that their $12 quartz-and-plastic Casio wristwatch kept better time than
|> their $5000 workstation.

  First of all, the procedure for "electing" a timed master does not
happen unless the '-M' option is specified on at least one of the
machines running timed.  If none of your machines start timed with '-M',
then you can control who gets to be the master, and this isn't a problem.

  Second, another problem with timed is that if there is more than one
master, then all the masters keep themselves in sync by averaging all of
their times (because they assume that none of them possesses the
absolute correct time).  This is a problem.

  The way we do things here at Athena is:

1. There is one master on each subnet.  All the other machines are slaves only.
2. The timed sources are modified so that they do not do the clock averaging
   between masters; that is, timed on the masters assumes that they have the
   correct time, no matter what.
3. All of our masters run ntpd, which makes the assumption above valid.

Therefore, timed's on masters never adjust their own time, does, and
timed's on slaves get the correct time from the ntpd-synced masters.

  This works very well, unless the master on a subnet goes down.  If
this happens (it doesn't happen very often) and it isn't noticed
immediately by the network monitor (or, at least, it isn't noticed by
any humans *watching* the network monitor :-), the workstation clocks
begin to drift until they eventually are too far off for Kerberos to
work (Kerberos has a 5-minute window), and this alerts us to the problem
so we can fix it.

Jonathan Kamens			              USnail:
MIT Project Athena				11 Ashford Terrace
jik@Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8495			      Home: 617-782-0710