*nix performance

pri=-10 Stuart Lynne sl at van-bc.UUCP
Mon Oct 3 19:07:43 AEST 1988


In article <736 at starfish.Convergent.COM> cdold at starfish.Convergent.COM (Clarence Dold) writes:
>From article <9902 at ico.ISC.COM>, by rcd at ico.ISC.COM (Dick Dunn):
>>> | One of my main interests is whether a fast (25MHz with cache etc) 386 with
>>> | some users attached to it can compare itself with a VAX/750 or other minis.
>> 
>> Also, think very carefully about what sort of disk(s) you're going to put
>This also harks back to the MAC - vs - PC discussion of a particular DMA
>not being as fast as CPU data transfer.  A DMA activity does take some setup
>time.  If the system (single-tasking) is going to be idle until the disk
>transfer is complete, -and- the CPU is fast enough to handle disk data on the
>fly, -then- CPU will be faster than DMA.
>As soon as you talk multi-user, that argument goes away, because the CPU could
>be working on a different process, while the DMA occurs offline.
>Multi-user performance is distinctly different from single user.
>Do buy the fastest disk you can.  Don't forget that with the proper controller,
>two slower disks might actually be faster in a multi-user setup.

Not neccesarily. If the DMA channel takes over the bus for the duration of
the transfer, or if each word transferred takes a a larger number of cycles
than the CPU would and the system can't interleave processor cycles; then
CPU is still a win.

In both of those situations the CPU can't perform as much work during the
DMA operation so it *may* be more efficent to allow the CPU to do it.

Well designed DMA systems get around this by allowing the DMA to operate in
an interleaved fashion with the CPU. In these systems you can sometimes beat
DMA with CPU but at the expense of burning CPU cycles and you may wish to
use DMA simply to allow more processing at the expense of increased data
transfer time.


-- 
Stuart.Lynne at wimsey.bc.ca {ubc-cs,uunet}!van-bc!sl     Vancouver,BC,604-937-7532



More information about the Comp.unix.questions mailing list