slow clock of mac68k

On Wed, Nov 15, 2006 at 07:57:17PM +0100, Hauke Fath wrote:
> The '030 Macs have an interrupt hierarchy where the
timer interrupts
> have a low priority, which means that ticks get lost as
soon as there
> is any significant I/O load. The Quadra 700 and later
'040 Macs can be
> switched to a different hierarchy which gives the timer
interrupts
> higher priority.  Apple apparently learned from its
A/UX experiences.

I always wondered which device drivers were worst about not
letting
clock ticks run, and seeing if there were ways to
"flash" in the driver
to let the clock ticks update.

-- 
  Aaron J. Grier | "Not your ordinary poofy goof."
| agrierpoofygoof.com
              "silly brewer, saaz are for pils!" 
--  virt

At 19:50 Uhr +0100 17.11.2006, Aaron J. Grier wrote:

[lost clock interrupts]

>I always wondered which device drivers were worst about
not letting
>clock ticks run, and seeing if there were ways to
"flash" in the driver
>to let the clock ticks update.

The problem may be that the Macintosh is DMAless (apart from
the IIfx and
the Quadra 840av, where we don't support the feature), and
its cpu does all
I/O. This is as good as a hard realtime constraint: If you
"shell out"
from, say, the SCSI driver, to work on a clock interrupt,
and don't return
in time, you may lose a SCSI block.

I can say for sure that in the iwm(4) driver, running at
splhigh is not to
protect common data structures, but to do realtime work.
iwm(4) is
definitely the worst offender here (late-seventies 8-bit
technology), and
an alien in a multitasking world...

	hauke

--
"It's never straight up and down"     (DEVO)