Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!apple!voder!dtg.nsc.com!waggoner From: waggoner@dtg.nsc.com (Mark Waggoner) Newsgroups: comp.sys.amiga.tech Subject: Re: Questions about Harddisks Message-ID: <102@dtg.nsc.com> Date: 1 Dec 89 20:12:45 GMT References: <8911300328.AA02859@jade.berkeley.edu> <18870@watdragon.waterloo.edu> Reply-To: waggoner@dtg.UUCP (Mark Waggoner) Organization: National Semiconductor, Santa Clara Lines: 56 In article <18870@watdragon.waterloo.edu> ccplumb@rose.waterloo.edu (Colin Plumb) writes: > >Non-DMA drives are limited by the size of their buffers. You can't make >a transfer larger then one buffer without running into the buffer-overflow >problem that the 2090 has problems with. It can be solved, by adding >hardware, but simplicity is the reason for avoiding DMA, so it's >unlikely to happen. So are DMA disk devices. It's just that the buffer is in the disk drive instead of on the controller board. You can make transfers larger than the buffer size if you break them up into blocks, they way a DMA controller essentially does. > >DMA devices can transfer essentially unlimited amounts of data in one >burst, because their buffer is main memory. Perhaps someone uses a >16-bit DMA chip which has 64K limits, but that's still lots bigger >than the buffer a non-DMA device is likely to have. A DMA device's REAL buffer is the buffer in the SCSI drive. The reason the SCSI drive can "slow down" is that it isn't feeding you the data directly from the disk. If you talk about an ST-506 type interface, for instance, there is no way a DMA controller can solve the overflow problem unless it contains an on board buffer for at least a full sector. This means you have to have either a very large FIFO or a double transfer: from the disk interface to a buffer memory on the disk controller board and then from the buffer memory to main memory. The second transfer could be done by either DMA or by the Amiga CPU. Letting the CPU do it is cheaper, but slower. > >... > >Now, I don't have DiskPerf numbers, but aside from that, is there any >remaining confusion? There was a Stupid Mistake in the 2090, which >causes it to be abysmally slow in certain well-understood cases. >No other DMA controllers make this mistake. Because non-DMA >controllers do a stop-and-wait operation, filling a bucket and then >pouring it somewhere, the problem doesn't tend to arise. a DMA >device is like a hose, and putting more water in one end than >you take out at the other is a problem requiring a bit more care. >But it's a lot faster than using a bucket. The DMA controllers you speak of also have a bucket, but it is in the disk drive. The non-DMA controllers could become DMA controllers by the addition of a DMA machine to copy from the controller buffer to the system memory. Cost and design complexity are the difficulties. >-- > -Colin -- ,------------------------------------------------------------------. | Mark Waggoner (408) 721-6306 waggoner@dtg.nsc.com | `------------------------------------------------------------------'