smith@sctc.com (Rick Smith) (05/14/91)
I'm looking for information about Ethernet boards packaged with
a TCP/IP protocol suite. We need access both to the transport
layer facilities (TCP/IP/UDP) and to "raw" Ethernet packets
(i.e. physical addresses bypassing logical addresses).
We're using it with a VMEbus based system.
I'd also be interested to hear if anyone knows of a supplier of
VME boards that just have some LANCE chips and VME drivers.
So far I've heard about 3 suppliers:
Motorola has an Ethernet comm board, though our local techie says
that you can't get raw Ethernet with their stock software. They'll
sell a TCP/IP package to us, but I don't think you can drop below
ARP and use physical addresses.
CMC ("a Rockwell company") has a similar board, and sells "Protocol
Implementor's Kits" for TCP/IP or OSI. The kits include binaries
for TCP/IP that run on the board. Alternatively you can load up
their "Link Level Driver" and talk directly to the Ethernet.
Then there's SBE, Inc., which has a similar line of products.
They have their VLAN-E and MLAN-E boards that run a version of
TCP/IP from "Spider Systems." Their PR blurb claims that they also
support a link level interface.
Now The Question: has anyone had experience with any of these or
any other similar boards? Good? Bad? Did it process this news
item? Would it be transmitting your reply to me? I'll post a
summary of any e-mail responses I get.
Rick.
smith@sctc.com Arden Hills, Minnesota.smith@sctc.com (Rick Smith) (06/11/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
hwajin@daahoud.wpd.sgi.com (Hwa-jin Bae) (06/12/91)
>>>>> 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.smith@sctc.com (Rick Smith) (06/13/91)
I recently posted that summary of information about TCP/IP products: >Several weeks back I posted an inquiry about boards that integrated >an Ethernet interface with a TCP/IP implementation. ... I forgot to include a key bit of information from my original request.. I surveyed products exclusively for the VME bus. Apologies for any confusion that may have resulted. Rick. smith@sctc.com Arden Hills, Minnesota.
perand@admin.kth.se (Per Andersson) (07/01/91)
In article <1991Jun10.201046.16912@sctc.com> smith@sctc.com (Rick Smith) writes: >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....... Anyone have actual experience with CMC boards in an Internetlike environment? Folks at work have started using CMC instead of Excelan board for some reason, and there are some strange problem with default router, arps and such going on, which wasn't a problem with the Excelan board? The router is Cisco btw. /Per -- Per Andersson (perand@admin.kth.se, perand@stacken.kth.se) Now working at Bofors Electronics, managing networks, still reading news at the Royal Institute of Technology