Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!decwrl!ucbvax!amdcad!rpw3 From: rpw3@amdcad.AMD.COM (Rob Warnock) Newsgroups: comp.protocols.tcp-ip Subject: Re: Interrupts & Polling [was: Re: Super Cheap IP router (< $1000)] Message-ID: <25404@amdcad.AMD.COM> Date: 26 Apr 89 09:22:15 GMT References: <820@aber-cs.UUCP> <25242@amdcad.AMD.COM> <606@interlan.UUCP> Reply-To: rpw3@amdcad.UUCP (Rob Warnock) Distribution: eunet,world Organization: [Consultant] San Mateo, CA Lines: 74 In article <606@interlan.UUCP> backman@interlan.UUCP (Larry Backman) writes: +--------------- | The approach of capturing an interrupt, grabbing the appropriate | SIO registers, and queuing them for later processing worked fine | except for one nasty case... The burst of interrupts that | end of frame, CRC, start of frame, end of frame, CRC generated was | too fast for 4.77 Mhz. PC's... [...then discusses fix/hack...] | THis approach worked, but as has been previously mentioned, the rest | of the system suffered. As I recall, the SIO only had a 2 or 3 byte | FIFO and did not latch interrupts. Has a better serial chip come | out since? | Larry Backman | Interlan +--------------- No, but faster CPUs have... ;-} ;-} Sorry, that was too flip. What we did back at Dig.Comm.Assoc. to handle similar issues with our poor little 4 MHz Z80's (DCA System-350, and the like) was to build an interrupt state machine which fielded the hardware interrupts from the serial chips and stuck the results of the interrupt into a linked list (via DMA) in the Z-80's memory. Why did we need all that, given that we had my fancy two-level interrupt scheme in the first place? Well, yes, of course, there *are* limits to the two-level scheme. All I've been trying to say was that the limits are typically much higher than the common perception of interrupt handling ability for a given CPU. So a 68000 *can* handle a dozen 19200-baud TTYs... But the "DCA System 350" could have 128 idle ports all starting up from idle at once, and one poor 4 MHz Z-80 having to deal with it. [Similar to the problem mentioned by an earlier poster with dial tone in telephone systems.] This system was an upgrade from an earlier PDP-8 based net node, for which the PDP-8 was handling all the interrupts from a bus with the ports on it. [Western Digital "ASTRO" chips, but might as well have been SIOs.] When the PDP-8 finally ran out of steam, we wanted to use multiple Z-80's to share the traffic, but without inventing a new bus. So we built a little state machine to go where the PDP-8 used to go, to handle all the interrupts from the serial ports. And the Z-80's went on boards that looked sort of like another serial port to the bus. And there was a little RAM that told the state machine which Z-80 should get the status for an interrupt from a given serial port. The state machine wrote a 4-byte "packet" to the correct Z-80, consisting of {intr-type, src-port, int-status, [int-data]}. (That is, if the interrupt status on the port said "received data available", the state machine went ahead and read the data for us.) Now a Z-80 wasn't all that blindingly fast at handling interrupts, and a *lot* of people could type at once, and all "idle" ports were mapped to a common node controller Z-80 (which would assign a port to the least busy Z-80 when the port went non-idle). So we needed to be able to handle 128 interrupts at once, and without interfering with full-speed traffic that might allready be going on on one of the ports (say). The solution was to make the bus interface DMA the 4-byte interrupt packet into Z-80 RAM, and to allocate enough space for those interrupts that a given Z-80 could handle the worst-case peak interrupt load. (It was really quite cute, just a couple of chips.) When the first-level handler for "bus interrupts" saw that the incoming queue was non-empty, it fired up the second-level handler, which trundled down the DMA queue processing transmit & receive interrupts as fast as it could. So I would say if your 4.77 MHz PC wasn't fast enough to handle the SDLC inter-frame timing, you could either get a faster CPU, or make the serial port "smarter". This may mean putting a small state machine on the port card to handle the inter-frame state changes, and/or putting a FIFO on board to queue the interrupt activity. There are many solutions. Rob Warnock Systems Architecture Consultant UUCP: {amdcad,fortune,sun}!redwood!rpw3 DDD: (415)572-2607 USPS: 627 26th Ave, San Mateo, CA 94403