Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!dg!rec
From: rec@dg.dg.com (Robert Cousins)
Newsgroups: comp.arch
Subject: Re: DMA on RISC-based systems
Message-ID: <183@dg.dg.com>
Date: 1 Jun 89 14:34:51 GMT
References: <46500067@uxe.cso.uiuc.edu> <181@dg.dg.com> <1989May31.163057.543@utzoo.uucp>
Reply-To: uunet!dg!rec (Robert Cousins)
Organization: Data General, Westboro, MA.
Lines: 83

In article <1989May31.163057.543@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>In article <181@dg.dg.com> rec@dg.UUCP (Robert Cousins) writes:
>>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...
>>
>>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?
>
>The three obvious ones are:
>
>1. A serious assessment of what performance in each of these areas is
>	necessary to meet the machine's objectives, and what fraction of
>	the CPU would be necessary to do so with "dumb" hardware.  It is
>	not likely to be cost-effective to add hardware to save 1% of
>	the CPU.  10% might be a different story.  50% definitely is.

Your point is well taken.  However, it is clear from reading about some
products on the market that the sum total of the penalty considered in the
calculations is the number of bus cycles required to do the copy.  In fact,
many of these copies will take place with interrupts disabled or at some
spl() level which restricts some interrupts.  Secondly, some copies will
require additional interrupt service which will require additional overhead
for context switches.  Thirdly, some of the management will require task
activation which can take a long time under traditional Unix.  When these
are considered, the cost function should be computed based upon 

	       Cost of smarter peripherals
   cost/MIPS = -----------------------------------
               MIPS freed up by better peripherals

If this number comes out lower than the price of your CPU, the odds are
that you would be better off using the smarter peripherals.  

>2. A serious assessment of the overheads of adding smart hardware, like
>	the extra memory bandwidth it eats and the software hassles that
>	all too often are necessary.

As a rule, smarter peripherals require less memory bandwidth than dumb ones.
For example, copying data from a dedicated disk buffer to main memory using
software entails not only the instruction bandwidth but also a read and
a write for each word or two bus cycles per word.  DMA on the other hand
should be able to perform the same operation with a single cycle per word.

As for the software hassels, I've written drivers for both smart and dumb
devices.  It is true that some classes of smart devices can be more difficult
to program than their dumb counterparts.  However, in my experience, this is
not the rule but is the exception.  In fact, if you graph the software
hassel factor (if one can truely be quantified), my experience shows that
as hardware goes from brain dead to genius the curve is "U" shaped.  Managing
very stupid hardware can be as difficult as the most sophisticated.  

>3. A serious assessment of whether the added performance can be had in a
>	more versatile and cost-effective way by just souping up the CPU.

Agreed.  As was pointed out in the equation above, the real issue is 
getting the end user the most bang for the buck.

>Simply saying "we've got to have smart i/o, and smart graphics, and smart
>networks" without justifying this with numbers is marketingspeak, not
>a sound technical argument.  As RISC processors have shown us, taking things
>*out* of the hardware can result in better systems.
>-- 
>You *can* understand sendmail, |     Henry Spencer at U of Toronto Zoology
>but it's not worth it. -Collyer| uunet!attcan!utzoo!henry henry@zoo.toronto.edu

I disagree.  There are certain requirements for a product to be considered
useful.  It is possible to design 500 Mhz Z80s.  There are also a number
of users who would find this an attractive product, though many people
would mutter that this is waste of technology.  There are certain things
which users have a right to demand:  quality software, state of the
art hardware, reasonable performance for the price, dependable support.
I would suggest that provision of non-braindead peripherals is in this
class almost (but not quite) by default.

Robert Cousins
Dept. Mgr, Workstation Dev't.
Data General Corp.

Speaking for myself alone.