>If you could add code in various places of the interrupt routines to
>write numbers to the parallel port (for example, on architectures
>that have one) and then monitor the port using external hardware, you
>could see just about anything you wanted.  I measure execution times
>of interrupt routines using a multimeter or oscilloscope this way. ;)

That lets you measure one piece of code, but doesnt help
identify which of many possible pieces is being a pig.

There may also be bugs in the sparc (and other) zs drivers;
we shouldn't  overlook that possibility.  

But if it turns out the clock drift on a sun4c is an order of
magnitude higher with NetBSD than with SunOS 4.1.4 on the same box,
there is _something_ screwy with interrupts.


>It's strange that a pentium class machine loses data on serial ports.
>Even without a FIFO, at 115200 bps the CPU has almost 87 us to handle
>each byte - I guess a pentium chip can run 5000-10000+ instructions in
>that time.

Uh, interrupts usually incur _lots_ of cache misses.  87 us is more
like five or six interrupts than 10k+ instructions. Even just
delivering a signal to a process is a good 8 or 9 usecs.


>I don't think it's just a few lines of code causing this.. unless it's
>a while(1) loop :-}

If you are really using an old 1.2, not currrent, I think some of it
is just driver bugs.  Are we talking about pre-1.2.1?