At 2:47 PM -0800 11/20/02, David Gatwood wrote:
>On Wed, 20 Nov 2002, Dave Huang wrote:
>
>>  On Wed, 20 Nov 2002, David Gatwood wrote:
>>  > As an added note, certain drivers that don't block for a long period of
>>  > time and need low latency (the ADB driver comes to mind) should probably
>>  > be handled directly as it is now.  Depending on the IPL of the ADB
>>  > hardware, this might even improve perceived responsiveness on the console.
>>
>>  Sounds great to me :) Another device that needs its interrupts to be
>>  handled promptly is the serial port; I seem to recall that we can keep
>>  up with 57600 baud as long as there's no disk access (it's been a while
>>  since I've used the serial port though, so I may be recalling
>>  incorrectly :). Maybe with your changes, we'll be able to do the same
>>  even with disk I/O going on?
>
>That's the theory.  The effect should be equivalent to bumping disk I/O to
>a lower IRQ without actually rewiring the hardware....

Not to be a wet blanket, but I have vague memories from writing a 
synchronous serial driver using a Z8530 once about 20 years ago.  The 
chip had some funnies where you needed to do a reset within one bit 
time or you lost data (if frames arrived back-to-back).  The only way 
to get from ~50Kbps to ~700Kbps was to deliberately discard some of 
the error check bits at the end of the frame.

The problem was not completely covered in the chip specifications, 
and it may not be applicable to asynchronous operations.  Just 
realize that CPU interrupt latency may not be the only issue in 
getting high-speed serial communications.
-- 
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu