Losing interrupts?

[pri=-10 Stuart Lynne]

In article <553 at micropen> dave at micropen (David F. Carlson) writes:
>In article <NELSON.88Sep29160014 at sun.soe.clarkson.edu>, nelson at sun.soe.clarkson.edu (Russ Nelson) writes:
>> I notice that the section of the Runtime System manual that deals with
>> Writing Device Drivers and interrupts says that interrupts can be
>> lost.  Is this true?  If so, does Microport consider it a bug (i.e.
>> will it be fixed?)
>> --russ (nelson at clutx [.bitnet | .clarkson.edu])
>
>The problem is not Microport's:  its the d*mn IBM PC/AT interrupt
>controller (aka Intel 8259.)  The problem is not solvable in software
>alone, thus Microport is not to blame.  It was nice of them to tell
>you that it is a problem though so you won't pull your hair out trying
>to figure our why.  It is good device driver design to *assume* you
>will lose a critical interrupt so your design can cover its ass with
>a polling.  If the "next" interrupt time is known, a callout can be done
>to "simulate" the missing interrupt.  The rule for device drivers anywhere
>is that there is no such thing as reliable interrupts.
>

You're right, that problem is not Microports or on the 386 more generically
the System V port.

However we take note that SCO mysteriously looses far less than Microport.
The reason of course is that Microport spends a *lot* more time at spl7 than
SCO does. This exacerbates the problem that you mention.  

In my experience system interrupt overhead and time lost through use of spl7
is the primary cause of lost interrupts. At least when they are lost due to
a large influx of them.

SCO apparently has spent much time and effort in finding all places where
spl7 is needed and *not* needed and has reduced the amount of time when they
lock them out. 

For example with the tty drivers, try the following:

	stty 19200 -ixoff -echo; cat > /tmp/test

then from your terminal emulator program dump about 100kb of data to the
system. 

Even on an idle 386 system with System V you will see very few lines in the
destination file which are correct. On the same 386 running SCO you will
loose very few characters. 

SCO has also cleaned up interrupt servicing a bit. My rough guestimate for
servicing a serial tx interrupt on a 386 is 300-350 micro seconds for SCO
versus 400-450 micro seconds for System V.

Of those figures the actual overhead for the interrupt servicing is probably
about 150 vs 200 with the balance being spent in the actual serial driver
interrupt routine.

Let's take a poll. Will anyone using a Trailblazer on a Dumb serial port
under any type of Unix system send me a message on how successful it runs uucp
at 9600 or 19200.  What is your normal operating parameters.

I'll summarize if enough people reply.

As a further example; here on van-bc I can run two Trailblazers fairly
successfully at 9600 on dumb ports (van-bc is a 10Mhz 68010 based system). I
cannot however run one at 19200. Unfortunately somewhere in the kernel
someone is raising spl7 at odd intervals causing the uucp connection to drop
a character and time out. 

Running two at 9600 works because even though the net throughput is the same 
as one at 19200, and the system overhead is actually higher, the time to 
fill the three character buffer in the 8274 is twice as long at 9600. 
About three milli seconds versus one and a half. I can pull the stuff out 
very quickly but someone is getting spl7 for something right around the 
one and a half milli second range, and sometimes the driver just can't 
quite get the data out before that next character arrives. But there is 
plenty of time to get it out when running at 9600, the 8274's buffers 
havn't even filled up yet.

It's real close too, uucp will generally run for about five to fifteen
seconds before loosing that character.


-- 
Stuart.Lynne at wimsey.bc.ca {ubc-cs,uunet}!van-bc!sl     Vancouver,BC,604-937-7532