Path: utzoo!mnetor!uunet!husc6!cmcl2!nrl-cmf!ames!pasteur!ucbvax!CORY.BERKELEY.EDU!dillon
From: dillon@CORY.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga
Subject: Re: Practical task switch and software interrupt switching speed
Message-ID: <8803300950.AA15114@cory.Berkeley.EDU>
Date: 30 Mar 88 09:50:51 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 29

:>TEST 1:
:>	Each cycle is defined by:  A-(msg)->B, B-(msg)->A 
:>	results:	1000 cycles / second 
:>TEST 2:
:>	Each cycle is defined by: A-(msg)->SoftHndlr, SoftHndlr-(msg)->A
:>	results:	1736 cycles / second

:        In my interrupt server I have been useing shared memory with a few
:conventions applied to prevent conflicts.  Seems to me that 1700 cycles is
:at least two orders of magnitude smaller than the possble communications rate
:I can achieve.  Are you sure this is correct?

	I think you didn't read my test descriptions.  The only type of
interrupt I tested was a SOFTWARE interrupt generated continuously from a 
task.  I did NOT test HARDWARE interrupts.

	Anybody who has traced the code can tell you that CA did a 
slam-bang job on the hardware interrupts.... very little overhead for
a lot of nice features.  Assuming an interrupt handler doesn't have to
PutMsg() or Signal() anybody, it goes extremely fast.... essentially
the standard 68000 interrupt overhead plus a small number of instructions.
Throughput of at least 8000+ interrupts / sec (average), assuming your
interrupt handler doesn't need to do much.  (that is a rough figure, it
is probably even faster!)

	If your hardware interrupt *does* PutMsg() or Signal() something,
we are still talking 2500+ interrupts / sec (average).

						-Matt