Xref: utzoo comp.unix.xenix:3509 comp.unix.questions:9539 comp.unix.microport:1710 comp.sys.ibm.pc:19910
Path: utzoo!utgpu!water!watmath!clyde!ima!johnl
From: johnl@ima.ima.isc.com (John R. Levine)
Newsgroups: comp.unix.xenix,comp.unix.questions,comp.unix.microport,comp.sys.ibm.pc
Subject: Re: *nix performance
Message-ID: <2733@ima.ima.isc.com>
Date: 3 Oct 88 21:31:30 GMT
References: <9902@ico.ISC.COM> <736@starfish.Convergent.COM> <1901@van-bc.UUCP>
Reply-To: johnl@ima.UUCP (John R. Levine)
Distribution: na
Organization: Not much
Lines: 24

In article <1901@van-bc.UUCP> sl@van-bc.UUCP (pri=-10 Stuart Lynne) writes:
>In article <736@starfish.Convergent.COM> cdold@starfish.Convergent.COM (Clarence Dold) writes:
>>This also harks back to the MAC - vs - PC discussion of a particular DMA
>>not being as fast as CPU data transfer.  ...
>>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.
>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.

On machines with a PC AT bus DMA is rarely a win. It takes so long to get and
release the bus that it's faster to buffer a chunk of disk in the controller,
then use a processor INS or OUTS instruction to blat the data at full speed.
The IBM hard disk controller does just this. Besides, in many cases the DMA
design is so marginal that multiple DMA devices plain don't work. A controller
with a full track buffer would probably be your best bet.

Or I suppose you could get a microchannel computer; my PS/2 has no trouble
DMA-ing full disk tracks in one revolution.
-- 
John R. Levine, IECC, PO Box 349, Cambridge MA 02238-0349, +1 617 492 3869
{ bbn | think | decvax | harvard | yale }!ima!johnl, Levine@YALE.something
Rome fell, Babylon fell, Scarsdale will have its turn.  -G. B. Shaw