Path: utzoo!attcan!uunet!van-bc!sl From: sl@van-bc.UUCP (pri=-10 Stuart Lynne) Newsgroups: comp.unix.microport Subject: Re: Losing interrupts? Message-ID: <1900@van-bc.UUCP> Date: 1 Oct 88 09:42:40 GMT References: <553@micropen> Reply-To: sl@van-bc.UUCP (pri=-10 Stuart Lynne) Organization: Wimsey Associates, Vancouver, BC. Lines: 81 In article <553@micropen> dave@micropen (David F. Carlson) writes: >In article , nelson@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@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@wimsey.bc.ca {ubc-cs,uunet}!van-bc!sl Vancouver,BC,604-937-7532