Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!interlan!backman
From: backman@interlan.UUCP (Larry Backman)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Interrupts & Polling [was: Re: Super Cheap IP router (< $1000)]
Message-ID: <606@interlan.UUCP>
Date: 25 Apr 89 13:24:10 GMT
References: <820@aber-cs.UUCP> <25242@amdcad.AMD.COM>
Reply-To: backman@interlan.UUCP (Larry Backman)
Distribution: eunet,world
Organization: Interlan, Inc., Boxborough, MA (1-800-LAN-TALK)
Lines: 41

>By keeping the 1st-level interrupts *very* lightweight (*don't* save any
>context [except maybe a working reg or two], just grab the data, queue it,
>then queue your 2nd-level handler), you can afford a *lot* of interrupts,
>many more than you would think. And by leaving hardware interrupts *enabled*
>during [almost] all 2nd-level processing, you don't lose data due to
>latency problems.
>

	[]

	I've been following the "interrupts kill" discussion with interest.
	Its been a few years since I did SDLC/HDLC with the SIO but as I
	remember...

	The approach of capturing an interrupt, grabbing the appropriate
	SIO registers, and queuing them for later processing worked fine
	except for one nasty case.  That case was the situation where a
	large data framewithout the final bit was followed immediately by
	a Receive Ready (3 or 4 bytes).  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.  If I remeber correctly, the only
	approach that worked was a modified interrupt queue/handler.  The
	interrupt was scanned as it was processed, if it was "lightweight"
	i.e. a data interrupt, or one of the less critical start or end of
	frame ones it was queued for later processing.  If it was a
	"heavyweight" interrupt, i.e., the CRC for frame two in the
	situation mentioned above, it was processed immediately.  The
	catch of course was that before the "heavyweight" interrupt could
	be processed, the queue of "lightweight" interrupts had to be 
	completely serviced to keep things in their proper order. Now,
	here we are at interrupt time, and a very critical one, doing
	complete servicing of not one, but a whole string of interrupts.

	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