Re: DMA or not DMA...

[pubpc1@library.ucla.edu]

nathan@visi.com (Nathan Mates) wrote,
in response to my reply:
>>nathan@visi.com (Nathan Mates) wrote:
>>>>I would.  The loss of DMA is not that big of a deal.  In real world,
>>>>random read/write situations, it is not very noticeable (except when
>>>>doing sequential operations like verifying a volume).
>
>>>That's adding roughly 30% to a very much real world random access
>>>i/o operation.
>
>>Also, booting involves much sequential access (if you installed
>>the system on a clean/new partition).
>
>   There is a fair amount of sequential access, but any time you
>go load a file, then that init/etc goes and hits a resource fork,
>prefs file, etc, your sequential access pattern goes out the window.
>There's enough random disk bouncing around to make the even defragged
>disks not a linear i/o pattern on booting.
>
>   However, you've got it totally wrong as to what DMA affects. It is
>NOT sequential disk access only (that's what the RamFAST excels at,
>DMA on or not); DMA speeds up the transfer of each and every block
>read simply by telling the processor to take a nap while it shoves
>data into memory as fast as the bus allows. DMA off, the processor has
>to sit in a tight loop reading out bytes one at a time and copying
>them to the destination. Sequential block reads or random are both
>equally affected, no matter what the drive speed is-- at the basic
>level, each block must be copied from disk to RAM.

True.  The point is, however, that in random read/write, a major
part of the time is taken to position the read/write head over
the platters.  Thus, in such operations the speed gained by DMA
is only a fractional gain (since the majority of the time is still
spent on head positioning).  In sequential access, head positioning
time is mostly taken out of the equation, so the DMA speed gains
are more apparent.

-Scott G.