skraw@thiger.UUCP (Stephan von Krawczynski) (08/23/90)
>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. i said "some 100 kBytes", some meaning several (= more than 1). >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? i don't know, i just give it a try, and it comes out better. >It seems that you would always want to make the most efficient >use of those precious open bus cycles, and DMA will always be more efficient >than programmed I/O, although a 68030 tight loop might approach DMA >efficiency. have you cross-checked this with several controllers? >Ed Hanway >uunet!sisd!jeh -- best regards, stephan von krawczynski UUCP : ...!cbmvax!cbmehq!cbmger!danube!thiger!skraw PHONE: +49 9938 1664 FAX : +49 9938 1598
jeh@sisd.kodak.com (Ed Hanway) (08/31/90)
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. 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 seems that you would always want to make the most efficient use of those precious open bus cycles, and DMA will always be more efficient than programmed I/O, although a 68030 tight loop might approach DMA efficiency. Ed Hanway uunet!sisd!jeh
p554mve@mpirbn.mpifr-bonn.mpg.de (Michael van Elst) (09/01/90)
In article <1990Aug30.195419.25644@sisd.kodak.com> jeh@sisd.kodak.com (Ed Hanway) writes: >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 seems that you would always want to make the most efficient >use of those precious open bus cycles, and DMA will always be more efficient >than programmed I/O, although a 68030 tight loop might approach DMA >efficiency. Well, even a 68030 needs two cycles for a single word transfer (with a 32bit bus against a 16bit DMA they would equalize). The problem with DMA is not in the contention when DMAing to chip memory but in requesting the bus when the processor (==bus arbiter) waits in a chip memory cycle. -- Michael van Elst UUCP: universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve Internet: p554mve@mpirbn.mpifr-bonn.mpg.de "A potential Snark may lurk in every tree."
daveh@cbmvax.commodore.com (Dave Haynie) (09/05/90)
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!