Subject: Re: serial port silo overflow repair
To: Jonathan Stone <jonathan@DSG.Stanford.EDU>
From: Jukka Marin <email@example.com>
Date: 07/29/1997 15:34:25
> >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.
You have 256 possible signal combinations on an 8-bit port. :-) (Sure,
if you use all of them, you'd better have a logic analyzer or some other
device gathering the data.)
> 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.
The system clock (returned by time(3)) is drifting slowly? What kind
of timers does the Sparc hardware have? Do they generate evenly spaced
interrupts in their own or does the software have to reinitialize the
timer after every interrupt? In the latter case, I don't think you can
make the clock 100% stable on a system using more than just one interrupt
(or even if different instructions affect the interrupt latency). On the
other hand, if the hardware times generates a 100 Hz interrupt, the clock
shouldn't be drifting at all unless the system misses some interrupts
completely (or the crystal driving the timer hasn't been calibrated).
Odd that NetBSD performs worse than StunOS, anyhow..
> Uh, interrupts usually incur _lots_ of cache misses.
I guess so. But if a lowly 68030 (or even an 8-bit $1 microcontroller)
can handle the data stream, I find it difficult to believe that a fast
pentium can't do the same. :)
> 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.
Uh. I'm beginning to see why AmigaOS was so fast..
> 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?
I'm running 1.2 with some of the patches that went into 1.2.1. Something
like 1.2.07, I guess. ;)