Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!bloom-beacon!gatech!ncar!ico!vail!rcd
From: rcd@ico.ISC.COM (Dick Dunn)
Newsgroups: comp.arch
Subject: Re: DMA on RISC-based systems (SotA criteria)
Summary: seems old-fashioned (goal substitution?)
Message-ID: <15809@vail.ICO.ISC.COM>
Date: 1 Jun 89 20:23:43 GMT
References: <46500067@uxe.cso.uiuc.edu> <181@dg.dg.com>
Organization: Interactive Systems Corp, Boulder, CO
Lines: 47

> There are some basic requirements, IMHO, which must be met to be considered
> state-of-the art:  I/O which does not involve the CPU for moving every
> byte, graphics which does not require total CPU dedication for normal
> operations such as line drawing or bit blitting, dedicated LAN controllers
> to handle the low levels of the LAN protocol and a number of similar 
> minimums which most new machines have...

Why are these requirements?  At some point in the past, for some set of
architectural constraints, smart DMA was an improvement over having the CPU
move the data.  *However*, remember that smart DMA was not the goal!  The
goal was to speed up I/O, and you can only substitute the goal of smart DMA
if the numbers work right--that is, if you get enough performance gain to
justify the cost of the DMA controller, dual-porting the memory (or putting
it on the bus and making the bus fast enough), etc.

Similar arguments go for the other two putative requirements.  For example,
if it's going to make sense to have a separate bit-blitter, you have to be
able to set it up quickly.  If the setup time is longer than the time it
would take the CPU to draw the typical line or blt the typical bits, you
haven't gained anything.  Even if the setup is fast, you have to be able to
do something useful with the CPU--which is likely to mean that you have to
be able to do a blazingly fast context switch to another process while the
drawing is going on.

Folks working on networking here have found that it tends to be easier and
faster to run "host-based" TCP than to deal with "smart" boards.

>...It is interesting, however, to
> notice the number of machines which do not meet up with even the most
> basic criteria.  

But the criteria you've given are artificial...they come not from the
direct goals (such as performance in a particular application) but from
derived goals based on certain assumptions of how to increase performance.
I suggest that the problem is *not* that these machines are deficient, but
that the assumptions are wrong.

> I make this point to begin discussion.  What are some of the minimum
> standards which should be applied to these classes of machines and which
> machines fail to meet them?

I suggest that we proceed with the discussion by looking at the machines as
black boxen for a bit--establish the standards based on WHAT you want the
machine to do, not HOW it gets it done.
-- 
Dick Dunn      UUCP: {ncar,nbires}!ico!rcd           (303)449-2870
   ...CAUTION:  I get mean when my blood-capsaicin level gets low.