gilley@ndl.UUCP (Greg Gilley) (10/10/89)
Has anyone successfully ported the NTP (network time protocol) daemon to IRIX? Thanks, Greg -- ------------------------------------------------------- Greg Gilley gilley@ndl.COM [Numerical Design Limited] 919-929-2917 (voice)
rayan@cs.toronto.edu (Rayan Zachariassen) (10/12/89)
There are at least two NTP implementations for UNIX boxes (one from UMD, one from UofToronto), and the local one at least requires 2 things IRIX doesn't have: - sub-second time setting ability (nominally settimeofday()) - BSD signals Considering gettimeofday() exists, I'm surprised settimeofday() doesn't. It is probably possible to work around these and end up with an NTP that limps along, but it isn't worth the time...
lamy@ai.utoronto.ca (Jean-Francois Lamy) (10/12/89)
Should anyone wonder: interest in NTP does not necessarily have anything to do with an obsession to be within a couple femtoseconds of official earth time. A common practice around here is to keep a single copy of a program on one machine and have a shadow directory structure on the target machine with symbolic links pointing at files in the master source. I've been burned too often by compiling a file on the target machine that ends up being older than the source it was compiled from because of clock drift. Is it too much to ask to be able to keep clock accuracy within the compile time of a short C file? This symlink practice also does wonders for - keeping your makefiles squeaky clean - crashing NFS implementations (our 4D/240 has been up since yesterday at 5 without hanging since upgrading to 3.2, we're duly impressed). Jean-Francois Lamy lamy@ai.utoronto.ca, uunet!ai.utoronto.ca!lamy AI Group, Department of Computer Science, University of Toronto, Canada M5S 1A4
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (10/13/89)
Given the microsecond resolution in the IRIX adjtime(2) and the sub-second resolution in gettimeofday(2), NTP should be an easy port. Other issues such as signals should be trivial, particularly in view of the similarities between SVR3 "reliable" and BSD signals. NTP does wonders for synchronizing clocks. However, it requires each host to be individually configured. That can be a pain in large networks. Broadcast, election schemes such as that used by timed(1m) are much easier to administer, although they cannot hope for the microsecond accuracy achieved by NTP. Given the general sloppiness of UNIX time and process scheduling, fractional second accuracy for things like NFS and make(1) is usually necessary and sufficent. Better accuracy is generally an academic exercise, albeit one which I personally find a lot of fun. (Before flaming, usec time can be useful for things like network performance research and development). If I had a bunch of IRIS's near one or more NTP true-tickers, I would nominate one IRIS as a timemaster, use timeslave(1m) to synchronize the IRIS timemaster to the nearest NTP ticker, and timed(1m) to synchronize the rest of the IRIS's to the timemaster. The thousands of IRIS's in SGI's internal network are synchronized in a similar fashion. One machine listens to a WWV receiver with timeslave(1m). A second machine follows the first with `timeslave -H first` and uses `timed -M -F itself` to be the corporate timemaster. All other machines use `timed -M -G timelords`. The machines in the "timelords" YP netgroup are IP gateways between networks (i.e. routers). The netgroup permits the semi-automatic, centrally adminstrated construction of a hierachy of time keepers. I think the -G argument for timed was not present until 3.2, but the same effect, except for the central administration, is available with -F. When I checked a few minutes ago, the SGI network appears to be synchronized to about 30 milliseconds. Much better values are possible in IRIX 3.3 where the system clock can be trimmed using the values suggested by timeslave(1m) and timed(1m) in /usr/adm/SYSLOG. Timedc(1m) is a useful tool for measuring differences in time of day. Vernon Schryver Silicon Graphics vjs@sgi.com
rayan@cs.toronto.edu (Rayan Zachariassen) (10/13/89)
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: >Given the microsecond resolution in the IRIX adjtime(2) and the sub-second >resolution in gettimeofday(2), NTP should be an easy port. Other issues >such as signals should be trivial, particularly in view of the similarities >between SVR3 "reliable" and BSD signals. Re signals, it seems more to be a matter of signal masks and such, which can be overcome by careful bookkeeping and simulation functions. The more serious issue is settimeofday() (or similar capability). Here's what our local NTP wiz says about the matter: > From: Dennis Ferguson <dennis@gw.ccie.utoronto.ca> > To: rayan@ai.toronto.edu > Subject: Re: is settimeofday needed? > Date: Thu, 1 Jun 89 12:58:28 EDT > > NTP uses settimeofday() to step the time when the offset is greater > than 128 milliseconds (rather than using adjtime() to adjust it). > It does this rarely, usually just once when the program is started > after a reboot. It certainly can use better than 10 ms precision if > you can provide it, especially on a fast machine where the > gettimeofday()-add an offset-settimeofday() can be executed quickly. > What I usually see is the first step bringing the clock to within 5-15 ms, > leaving the adjustment routine to correct the remainder. > > You don't necessarily need quite that precision. You *must* be able > to step the clock to within 100 ms of where you want it, however. If > you do a step and the result falls outside the 128 ms aperture, it will > step the time again after the 10 minutes it will take to refill the > peer registers (and again, and again...). stime() isn't good enough. > > If nothing can be done, there is an option which I am not fond of. > The local clock procedure can be compiled to always use adjtime() to > adjust the clock. This was included because I once thought that > some people might find the occasional stepping of the time backwards > offensive. Trouble is, I never tested this since the time stepping > happened so infrequently. It also adds code to a critical section, > and may suffer from races between the adjustment code and the SIGIO > interrupt. In the worst case this could be debugged into service, > but it is a lot cleaner to just step the clock once in a while. Would > be a lot better to have a settimeofday(). > > Dennis One could also kluge around it by napping just enough to get to a whole-second boundary and then do the stime(), but this is pretty gross. In other words, it can be kluged but it involves a "port" as opposed to just fixing up names and recompiling.
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (10/13/89)
In article <89Oct12.150453edt.3224@neat.cs.toronto.edu>, rayan@cs.toronto.edu (Rayan Zachariassen) writes: > > > From: Dennis Ferguson <dennis@gw.ccie.utoronto.ca> > > To: rayan@ai.toronto.edu > > > > ... This was included because I once thought that > > some people might find the occasional stepping of the time backwards > > offensive. Trouble is, I never tested this since the time stepping > > happened so infrequently.... Things like cron and NeWS do not take kindly to reliving the past. Reverse time jumps are noticed around here. I speak from experience. Vernon Schryver Silicon Graphics vjs@sgi.com
cks@white.toronto.edu (Chris Siebenmann) (10/14/89)
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: | NTP does wonders for synchronizing clocks. However, it requires each host | to be individually configured. That can be a pain in large networks. It depends on what you mean by "individually configured"; often you can get away with a common configuration file on many of your hosts. We run Dennis Ferguson's xntp, and all of our workstations (Vaxen and DS3100s) have a common config file (which points them at our two fileservers). I'd expect that you could easily come up with a common configuration for the machines where you'd just be running timed(1m) on anyways and fault tolerance and falseticker detection isn't such a big problem. [If our servers go south, I don't care what happens to time on the clients; I've got bigger problems!] -- "I shall clasp my hands together and bow to the corners of the world." Number Ten Ox, "Bridge of Birds" Chris Siebenmann ...!utgpu!{ncrcan,ontmoh!moore}!ziebmef!cks cks@white.toronto.edu or ...!utgpu!{,csri!}cks