rbthomas@frogpond.rutgers.edu (Rick Thomas) (03/22/91)
In article <12536@goofy.Apple.COM> kerlyn@apple.com (Kerry Lynn) writes | In article <13990.668752214@K.GP.CS.CMU.EDU> bww+@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