[comp.dcom.lans] Advice: CMC vs SBE

endrizzi@sctc.com (Michael Endrizzi ) (06/06/91)

We are looking for an intelligent controller
, VME based with TCP/IP on-board processing.
We have narrowed the contenders to CMC and SBE.
If anyone has any comments to make on the vendors
we would appreciate hearing from you.


			Dreez

=================================================================
=================================================================
               Michael J. Endrizzi
	            SCTC
	   1210 W. County Road E #100
	      Arden Hills, Mn. 55112
	        endrizzi@sctc.com
	          (612) 482-7425
	
*Disclaimer: The opinions expressed above are not of my employer
             but of the American people.
=================================================================
=================================================================

hwajin@daahoud.wpd.sgi.com (Hwa-jin Bae) (06/07/91)

>>>>> On 5 Jun 91 20:39:07 GMT, endrizzi@sctc.com (Michael Endrizzi ) said:


Michael> We are looking for an intelligent controller
Michael> , VME based with TCP/IP on-board processing.
Michael> We have narrowed the contenders to CMC and SBE.
Michael> If anyone has any comments to make on the vendors
Michael> we would appreciate hearing from you.

i've previously worked on berkeley style drivers for both CMC enp-10
and sbeVlane for VxWorks a realtime OS by Wind River Systems.  note
that enp-10 is by now quite old; CMC has newer versions of this board.
enp-10 used to be shipped with CMC TCP/IP implementation that runs
on-board utilizing the 68010(?) on-board, and most OS products use
this interface.  there are some well-known performance problems with
this kind of on-board TCP/IP implementations, and since VxWorks
already has TCP/IP, the VxWorks doesn't use CMC TCP/IP product.
instead it talks to the interface to the link-level ROM provided by
CMC, with a bsd style interface driver.  this interface resembles
LANCE interface, and provides higher level interface to the on-board
LANCE to the driver.  the ROM code does all the LANCE buffer
management, etc.  the data copying over VME bus between the host
memory and the ethernet buffer memory is still quite costly in this
case, which is not really necessary if you have a LANCE right on the
CPU board on which your OS runs.  if your board is designed "properly"
and allow shared memory access to buffer memory from both CPU and
LANCE, there are some interesting optimizations you can perform with
bsd TCP/IP networking code.  in fact, many workstation vendors do this
already: Sun, Silicon Graphics, etc.  the idea is to use the buffer
LANCE uses as bsd "mbuf" clusters, avoiding unnecessary copying of
data between interface and protocol.  sbeVlane can be programmed this
way, if your OS runs on sbeVlane board itself (like VxWorks which runs
directly on sbeVlane -- a 68020 CPU board with LANCE; it is marketed
as an ethernet board but it can run a real OS just fine).  other VME
boards such as mvme-147 (motorola) can also do the same.  the end
result is that VxWorks is capable of achieving twice the throughput
rate on sbeVlane board than on enp-10 using TCP/IP.  having said all
that, even without all these things i've said above, i still prefer
sbe board because of their clean and efficient design.  a very nice
board for the money, speaking just as a happy user of course.


*hwajin








--
	Hwajin Bae	hwajin@pei.com		Protocol Engines, Inc.
--
	Hwajin Bae	hwajin@pei.com		Protocol Engines, Inc.