Bill,
	I readily admit that Apple made mistakes with the Macintosh's basic
design. You should have heard the screams of frustration from the poor guy
I know inside Apple who tried to implement full NTP for MacOS, only to
discover the limitations of the completely suckful clock hardware Apple
uses. Sub-second accuracy for that RTC chip is essentially impossible.

However, independent of the bad hardware question, there are things that we
do in software that make things worse, i.e. disabling interrupts for "long"
periods of time. This is an issue not just of good timekeeping, but of
general system responsiveness - the less we do it, the snappier the system
will respond to all interrupts, across the board.

I recognize the need to serialize operations on certain kernel data
structures to prevent inconsistent modifications, which would, in the long
run, lead to corrupted data structures and to crashes. So, when we know
that two sections of code modify the same data structure, one at an
interrupt level, and one not, the one not at interrupt level is wrapped in
an interrupt disabler. However, it is precisely in these sections of code
(both at interrupt level and not) that we should think *very* carefully,
and strive to absolutely minimize the instructions executed in such
critical sections.

The amusing thing is that we're going to have to face this issue from a
completely different angle - multiprocessor system support. Disabling
interrupts won't help there - we will need a non-interrupt-based semaphore
system to serialize access to kernel data structures for multiple
processors if we have any hope of doing SMP. I think SMP a worthy goal -
cheap MP systems are becoming available, e.g. PowerMac 9500/180MP, DayStar
Genesis MP, Sun SparcStation 10's & 20's (getting cheap on the used
market), to name a few; hell, if you wanna get really bizarre, I wonder if
it's possible to run both CPUs in an "accelerated" Mac (e.g. an SE/30 with
a faster CPU in the PDS). I'd like to be able to use their full power with
an SMP NetBSD.

Also, some things simply require guaranteed real-time response from the
system (e.g. writing a CD-ROM with a CD-R drive, or schlepping bits to an
audio device for playback) to work really right. We're going to have to
clean up not just the device drivers (frankly, it won't be enough, long
term, to simply say, "Well, then, don't use the tape drive when you're
writing a CD-ROM!"), but also modify the scheduler so that, aside from the
entirely too simple "nice" facility, the system can guarantee an
arbitrary-sized CPU time slice at particular intervals to one or more
processes. There have been quite a few papers given at USENIX over the
years on this topic.

Not everything needs to be real-time scheduled. However, some things that
we already do commonly, should be. First example that comes to mind is the
X display server, and probably your favorite X window system manager - they
should always respond immediately to the user's inputs - this is just basic
good UI practice. If we can provide some simple kernel mechanism to
guarantee that responsiveness, our system will look & feel that much better
to everyone. Put another way: "frozen mice are not nice."

I've been a professional UNIX systems programmer (kernel hacker &
everything else) for 14 years. I used to be very derisive of the people
interested in doing "real-time" hacks to the kernel. I've come around to
the point of view that having the basic real-time scheduling facility, plus
a clean enough kernel that does not give lie to the real-time scheduling,
would be a good thing for a whole lot of things that people do commonly
now; if anything, it would make the system perform better, over all. And it
in no way hurts the system we've come to know & love - I see no reason why
existing programs would not continue to run just as well on a system
modified in the way I describe (if not better), as they do now.

	good night,

	Erik