Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!cbmvax!daveh
From: daveh@cbmvax.commodore.com (Dave Haynie)
Newsgroups: comp.sys.amiga.hardware
Subject: Re: DMA Controllers (was Re:   GVP Trade-in)
Message-ID: <14195@cbmvax.commodore.com>
Date: 4 Sep 90 21:11:29 GMT
References: <1898@lpami.wimsey.bc.ca> <02102.123056@thiger.UUCP> <1990Aug30.195419.25644@sisd.kodak.com>
Reply-To: daveh@cbmvax (Dave Haynie)
Organization: Commodore, West Chester, PA
Lines: 54

In article <1990Aug30.195419.25644@sisd.kodak.com> jeh@sisd.kodak.com (Ed Hanway) writes:
>In article <02102.123056@thiger.UUCP> skraw@thiger.UUCP (Stephan von Krawczynski) writes:
>>DMA (other than bitmap) runs into heavy troubles sometimes during
>>overscan-graphics (e.g.)
>[...]
>>i have seen no dma-controller yet, that didn't have problems.
>[...]
>>amigamem troughput brings the thing down to some 100 kBytes (a typical

>Well then I guess that you've never seen a HardFrame. Using the Diskspeed
>benchmark with DMA contention turned on, my disk transfer speeds slow from
>about 800k/sec to about 650k/sec, which seems completely reasonable to me.
>I don't know where you get the idea that 100k/sec is a typical bottleneck.

It certainly isn't.  The real question is, more than likely, what's the 
target of your DMA.  If you have Fast memory in the system, than the Chip
bus saturation is really only a DMA lag problem -- how long might the DMA
device have to wait before it gets the bus.  Once it has the bus, the 
transfer into Fast memory occurs at full bus speed.  If the DMA was to Chip
memory, then it's the same problem the CPU had -- waiting for retrace times.

>My question to all the DMA opponents is this: given that 4 bitplane hires
>overscanned screen DMA does eat up most of the chip memory bandwidth, why
>should processor-controlled I/O be any better than DMA at using the remaining
>bandwidth?  

It's actually worse, if it relies on any interrupt activity.  To begin the
transfer, the either CPU or the potential bus master must wait for a clear
cycle.  The bus master gets it in a single cycle, most of the time, while
any interrupt will have to wait for an instruction boundary, and then in most
cases fetch its vector from Chip memory anyway.  So, DMA or not, you are most
likely taking the largest bottleneck waiting on interrupts, not the actual 
transfer, as long as there's fast memory around.  If you have an A2620 or 
'030 system, try SetCPU V1.6 (to get supervisor stack out of Chip memory) and 
one of the MoveVBR things to get interrupt vectors out of Chip memory, and
your Chip-bus-saturated disk performance should go up, a little or alot will
depend on the 

>although a 68030 tight loop might approach DMA efficiency.

Compared with 16 bit DMA, it does approach DMA efficiency in the limit as 68030
memory access time approaches 0 (not being facetious here; one 32 bit RAM 
access can be 200ns or less, while two 16 accesses take at least 1120ns).
Of course, what you want is to build a DMA controller for the 68030 bus.  See
"A3000" for more details :-)

>Ed Hanway



-- 
Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
      Get that coffee outta my face, put a Margarita in its place!