NTP

[Rayan Zachariassen]

vjs at 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 at gw.ccie.utoronto.ca>
> To:	rayan at 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.