Return to BSD News archive
Path: sserve!manuel.anu.edu.au!munnari.oz.au!uunet!optigfx!mrm From: mrm@optigfx.optigfx.com (Mike Murphy) Newsgroups: comp.unix.bsd Subject: Re: DMA disk controllers Message-ID: <1735@optigfx.optigfx.com> Date: 27 Oct 92 23:58:40 GMT References: <1992Oct26.062909@eklektix.com> <720149795snx@grendel.demon.co.uk> Organization: Optigraphics Corporation, San Diego Lines: 85 In article <720149795snx@grendel.demon.co.uk> jes@grendel.demon.co.uk (Jim Segrave) writes: : :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. Only in burst mode. :> :> 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. Some do. Some don't. :> 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. Probably a good argument for throttled DMA, e.g. transfer four words, give up the bus, transfer four words, give up the bus,... One could even have a card that looked for what would be defined as higher priority DMA, and didn't request until... oh, nevermind. :> :> 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. Not the way it has to be. Set up the DMA, start the controller, wait for interrupt on completion, check for DMA completion... :> 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. This really depends upon how the driver is written. :> 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. Yep. More's the pity. I never did get any response from anyone about a 16-biT MFM, IDE, or RLL interface that does DMA, so an elegant driver is a moot point. :> -- :> 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 The DMA on the ISA BUS PC is worse than 3-cycle DMA on a PDP-8. -- Mike Murphy mrm@Optigfx.COM ucsd!optigfx!mrm +1 619 625 3000 x 265 Optigraphics Corporation 9339 Carroll Park Drive San Diego, CA 92121 The opinion(s) expressed above are mine and not those of my employer.