Steve Allen <wormey@eskimo.com> reminds me that Apple wired
up the 68k macks with the clock at lowest hardware priority.
This currently makes Macs incapable of keeping accurate time 
under heavy interrupt load.

Is there some compelling reason not to work around this in software?

The obvious fix is to poll for a pending clock-tick interrupt at some
(or maybe even all) higher hardware interrupt priorities.  The idea is
to check on exit from the higher-level interrupt handlers to see if a
clock tick is pending; and if so, to call hardclock() in such a way
that the CLKF_ macros decide the system is `busy' and just do
hardclock() processing, not softclock().  (A global variable set by
the polling code and cleared after calling hardclock() would suffice).
Time vultures might even considering polling *before* the higher
hardware-priority interrupts.

Other m68k-based systems manage to service clock interrupts at ~60 Hz,
even with zs chips, so a Mac should be able to keep up at ~100Hz.
Is there something else special about Macs that makes this infeasible?


Failing that, maybe the release notes for the mac86k port could say
that NetBSD doesn't keep accurate time and to not run xntpd??