Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!usc!apple!sun-barr!newstop!sun!pepper!cmcmanis
From: cmcmanis%pepper@Sun.COM (Chuck McManis)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Hard disks, DMA vs Non-DMA
Message-ID: <127914@sun.Eng.Sun.COM>
Date: 15 Nov 89 19:14:39 GMT
References: <8911150430.AA24506@jade.berkeley.edu>
Sender: news@sun.Eng.Sun.COM
Reply-To: cmcmanis@sun.UUCP (Chuck McManis)
Organization: Sun Microsystems, Mountain View
Lines: 77

Dennis Robert Gorrie writes:
> The story goes, DMA is faster.  But, as many people point out, it sometimes
> is slower than non-DMA, when there is contention for the bus.  Case in point
> is the hi-res interlace screen situation where co-processors and your DMA
> hard disk device are contending for cycles on the coprocessor bus.

DMA == Direct Memory Access. If a peripheral does DMA it will always be faster
than a non-DMA device for one simple reason. The path between the peripheral
and it's destination is shorter. Consider the following diagram :

              +---------------+           +-----+            +--------+
	      |               |           |     |            |        |
Device >----->+ I/O Interface +--+    +-->+ CPU +--+    +--->+ Memory |
	      |               |  |    |   |     |  |    |    |        |
              +---------------+  |    |   +-----+  |    |    +--------+
	                         V    ^            V    ^
			/--------+----+------------+----+-----------/
		       /     (1) +----+            +----+          /
		      /      (2) +----------------------+         /
		     /             Computer Backplane            /
		    /-------------------------------------------/
(1) is the path of Non-DMA data, it is read by the CPU from the Peripheral
    interface, then it is written by the CPU into the destination memory 
    address. This involves one Read and one Write cycle on the main bus.

(2) is the path of the DMA data, it is written directly to memory by the 
    peripheral interface. This involves a single write cycle on the main
    bus. 

Many things compete for the bus, in the Amiga these can be the CPU and 
other peripherals. Further the bus is sometimes blocked by the CPU waiting
on information to come out of "Chip" memory. This is particularly true 
during high overscan situations. For any given set of bus cycles the
DMA device will transfer more data over the bus then the CPU would be
able to move it over the bus.

Some people have been lead to believe that DMA devices are sometimes slow
because the 2090 interface is slow in transferring data sometimes and other
non-DMA drives seem to be faster. This is not due to non-DMA being faster,
rather it is due to the 2090 being incapable of dealing with bus inactive
conditions. It's internal FIFO overflows and it must abort and restart the
entire transfer. This is a bug in the 2090 and you will notice that the 
2091 (and A590) don't have this problem. 

>Then someone says a 'proper' DMA device is faster, than non-DMA, even for the
>situation above.  How is this so?  What is a 'proper' DMA device?

For any number of cycles, DMA will be faster than non DMA because it can
transfer data at full bus speeds. A 'proper' DMA device is one that can
operate even when the bus has become unavailable for relatively long 
periods of time. This implies some flow control on the peripheral interface
itself, or sufficient buffering to allow for the maximum bus latency delay.

>The current solution, for DMA controlers with slow loads during the above
>situation, from my understanding, is to limit the DMA transfer to small
>block sized transfers.  It seems that this is basicaly just like a non-DMA
>transfer.

That is the 2090 solution because by limiting the transfers to sizes that
are less likely to overflow it's inadequate FIFO so that it maintains its 
DMA performance advantage. Other controllers such as the HardFrame, and 2091
do not have this problem.

>What about other solutions?  Like dynamicaly allocating DMA transfer sizes
>based on device priority, and contention, ect.  Isn't that what Bus Mastering
>is all about?

Again, if you design your board to be able to deal with long bus latency
times as many people have, then you don't have any problem. You are 
apparently confusing a weakness with the 2090 design, with a problems in
the concept of DMA. They are not related at all. 


--Chuck McManis
uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@Eng.Sun.COM
These opinions are my own and no one elses, but you knew that didn't you.
"If it didn't have bones in it, it wouldn't be crunchy now would it?!"