*BSD News Article 7172


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.