Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!lll-winken!abhg!wrangler!ssbn!bill From: bill@ssbn.WLK.COM (Bill Kennedy) Newsgroups: comp.unix.sysv386 Subject: Re: Son of FAS? Message-ID: <2058@ssbn.WLK.COM> Date: 26 Apr 91 00:10:20 GMT References: <1991Apr25.010758.1522@pegasus.com> Reply-To: bill@ssbn.WLK.COM (Bill Kennedy) Distribution: na Organization: W.L. Kennedy Jr. and Associates, Pipe Creek, TX Lines: 70 richard@pegasus.com (Richard Foulk) writes: >I recall hearing that Equinox (or someone like that) equips their >smart serial card with a driver that doesn't use interrupts. They >do some kind of polling from within one of the kernels inner loops. Polling is quite common on interfaces with a heavy load or a lot of spigots. I think (don't know because I don't have one) that Altos polls their multi user I/O cards, i.e. 64 user systems. It imposes considerable processor burden but it scoops up the stuff that's just roaring in and out. >Doing away with the interrupt overhead supposedly results in a marked >performance gain. (Seems reasonable.) It does seem reasonable if you're dealing with a gawd awful interrupt architecture like Intel and living with abysmal interrupt controllers like the 8259. On a system with decent context switch time and some adequate hardware (meaning don't make the processor work extra just to use the part) it makes sense to be thrifty with interrupts. The 80286 is probably one of the worst on earth. On a 6MHz AT&T PC6300 PLUS you can't handle a steady stream of async characters >4800bps. If you plan to do much of anything else, 2400bps is max. They document 1200bps as max. With something like the NS16550A where you can meddle with the FIFO threshold you can make a 9600bps stream interrupt at the same frequency as a 2400bps connection without FIFOs. The overhead is stopping what you're doing, saving the machine state, deciding where to go and getting there. The memory and I/O events while you're there are "free". >My question is: couldn't this same technique be used to good advantage >with the fifo-ized dumb serial cards? > >Since most smart cards gain mostly from the reduced interrupt load they >place on the system wouldn't this blur the difference a bit more? > >-- >Richard Foulk richard@pegasus.com I heard that DigiBoard's latest stuff doesn't interrupt at all. Sure, you could poll dual ported memory and any number of things, but the easiest thing to do is manage your FIFO threshold such that you take as few interrupts as possible while servicing the maximum number of I/O events. The 550A is still going to interrupt after a period of "quiet" with a character in the buffer. What makes a whole lot of sense is to service every part you can get to during the interrupt service for the one who interrupted. By that I mean if there's any output to do and the port is ready, send it the next byte and collect all input and queue it for the top level routine as long as any port has input available. You spend a few cycles but not as many as you would if each event required a separate context switch. The old Z80-SIO was a pretty good example of a part designed with interrupts in mind. If you were using it in async mode it used the two bytes that it kept for SDLC CRC as a FIFO. That meant that as long as you grabbed the first character before four characters had arrived, you were safe. They also have another thing called "auto-enables". Like any hardware feature there are two sharp edges on the blade. When you set auto-enables you would not get a receiver interrupt unless DCD was true and you wouldn't get a transmitter interrupt unless CTS was true. That sounds like an ideal thing to do but it had as many drawbacks as blessings. I've run some pretty high speed stuff with hardware handshaking through an SIO and it was a pleasure. At the same time, "pleasure" has twice as many syllables as most of the words I had for auto-enables when I really didn't need them but used them anyway. Polling makes sense when you know that you always have a lot to do. If you don't or aren't sure, then interrupts help you decide. I don't, for example, enable FIFOs in a '550A unless the baud rate is > 2400bps, you don't need it. If you become heavily loaded it might make some sense to stop interrupting and start polling until things calm down. Anybody want to write an async driver _that_ smart? :-) -- Bill Kennedy internet bill@ssbn.WLK.COM or ssbn!bill@attmail.COM uucp {att,cs.utexas.edu,pyramid!daver}!ssbn.wlk.com!bill