Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!convex!eugene!swarren
From: swarren@eugene.uucp (Steve Warren)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Hard disks, DMA vs Non-DMA
Message-ID: <3112@convex.UUCP>
Date: 15 Nov 89 18:56:40 GMT
References: <8911150430.AA24506@jade.berkeley.edu>
Sender: usenet@convex.UUCP
Reply-To: swarren@convex.COM (Steve Warren)
Organization: Convex Computer Corporation, Richardson, Tx.
Lines: 51

In article <8911150430.AA24506@jade.berkeley.edu> GORRIEDE@UREGINA1.BITNET (Dennis Robert Gorrie) writes:
>
>I know this has been discussed alot already, but its still not completely
>clear to me.  I would appreciate any information regarding this subject.
>
>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.

No matter where the request comes from, the same bus cycle will have to
occur to read or write to the chip ram.  The non-DMA transfer to chip
ram will experience the same contention that the DMA transfer would.
If the DMA device has trouble where the CPU doesn't then it just isn't
glued into the bus properly.

>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?

The only thing I can think of is that maybe the DMA device is held off so
long that it overflows its buffer and has to wait for another disk rotation
to get the rest of the data.  In this case a bigger buffer would have fixed
it.  Otherwise the two devices (DMA & CPU) should both see the same contention
and suffer the same constraints.

>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 sounds like a work-around for a too-small buffer on the disk interface
card.

The only time I think you might find non-DMA faster is on 32-bit ram on
a coprocessor (where DMA is 16-bit), and you still take a performance
hit, because you can't use your cpu cycles for other tasks while you are
doing the transfer.  Of course, if the DMA device uses 100% of the bus
bandwidth then you couldn't use those cycles anyway, unless the CPU is
playing in chip-land.

>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?

How about emergency-dumping into unused fast-ram whenever contention
threatens to overrun the device buffer, then transferring from fast-to-chip
when possible.  This might save a disk rotation, if that is the problem.

--Steve
-------------------------------------------------------------------------
	  {uunet,sun}!convex!swarren; swarren@convex.COM