tjhayko@THUNDER.LAKEHEADU.CA (10/12/90)
I'm looking at various hard drive controller and I've looked at some that are DMA and some that are no. Could someone clue me in on what the advantages and disadvantages of using DMA and not us- ing DMA are? The controller I'm considering strongly is a Supra WordSync. I'm also curious to know if you can build a switch that switched the jumpers on controllers that require switching jumpers to determine if they autoboot or not. ************************************************************* * Tom Hayko * only the Amiga /// * * tjhayko@thunder.lakeheadu.ca * (Commodore is starting/// * * * to know that) \\\/// * * * and it's about time\XX/ * ************************************************************* QUIT
daveh@cbmvax.commodore.com (Dave Haynie) (10/17/90)
In article <9010120234.AA16614@thunder.LakeheadU.Ca> tjhayko@THUNDER.LAKEHEADU.CA writes: >I'm looking at various hard drive controller and I've looked at >some that are DMA and some that are no. Could someone clue me in >on what the advantages and disadvantages of using DMA and not us- >ing DMA are? The controller I'm considering strongly is a Supra >WordSync. I'm also curious to know if you can build a switch >that switched the jumpers on controllers that require switching >jumpers to determine if they autoboot or not. Here's a quick attempt to formalize this a little. This pretty much assumes that the fastest disk speed possible is still less than the transfer speed of the controller, which is the case with asynchronous SCSI -- the SCSI bus itself isn't faster than 1/2 the Amiga bus speed, most disks can't go even that fast, and no disk goes that fast across track boundaries. Understanding disk controllers is understanding the timing involved. You have three physical times to worry about: tDISK The fastest you can get data from the disk tXFER The transfer time between controller and system tINTR The interrupt and related overhead. And two logical times to worry about: tEFFE The drive's effective transfer rate tEVIL The amount of CPU time you waste achieving tEFFE. The total real time spent is tEFFE, the time unavailable to the CPU for other things is tXFER + tINTR. [1] DMA In a DMA setup, you have some kind of DMA controller which replaces the CPU in the system to effect the transfer. Since the data flows only from the controller to memory, the transfer is quite fast. tXFER = Theoretical maximum of the bus tINTR = Interrupt + bus arbiter time tEVIL = Minimal; as tXFER -> tXFER(max), tEVIL -> 0 tEFFE = tDISK + FIFO_Lag + tINTR Basically, what this says is that DMA runs the full bus speed, but since most disks don't, it lets the CPU use the bus when its waiting for some DMA activity. The disk transfer actually finishes a little bit before the DMA is finished in most systems, the DMA controller buffers disk data with a FIFO or similar memory. When the last DMA finishes, the controller signals the CPU via an interrupt, and that wakes up the device driver program and you see the transfer finish. [2] Buffered non-DMA In a fully buffered non-DMA setup, a controller gets the data for a whole block or so, then interrupts the CPU to effect a copying transfer. Data must flow from the controller memory to the CPU, and then from the CPU into system memory. tXFER = (Theoretical maximum of the bus)/2 - epsilon tINTR = Interrupt time tEVIL = Small; not as efficient as DMA, but no system time is wasted tEFFE = tDISK * Buffer_Efficiency + tINTR Here, the transfer runs at the full bus speed, but twice as many transfers are needed for each word. When the buffer is full, the controller interrupts the CPU to come and do the transfer. The epsilon there is a small amount of code overhead for the CPU transfer loop; this is noticable for a 68000, but basically vanishes for a 68030 thanks to cache. There is CPU time wasted as compared to a DMA transfer, but since transfer time tends to be much less than disk time, especially during seeks, this is a relatively small waste. The effect of the buffering on delivered speed can be a lag as long as tDISK (Buffer_Efficiency = 2), though modifications to this scheme may get the CPU transfer going before the disk transfer is complete, or while the disk is seeking. As the buffering scheme gets better, the Buffer_Efficiency can approach 1, and the disk speed appears to be about the same as that of the DMA disk. The difference is tEVIL; the larger tEVIL is, the less CPU time you get during the tEFFE of your disk transfer. This isn't much of a concern in single tasking systems, but the day of single tasking systems has long been over. [3] Parasitic non-DMA (polled I/O) This third type of non-DMA uses the CPU to read the SCSI controller much like a chunk of slow memory. Macintosh computers prior to the Mac IIfx use this method. Most controllers of this type for Amiga use a modification, whereby they funnel the 8 bit SCSI data into 16 bits for transfer. Without the 8 to 16 bit funneling, the SCSI bus may end up waiting for the Amiga, which will increase my tEVIL timing. In this setup, you have: tXFER = tDISK tINTR = 0 tEVIL = Maximum tEFFE = tDISK Basically, the controller plus CPU sit and wait for the full SCSI transfer to complete. The individual word transfers are as fast as in buffered non-DMA, but the CPU will always wind up waiting for a word, so the actual transfer time for a block is the same as the apparent transfer time, tDISK. However, the CPU gets absolutely no time during the tDISK period, so tEVIL is maximized. The transfer completes as soon as the SCSI chip finishes, so there's no additional delay due to interrupts. The removal of the interrupt lag can make the effective disk speed greater than that of the other two controllers, but if there's any CPU work to do during a transfer, the SYSTEM performance goes way down. [4] But is it really that evil... OK, so you say, "hey, great with the theory, but I can SEE a disk speedup in type [3] controllers. How much CPU time do I actually lose"? That's a good question, and of course dependent on disk and system speeds. So let's look at the best case. Start with a good asynchronous SCSI drive, like a Quantum. On an A2000 with A2091, for example, the SCSI drive can go at full asynchronous SCSI speed, and since tXFER is at least twice tDISK, you find that the CPU gets almost 50% of the CPU time during a full speed disk transfer; much more if drive seeking is involved (tDISK is greater than tDISK,min). On the A3000, you have about 96.5% of the CPU time available during a full speed asynchronous SCSI transfer. With a fully parasitic controller controller, you have no CPU time at all during transfers, even while the disk is seeking. -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Standing on the shoulders of giants leaves me cold -REM