Return to BSD News archive
Path: sserve!manuel.anu.edu.au!munnari.oz.au!uunet!charon.amdahl.com!pacbell.com!sgiblab!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!agate!doc.ic.ac.uk!uknet!pavo.csi.cam.ac.uk!pipex!demon!grendel.demon.co.uk!jes From: jes@grendel.demon.co.uk (Jim Segrave) Newsgroups: comp.unix.bsd Subject: Re: DMA disk controllers Message-ID: <720149795snx@grendel.demon.co.uk> Date: 26 Oct 92 18:36:35 GMT References: <1992Oct26.062909@eklektix.com> Sender: usenet@gate.demon.co.uk Organization: None Lines: 54 ReplyTo: jes@grendel.demon.co.uk X-Mailer: cppnews $Revision: 1.19 $ In article <1992Oct26.062909@eklektix.com> rcd@raven.eklektix.com (Dick Dunn) writes: > 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. ISA machines do both memory and I/O down the same bus. > 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!) No, when a DMA controller is in burst mode (which would be the mode used for disc and network controllers where the data to be moved resides in or is going to a memory buffer on the controller), the bus is completely seized by the DMA controller for the duration of the transfer. There are no CPU cyles left. > > 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. Generally DMA is not initaited until all the data is readu (for peripheral to memory transfers) or until there is sufficient on-controller buffer space (for memory to peripheral transfers). Thus any break in data to or from the peripheral represents a dead controller card. > And, as someone else already mentioned, you may be able to reduce interrupt > overhead using DMA. They are partly right - tranferring blocks greater than 512 bytes improves DMA performance. If the DMA controller is the motherboard controller or is not a sophisticated controller which can fetch commands (eg. a channel controller), then most transfers will be in virtual memory page sizes and the reduction in interrupts will be by page size/sector size - about an 8 to 1 reduction. This will produce a slight performance edge, but nothing very significant. > 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) > > -- Jim Segrave (Segrave Software Services) jes@grendel.demon.co.uk