Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!sgi!shinobu!odin!daahoud!hwajin From: hwajin@daahoud.wpd.sgi.com (Hwa-jin Bae) Newsgroups: comp.dcom.lans Subject: Re: Advice: CMC vs SBE Message-ID: Date: 6 Jun 91 20:15:46 GMT References: <1991Jun5.203907.15946@sctc.com> Sender: news@odin.corp.sgi.com (Net News) Reply-To: hwajin@pei.com Distribution: comp.dcom.lans Organization: Protocol Engines Inc., Mountain View, CA Lines: 57 In-Reply-To: endrizzi@sctc.com's message of 5 Jun 91 20: 39:07 GMT >>>>> 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.