garyo@masscomp.UUCP (11/22/86)
In article <2077@well.UUCP> perry@well.UUCP (Perry S. Kivolowitz) writes: > >[Brand X is a DMA controller, Brand Y is a slower Serial/Parallel controller]: >...the throughput through the AmigaDOS file system is low enough >that neither controller will run at full speed (ie brand X will never get >to really take advantage of the 300KB/sec since disk i/o time is dominated >by seeeeeeeeeeeeeeeeking). > >Those wanting to design THE high performance disk controller for the amiga >will have to look elsewhere for their performance boosts. We (ASDG) are. > >Perry > Most of this is true. Normally, disk rate shouldn't be much improved by using DMA, since most of the time is spent seeking. However, with a non-DMA controller the overhead during the actual transfer is MUCH higher, since the device must do CPU interrupts per byte transferred. Thus not only is the transfer slowed by using the CPU, it's doubly slowed because other computation cannot proceed while all these interrupts are happening. This will be much worse for image data, which presumably is stored semi- contiguously on the disk. In fact, for a non-dma SCSI controller reading an optical disk, megabytes of image data could be read in without a single disk seek. In this case a DMA device would be a GREAT DEAL faster, for the reasons mentioned above. Give me a DMA SCSI controller any day. It has all the advantages: standard interface, fast, cheap, and flexible. What more could one want? - Gary Oberbrunner Usenet: ...{harvard,allegra,ihnp4}!masscomp!garyo Snail: Gary Oberbrunner MASSCOMP One Technology Park Westford, MA 01886 (617) 692-6200
perry@well.UUCP (Perry S. Kivolowitz) (11/24/86)
The referenced article (saying that non-dma disk controllers will have some detriments over dma driven cousins) is absolutely correct. My intent was to give credence to Bob Page's claim that dma driven hard disk controllers aren't the be-all-end-all we hoped they would be...yet. Perry
perry@well.UUCP (Perry S. Kivolowitz) (11/24/86)
In article <1242@masscomp.UUCP>, garyo@masscomp.UUCP (Gary Oberbrunner) writes: > Most of this is true. Normally, disk rate shouldn't be much improved > by using DMA, since most of the time is spent seeking. However, with a > non-DMA controller the overhead during the actual transfer is MUCH higher, > since the device must do CPU interrupts per byte transferred. Thus not > only is the transfer slowed by using the CPU, it's doubly slowed > because other computation cannot proceed while all these interrupts are > happening. But the transfers don't HAVE TO NECESSITATE (sp?) interrupts. The processor in a tight loop will run competitively to the overhead of handling interrupts. If you were to do a non dma driven disk controller, that is.
stever@videovax.Tek.COM (Steven E. Rice, P.E.) (11/26/86)
In article <2111@well.UUCP>, Perry S. Kivolowitz (perry@well.UUCP) writes: > In article <1242@masscomp.UUCP>, garyo@masscomp.UUCP (Gary Oberbrunner) > writes: >> Most of this is true. Normally, disk rate shouldn't be much improved >> by using DMA, since most of the time is spent seeking. However, with a >> non-DMA controller the overhead during the actual transfer is MUCH higher, >> since the device must do CPU interrupts per byte transferred. Thus not >> only is the transfer slowed by using the CPU, it's doubly slowed >> because other computation cannot proceed while all these interrupts are >> happening. > > But the transfers don't HAVE TO NECESSITATE (sp?) interrupts. The > processor in a tight loop will run competitively to the overhead of > handling interrupts. If you were to do a non dma driven disk controller, > that is. The problem is, it eats the entire CPU! The overwhelming advantage of DMA is that it frees the processor to do other things. In a multitasking system (like the Amiga) the CPU can execute some other task while the first one is blocked waiting for I/O. Or you can run asynchronous I/O, as Matt does in his asynclib. Either way, the DMA buys a big gain in throughput! Steve Rice ---------------------------------------------------------------------------- {decvax | hplabs | ihnp4 | uw-beaver}!tektronix!videovax!stever