[comp.protocols.tcp-ip] Smart Ethernet boards

mel1@houxa.UUCP (M.HAAS) (07/03/87)

I think there are two performance factors to consider.  If one wants
to devote CPU cycles to Ethernet processing, then an off-board TCP/IP
makes sense and high network traffic rates can be achieved.  If the
CPU is already burdened by having to handle too many time-share users
or by just being too small, then an on-board TCP/IP makes sense (with
network traffic rates limited by the board/CPU combination's power).

If the on-board TCP/IP imposes more load on the CPU than an off-board
TCP/IP, then something is radically wrong with the design.  If anyone
has evidence of such a situation, please post it here so we can avoid
purchasing that board.

For small systems with 80386 and 68020 class CPUs, I would think that
an on-board TCP/IP with similar CPU and decent memory buffers would give
optimum performance.  Does anyone have figures or thoughts as to what
impedes performance?  One article here commented on the multiple
copies being made of the data being transferred.  Is that necessary
or desirable?  Couldn't the on-board TCP/IP processor just handle
the headers on the board and DMA the data to/from user's I/O space?
(i.e. no copying, just pointer shuffling)  Are there TCP/IP
implementations that do this?

   Mel Haas  ,  odyssey!mel

daveb@geac.UUCP (Dave Brown) (07/06/87)

In article <585@houxa.UUCP> mel1@houxa.UUCP (M.HAAS) writes:
>For small systems with 80386 and 68020 class CPUs, I would think that
>an on-board TCP/IP with similar CPU and decent memory buffers would give
>optimum performance.  Does anyone have figures or thoughts as to what
>impedes performance?  One article here commented on the multiple
>copies being made of the data being transferred.  Is that necessary
>or desirable?  Couldn't the on-board TCP/IP processor just handle
>the headers on the board and DMA the data to/from user's I/O space?
>
>   Mel Haas  ,  odyssey!mel

  A side point that might be of interest here: "an on-board TCP/IP with 
similar CPU and decent memory buffers would give optimum performance"
implies that the TCP/IP board could be programmed from the host. If you
have the choice of such a board, go for it.

  CP-6 (and possibly CP-V) has a mechanism for compiling parts of
major programs (like editors) to run on the front-end processors.  As
a result the front ends tended to be accesable, programmable in
something other than assembler and maintainable.
  A performance improvement was there too: the two parts of the "same"
program tended to know how to communicate with each other effectively,
using the basic comms primitives the system provided. Especially minimizing
redundant copying.

  So look for boards with big ram buffers and hooks for user
programmability/downloading: you may bless your foresight.
-- 
 David (Collier-) Brown.              |  Computer Science
 Geac Computers International Inc.,   |  loses its memory
 350 Steelcase Road,Markham, Ontario, |  (if not its mind)
 CANADA, L3R 1B3 (416) 475-0525 x3279 |  every 6 months.