Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!cmcl2!rutgers!gatech!rayssd!rayssdb!ras From: ras@rayssdb.RAY.COM (Ralph A. Shaw) Newsgroups: comp.protocols.tcp-ip,comp.unix.wizards,comp.dcom.lans Subject: Re: Ethernet - Hyperchannel Gateway Message-ID: <1800@rayssdb.RAY.COM> Date: Mon, 19-Oct-87 10:58:56 EDT Article-I.D.: rayssdb.1800 Posted: Mon Oct 19 10:58:56 1987 Date-Received: Tue, 20-Oct-87 06:40:47 EDT References: <1822@celtics.UUCP> <11221@beta.UUCP> Sender: ras@rayssdb.RAY.COM (Ralph A. Shaw @ Raytheon Company, Portsmouth RI) Organization: Raytheon Company, Portsmouth RI Lines: 42 Summary: local experience with the hyperchannel BC601 Xref: mnetor comp.protocols.tcp-ip:1465 comp.unix.wizards:4997 comp.dcom.lans:874 We at Raytheon have had some experience with the Hyperchannel products, in particular the BC601, or EN601 as it is now known. While I do not speak for the larger group of sites within the company, I'll try and bring up some of the problems we think we have run into with the EN601 product. This is merely using the Hyperchannel bus as a carrier, and allowing ethernets to talk to each other, and is not performing any type of gateway/protocol translation facility between the TCP, DECNet, XNS or other protocol machines and the NETEX/BFX machines. We have a number of different locations scattered throughout Mass and this site in RI that are interconnected via both A-Hyperchannel and B-Hyperchannel equipment over T1 lines. Some of the locations are tied together with Bridge GS3/M's, some with Vitalink Translan's, some with the AT&T ISN "EBIM" adapters, and 5 locations with the NSC EN601's, all presumably as part of an evaluation and/or production installation, both of which add up to sites in at least 10 towns on an extended ethernet; (total net population: 300+, 70% DECNet) To make a long story short, many of the problems we have had have been related to having such a widely spread out extended LAN. One of the failings of the EN601 is the lack of visibility into what is going on, in the way of maintenance and diagnostic aids as an ethernet bridge, compared to the Bridge/Vitalink style of products. Another problems may result in an inconsistency of loop detection algorithms between the different vendors' bridges (while Bridge/Vitalink are supposed to cooperate). Yet Another situation (which is still unclear as to it's impact) is the fact that at least multicast packets are batched up into a 4K buffer, and then VC-transferred to each other EN601 in sequence, imposing quite a delay when the BFX traffic is going on (making for very choppy telnet sessions). Anyway, the 601's are still here, and NSC is supposedly working on the problems we have with them, and they have improved them dramatically in the time since we first got them in (we were an early Beta-test), but I think that no matter what they do, the BC601 will always be compromised by the fact it has to time-slice over the HyperChannel. -- Ralph Shaw, Raytheon Co., Submarine Signal Division Portsmouth, RI 02871 ras@rayssd.RAY.COM or ihnp4!rayssd!ras