Lost interrupts on Sparcstations and what xntpd does about it

[Rick Thomas]

In article <12536 at goofy.Apple.COM> kerlyn at apple.com (Kerry Lynn) writes
| In article <13990.668752214 at K.GP.CS.CMU.EDU> bww+ at K.GP.CS.CMU.EDU (Bradley 
| White) writes:
| > If you are losing interrupts with any regularity, forget about using NTP
| > to synchronize clocks---it will be continually confused by the shifting
| > frequency of the local clock.  Something coarser will suffice.
| 
| Is this statement accurate?  If so, wouldn't this be an "implementation 
| issue" of the first rank?  Can such a situation be mitigated by lowering
| the advertised precision of one's clock or by using "mains" parameters
| for the PLL?  I'd really appreciate hearing from people who've faced
| this problem and solved it.

Don't worry, that statement is actually not accurate.  indeed, it is one
reason why xntpd updates drift and compliance estimates based only on
'slew's and not on 'step's.  If the clock gets too far out of whack (as it
does on Sparcstations when interrupts are getting dropped alot) xntpd just
does a "step" adjustment and starts over from scratch.  If the clock is
only out by enough to fit within the "window" of slewing (128 ms usually,
but it can be configured all the way up to 499 ms without having to make
major code changes) then xntpd does the appropriate adjtime and also makes
adjustments to its own idea of how much the clock is drifting.

Experience shows that this actually copes quite well with the situation
encountered in Sparcstations (and other machines too)  When interrupts are
getting dropped at a large (hence unpredictable) rate, the clock advances
by a series of discrete steps but stays on track as well as can be
expected under the circumstances; when things are going good, and
interrupts are not being dropped (or are being dropped only infrequently)
then the algorithm can get a good handle on the actual amount of drift in
the hardware clock, and it does.

			WARNING
The following is based mostly on rumor and surmise.  Will somebody who
knows for sure please speak up?

What actually seems to be happening on Sparcstations is that the S-bus
standard specifies that all S-bus peripherals will have a minimal handler
in ROM on the S-bus card.  (Do you think they learned this trick from the
Apple II by any chance?)  That handler is not written in SPARC assembler
as you would naturally assume, but rather in FORTH, so that the same card
can be used on any machine that provides an S-bus, regardless of the host
CPU type.  One of the specifications of the S-bus is that the host machine
will provide a FORTH interpreter in its own boot-ROM for use in driving
S-bus cards.  Now Sun, in their wisdom, seem to feel that nobody would
*ever* want to run for an extended period of time directly on the console
without using a windowing system, so to avoid having to write a console
driver in C (or SPARC assembler) for every possible different kind of
console, they just use the single standard FORTH driver interface.  This
accounts for the fact that Sparcstation consoles without windowing
programs are so Gawd-awfully slow (2400baud seems an appropriate
comparison) and (because the FORTH interpreter is run with interrupts
turned off -- who knows why?) it also accounts for the dropped clock
interrupts.

Enjoy!
Rick