Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!unmvax!ncar!ames!ucsd!orion.cf.uci.edu!uci-ics!zardoz!tgate!ka3ovk!drilex!axiom!linus!mbunix!rachamp From: rachamp@mbunix.mitre.org (Richard A. Champeaux) Newsgroups: comp.sys.amiga.tech Subject: Re: DMA or polling (was Re: GVP controller) Message-ID: <63241@linus.UUCP> Date: 11 Aug 89 13:03:52 GMT References: <8908092130.AA23369@jade.berkeley.edu> Sender: news@linus.UUCP Reply-To: rachamp@mbunix (Champeaux) Organization: The MITRE Corporation, Bedford, Mass. Lines: 81 In article <8908092130.AA23369@jade.berkeley.edu> 451061@UOTTAWA.BITNET (Valentin Pepelea) writes: >Steve -Raz- Berrywrites in <120232@sun.Eng.Sun.COM> > >> In article <8908072207.AA14796@jade.berkeley.edu> 451061@UOTTAWA.BITNET >> (Valentin Pepelea) writes: >> >> >The net result is that the processor therefore spends less time on the data >> >transfer and is available more often for other concurrent tasks. >> >Unfortunately this means that there are two transfers occurring, a slow >> >DMA from hard disk to the cache, and a fast CPU transfer from the cache >> >to internal memory. Other controllers such as the A2090 and HardFrame DMA >> >directly from the harddrive into internal memory, thus tying up you CPU >> >much longer. >> >> Yikes! I'm sorry, but I TOTALLY disagree with you on this one. >> Logicly, if you look at the time to complete a given task, based only >> on the number of bus cycles it takes to transfer a given block of data, >> DMA will always win. Period. Unless of course your DMA circuitry is >> totally braindead. > >Clearly you don't understand, or perhaps I did not explain well. The bottleneck >here is the speed at which the hard disk turns, and therefore the rate at which >data is available to the DMA channel. That is why DMAing directly from the hard >disk to internal memory is a loosing proposition. GVP provides a cache into >which it reads from the disk while leaving the Amiga's 680x0 alone. Only then >does it transfer the data from the cache into internal memory at full speed, >without having to wait for the mechanical limitations of the hard disk. You keep claiming that the transfer from the disk is slow, and the transfer by the CPU is fast. Have you ever bothered to calculate the speeds? The minimum loop required for transferring words from GVP's onboard buffer to main memory is the following: loop: move (a0)+,(a1)+ (24 clock cycles) dbra d0,loop (18 clock cycles) The execution times were found in Motorola's 68000 programmer reference manual. So it takes 42 clock cycles to transfer 2 bytes. At 7.12MHZ, that 5.89 us to transfer 2 bytes, or 339 kbytes/sec, maximum. Assuming no transfer time from the disk, and no track to track stepping time, the maximum transfer raste is 339 kbytes/sec. I don't even pretend to know all of the delays and bottlenecks associated with a SCSI drive, but lets look at the on you mentioned: the disk rpms. Hard disk drives, I believe, spin at 3600 rpms. My ST296N has 34 sectors per track with 512 bytes per sector. It is formatted with an interleave of 1. Assuming that there are no other delays, the disk itself can deliver 1.04448 Mbytes/sec. I realize that there are a bunch of other factors, but the drive rpm is not the bottleneck. Your argument now seems to be sitting on a pretty poor foundation. You also claim that part of the advantage of the GVP is that the processor can do other things while data is being transfered to the onboard buffer. Lets look at that. My HardFrame is giving me 655 kbyte/sec reads. Lets call the time it takes to transfer a chunck of data X. The transfer rate from GVP's onboard buffer to main memory is roughly half that of the HardFrame, so lets call it's transfer time 2X. The time it takes to transfer from the drive to the onboard buffer can not be bigger than X, so lets also call it X. Lets also assume that with the HardFrame, the processor can not access the bus durring the transfer. So, the time it takes for the transfer to complete on the GVP is 3X. Durring that time, the processor is busy 2 thirds of the time. Durring the same time period 3X, however, the HardFrame is busy only 1 third of the time. So where's this mythical free time advantage the processor is supposed to have with the GVP? > >> Sorry, this is one EE type that >> just won't believe it. The Amiga is a DMA machine, that is part of >> what gives it it's amazing speed for graphics and sound. > >Obviously some EE types are better than others. Oh that's OK, don't put yourself down. You'll do better next time. >Valentin Rich Champeaux (rachamp@mbunix.mitre.org)