Return to BSD News archive
Newsgroups: comp.unix.bsd Path: sserve!manuel.anu.edu.au!munnari.oz.au!spool.mu.edu!caen!hellgate.utah.edu!csn!raven!rcd From: rcd@raven.eklektix.com (Dick Dunn) Subject: Re: DMA disk controllers Message-ID: <1992Oct26.062909@eklektix.com> Organization: eklektix - Boulder, Colorado References: <1732@optigfx.optigfx.com> <1992Oct25.045047.29452@ntuix.ntu.ac.sg> Date: Mon, 26 Oct 1992 06:29:09 GMT Lines: 32 eoahmad@ntuix.ntu.ac.sg (Othman Ahmad) writes: >Mike Murphy (mrm@optigfx.com) wrote: >:...DMA ought to be fast enough, and it would offload the CPU if the DMA setup >: didn't take more CPU than the DMA saved. > >You cannot offload the CPU becaue the DMA take full control of the bus. There are two buses to consider: I/O and memory. DMA can't take over the memory bus, because it can only feed it via the I/O bus, which is much slower. Therefore, the CPU can sit and crank in memory while data dribbles in/out. I'm not convinced the 8237 can drive the I/O bus to capacity, either. I believe that even when it's running flat-out, and even after taking bus arbitration into account, there are still I/O bus cycles available. Any- one have solid information one way or the other? (I'm not about to dive into the AT logics and the 8237 reference mud just to answer this one!) Beyond that, if you get a break in the data to/from a peripheral (due to some physical boundary), you get a break in the DMA controller bus activity. And, as someone else already mentioned, you may be able to reduce interrupt overhead using DMA. The DMA controller is still pretty bad, and the rock-and-a-hard-place choice of slow/clumsy DMA, versus hand-transfer by the CPU with interrupt per sector, is background for the plethora of disk-interface choices on the PC. -- Dick Dunn rcd@raven.eklektix.com -or- raven!rcd Boulder, Colorado Read my .sig: No rude Texans! (!Bush && !Perot)