Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!caen!spool.mu.edu!cs.umn.edu!sctc.com!smith
From: smith@sctc.com (Rick Smith)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Board Level Ethernet/TCP/IP Products
Message-ID: <1991Jun10.201046.16912@sctc.com>
Date: 10 Jun 91 20:10:46 GMT
Article-I.D.: sctc.1991Jun10.201046.16912
Organization: SCTC
Lines: 91

Several weeks back I posted an inquiry about boards that integrated
an Ethernet interface with a TCP/IP implementation. In particular I
asked about peoples' experiences with products from Motorola, CMC,
and SBE, and asked for pointers to other implementations.

When the smoke cleared, there were only two vendors, CMC and SBE, that
really offered what we wanted. From the responses it's clear that there
is lots of good hardware out there for what we want; few people griped
about board performance. The TCP/IP was a different issue entirely.

I spoke to several vendors and tried to collect technical documentation
and recommendations from users for their TCP/IP products. Here are the
highlights:

SBE --

Not very well known in the Internet community. They've shipped hundreds
of boards running TCP/IP, and they seem to be used primarily on private
networks. Their product is based on the Spyder implementation, which
they've modified. I talked to two OEMs, both very enthusiastic about
the product and with the quality of support they received from SBE.
None of the users seem to have much experience running connections
on the Internet or even through gateways, though.

I reviewed the technical documentation. The board's interface is very
streams-like: they pass streams data structures between the host and
the TCP board. SBE provides hooks into every level of their protocol
stack to allow for such things as specifying gateways or even
for implementing non-standard protocol stacks. To do so you open a
channel/socket with the appropriate "device" identifier. The OEMs who
worked with the SBE board said that their driver interface was pretty
easy to work with, though one of them only needed to recompile SBE's
Unix compatible driver.

CMC --

It was obvious from my mail that CMC is well known. I also got responses
from CMC employees on the Net. The general form of non-employee messages
was "We tried them two years ago, their protocol software was buggy, and
they didn't fix things very fast." I passed this perception along to
the guys at CMC. They said their software has vastly improved in the
past couple of years, and their employees evidently use it routinely
for interacting with the Internet. We also heard from their sales rep
that they're trying to improve their handling of customer problems by
setting up deadlines by which problems are supposed to be addressed
and resolved.

I reviewed CMC's technical documentation, too. The board's interface
takes essentially the opposite approach to SBE: their interface uses
fixed size ring buffers similar to those used by the Ethernet LANCE
chip. They use the ring buffers for communication between the two
processors, and use a bunch of auxiliary queues and channel structures
with flow control ring buffers that are maintained separately by each
processor. Like SBE, CMC provides access to different layers of the protocol
stack, though they limit such usage to specific channels/sockets in their
interface. One respondent claimed that they had trouble building a driver
to do streams with this interface, though CMC now offers such a driver.

Interphase --

We communicated at length with Interphase. They provided several thick
manuals about their TCP/IP, none of which applied to what we were
looking for. They claim that they have a product with a board-resident
TCP/IP implementation, but ultimately they could not provide us with a
document describing the interface. They said it was "in preparation."

Motorola --

Different people at Motorola told us different stories. Evidently they
used to sell the CMC product with a Motorola label on it. Now they
are said to have some relationship with Interphase. They advertise
the MVME374, a board that claims in its tech sheets to support TCP/IP.
Maybe so, but the current version isn't completely resident on the board.
We called off our search for a Motorola product since we couldn't find
a technical manual describing an on-board solution.

Single Board Alternatives --

Several respondents recommended a sort of "component assembly" approach,
like getting a board-resident monitor (VxWorks, pSOS, OS-9, etc) and
running with a TCP/IP on top of one of them. A couple of people had
personal experience with such things and claimed that the right set
of components would outperform any of the prepackaged TCP/IP boards.
However, you'd then typically have to do your own implementation of
an interprocessor communications protocol for handling the socket
interactions.

Many thanks to those in Net.Land who responded to my request for info.

Rick.
smith@sctc.com    Arden Hills, Minnesota