The Mac, like most modern systems, has two clocks:

1. a Time Of Day clock that is persistent across reboots (this is what the
lithium battery powers, among other things); this is what the mac reads at
boot time to determine the time of day to start from. This clock is stable
and accurate over the long term. Set it once, forget it. Read it as often
as you like. Does not do sub-second timing.

2. an Interval interrupt that the MacOS (or NetBSD) uses to "tick" the
system's notion of time while the system is up (60 Hz, 100 Hz, whatever).
Apple used the cheapest damned *crap* for this clock, and then wired it to
the lowest priority interrupt, making it even worse.

MacOS is a terrible time keeper, unless you reboot it often (see clock #1).
If it stays up, MacOS loses time with great rapidity, unless the system is
utterly idle (not a server, and no human bashing the keyboard, or pushing
the mouse around). If you have a MacOS machine, I highly recommend getting
"Network Time 2.0.1" (a Control Panel by Pete Resnick, $5 shareware,
available from just about every Internet archive you can think of) which is
an NTP client for MacOS.

The UNIX versions for Apple hardware are not much better, because there has
not been enough attention to the interrupt lockout problem (in A/UX or
MK/Linux, or NetBSD). However, UNIX systems are more stable than MacOS, and
therefore more clearly exhibit the awful properties of the interval timing
chip and its position in the interrupt hierarchy.

In SunOS and early versions of Slowlaris, Sun had some of the same
problems: terrible clock hardware and an OS that spent too much time
locking out the interval clock interrupt. They "solved" the problem by
reading the stable Time Of Day Register (TODR) periodically. This, of
course, had to be shut off when NTP was used, and I do not recommend it for
NetBSD.

We need to rototill the kernel until we can get interrupt latencies down to
a tolerable level (i.e. keep removing spl() calls, and taking instructions
out of the interrupt service routines), which will leave us stuck with just
the bad interval clock, instead of that compounded with our own mistakes.
The best part is that if we do this work, not only will clock performance
improve, overall system performance will improve.

	Erik E. Fair <fair@clock.org>
	formerly <timekeeper@apple.com>