*BSD News Article 7080


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