On Tue, 11 Aug 1998, Henry B. Hotz wrote:

> At 1:57 PM -0700 8/11/98, Capt. Avram Dorfman wrote:
> >Is there any better info out there about dealing w/ the clock problem,
> >besides what's in the macbsd.com FAQ?
> 
> I haven't read the FAQ in a while, but I did look into this problem.
> 
> The reason the Mac keeps lousy time is that the hardware interrupt
> priorities are set according to some strange philosophy of importance that
> does not correspond to good system design.  The user is the most important
> thing so the mouse gets highest priority.  OS housekeeping is unrelated to
> serving the user so the clock gets the lowest priority.  Therefore if
> *anything*at*all* is happening in the kernel due to an interrupt of any
> kind the clock interrupt is locked out and you loose time.

That's not quite correct. The mouse is an ADB thing, and so it comes in at
level 1. NuBus and SCSI come in at 2, and the serial port comes in at 4.
So the mouse is way down there. It's just that under MacOS, the system
runs w/ interupts enabled MOST of the time.

The problem is that the NetBSD interupt structure assums a certain
priority scheme, which we don't satisfy. Among other things, the clock is
the most important interupt. :-) Also, the system uses interupt masking to
protect certain queues. Like spltty() sets the interupt masks so that the
tty queues won't be touched...

Unfortunatly for us, many of the queue-protecting interupt levels, like
spltty and splsoftnet and maybe another I'm not looking up, get
implimented as blocking at least level 1 interupts - the clock interupts.
If we were more clever, we could maybe rig things up so that these
interupt levels really just keep us from scheduling a different process
and leave interupts enabled.

Scott also has mentioned using something like how the i386 does interupts.
I don't understand it, so I can't comment. :-)

So basicly the problem's that we need to rototill how the kernel handles
interupts. :-)

Any volinteers?

Take care,

Bill