Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!sgi!shinobu!odin!daahoud!hwajin From: hwajin@daahoud.wpd.sgi.com (Hwa-jin Bae) Newsgroups: comp.protocols.tcp-ip Subject: Re: Board Level Ethernet/TCP/IP Products Message-ID: Date: 11 Jun 91 20:27:31 GMT References: <1991Jun10.201046.16912@sctc.com> Sender: news@odin.corp.sgi.com (Net News) Reply-To: hwajin@pei.com Organization: Protocol Engines Inc., Mountain View, CA Lines: 60 In-Reply-To: smith@sctc.com's message of 10 Jun 91 20: 10:46 GMT >>>>> On 10 Jun 91 20:10:46 GMT, smith@sctc.com (Rick Smith) said: Rick> SBE -- VxWorks which includes 4.3 tahoe TCP/IP runs on SbeVlane as well. The performance for this configuration is really good (price/performance wise), definitely worth checking out. Applications written for VxWorks can run directly on-board using the socket library. Rick> Motorola -- Rick> Different people at Motorola told us different stories. Evidently they Rick> used to sell the CMC product with a Motorola label on it. Motorola used to re-sell ENP-10 as MVME330. They started pushing MVME374 a few years ago. Rick> Now they are said to have some relationship with Interphase. Rick> They advertise the MVME374, a board that claims in its tech Rick> sheets to support TCP/IP. Maybe so, but the current version Rick> isn't completely resident on the board. We called off our Rick> search for a Motorola product since we couldn't find a technical Rick> manual describing an on-board solution. MVME374 has on-board 68020 and Motorola has pSOS based realtime OS that has TCP/IP support for it. Motorola Unix driver (STREAMS) for this board talks to the CE/BPP (common environment/buffered pipe protocol) code that gets downloaded to the board. This is similar to other vendor's approaches. In general, this kind of solution doesn't yield a very good performance. The overhead of talking to the software running ethernet board from the host + data copying over VME costs quite a bit, and prohibits any possible driver level optimizations. Perhaps that's why so many smart people seem to be attracted to simple on-board shared memory style network interfaces. Rick> Single Board Alternatives -- Rick> Several respondents recommended a sort of "component assembly" approach, Rick> like getting a board-resident monitor (VxWorks, pSOS, OS-9, etc) and Rick> running with a TCP/IP on top of one of them. A couple of people had Rick> personal experience with such things and claimed that the right set Rick> of components would outperform any of the prepackaged TCP/IP boards. Rick> However, you'd then typically have to do your own implementation of Rick> an interprocessor communications protocol for handling the socket Rick> interactions. If your application can be ported to the board-resident monitor/OS that supports TCP/IP and controls the ethernet chip directly, the performance of your end product will be much better. Portability is pretty high in case of VxWorks, but I haven't used pSOS or OS-9 solutions. If your application cannot be ported, communication between the board software and host software can be implemented as you suggested, and the communication overhead over the bus will be typically lower than the overhead required for communication between the driver and the board. *hwajin -- protocol engines inc.