Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!uwvax!oddjob!hao!ames!sdcsvax!ucsdhub!hp-sdd!hplabs!sdcrdcf!CAM.UNISYS.COM!mrc
From: mrc@CAM.UNISYS.COM.UUCP
Newsgroups: comp.dcom.lans,comp.sys.ibm.pc
Subject: Re: PC LAN Comparison
Message-ID: <390@sdcjove.CAM.UNISYS.COM>
Date: Thu, 19-Nov-87 09:40:10 EST
Article-I.D.: sdcjove.390
Posted: Thu Nov 19 09:40:10 1987
Date-Received: Sat, 21-Nov-87 15:49:15 EST
References: <2070@killer.UUCP> <1020@kodak.UUCP> <155@tic.UUCP>
Reply-To: mrc@CAM.UNISYS.COM (Ken Leonard --> ken@oahu.mcl.unisys.com@sdcjove.cam.unisys.com)
Organization: Unisys, McLean (Va.) Research Center
Lines: 71
Keywords: IBM PC, Novell, hardware
Xref: utgpu comp.dcom.lans:845 comp.sys.ibm.pc:8815

In article <155@tic.UUCP> ruiu@tic.UUCP (Dragos Ruiu) writes:
>...long referral trail deleted...
>...
>   However, I had great difficulty believing their hardware section, which
>repeatedly says that DMA interface boards are slower than others. Unless there 
>is something I don't know, DMA is much faster than interrupt driven hardware.
>...

First, which of the following  are we asking?...
   "Is MY workstation trans-net access speed lower with a DMA netcard?"
 or
   "Is the net aggregate thruput lower with DMA netcards on the workstations?"
 or
   "...?"

Usually, I think, most instances considering a net of more than just a couple
workstations tend to concentrate on the second question.  Or, when they do
address the first question, they tend to look at it in terms of transfer rate
during (or elapsed time for) rather large chunks of data  (i.e. umpty-KB).
   Well, humm, having been embogged (emboggled?) in this kind of issue just
   a few times ago...
      The type of netcard (DMA vs. interrupt-and-read) has nothing to do with
      aggregate net thruput if the product line is anywhere close to good.
      This is not to say that there is no difference between product lines,
      it is just saying that it takes a pretty damn bad design for ONLY
      netcard-to-CPU transfer mode to have a notable differential effect on
      the net as a whole.

      The type of netcard (DMA vs. i-&-r) need not have much, if any, effect
      on the burst/block rate of the workstation IF the upper layers (NETBIOS-
      equivalent, and above) are a clean implementation of the "right"
      protocol for the job.  Trap-and-overlap, or whatever it may be called,
      can keep the workstation "ready" with respect to the net, with either
      type of netcard.  It's just a matter of HOW those mid-layers are
      implemented.

   Now, again, let's get back to the first question, with the emphasis on
   the term MY...
      The Novell folk are smart enough to know, and they do know, that what
      sells a network, or keeps it sold, is what it does for those poor peons
      whom we gurus tend to neglect (to put it kindly).  

      When I/me/myself is the user;  when I am doing the explicitly or
      implicitly transaction-ish stuff that really occupies most of the
      on-terminal time of most folk like me--then what counts is "How fast
      does MY SCREEN SHOW the next thing I want to see?"

      Here is where, to some folks' surprise, an interrupt-and-read type
      netcard can substantially beat a DMA type netcard.  This is because
      so much of the transaction-ish applications are treating the data from
      (and often, to) the net as a stream of individually relevant characters
      (at least, as individually partly processable before the whole block
      has arrived and/or as maybe actually going to arrive in multiple blocks,
      anyhow).  This means that the user ends up seeing something (often,
      actually, something "useful") quite a bit sooner.
 
      Now, for all of those self-appointed gurus who have just written-off
      this whole missive as too much like social science and not sufficiently
      arcane or academic-ish, all I can say is that I have been bitten on
      the backside more than once in the process of learning this.  And,
      if the data were not "company black" to a couple of clients I have had,
      I could show you a couple of very interesting simulations AND TRACES OF
      REAL SYSTEMS (shame on me for mentioning the real world?) which proved
      the thesis above--much to the chagrin of those of us who were trying
      to disprove it!

"Whosoever pisseth in the beer is not entitled to complain of strange flavor."
Froggy

Best regardz,
Ken Leonard