Subject: Re: serial port silo overflow repair
To: Jukka Marin <firstname.lastname@example.org>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 07/29/1997 05:19:59
>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
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?