Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!ucbcad!ucbvax!ucbarpa.Berkeley.EDU!leres
From: leres@ucbarpa.Berkeley.EDU.UUCP
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Ethernet Terminal Concentrators
Message-ID: <18787@ucbvax.BERKELEY.EDU>
Date: Thu, 7-May-87 22:10:25 EDT
Article-I.D.: ucbvax.18787
Posted: Thu May  7 22:10:25 1987
Date-Received: Sat, 9-May-87 06:45:38 EDT
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: leres@ucbarpa.Berkeley.EDU (Craig Leres)
Lines: 34


I'm not familiar with the cmu/tek vms tcp/ip. Does it use the Salkind
epacket/elink code? The (low) performance you quote in your posting
leads me to believe so.

Salkind's code was the first to share the deuna with decnet. Basically,
a process (elink) hangs reads on the deuna and on a raw internet
socket. When a packet comes in off the wire, elink gets it and then
writes it onto the raw socket. It goes through the internet code, comes
out via the indriver, and arrives in the users buffer. An out bound
packet goes the other way; from user process to internet kernel to
elink process to deuna driver. At the time it was first implemented,
elink was great; you could have decnet and internet on your machine
without buying two ethernet interfaces. But obviously, having data pass
through the elink process isn't very efficient.

Decnet uses an (undocumented) internal interface to the ethernet driver
called the alt start facility. This facility allows kernel use of the
ethernet driver. I recently rewrote epacket for the Wollongong Group's
WIN/VX product. Now, packets go directly from the ethernet driver to
the internet code so things runs faster and uses less cpu time. If I
login to a 9600 baud hardwired terminal on a 780 and telnet to a 750
and do "help /nopage * * *", the 780 is 95% idle and the 750 is 60%
idle. On occasion, I have achieved 85 Kbytes/sec between the VMS 780
and a 4.3 Unix 780.

I've heard that Kashtan rewrote epacket to use the internal "ffi"
interface to the ethernet driver for SRI's Multinet product. I'd expect
it to also be much faster than an elink process implementation.

I don't sell or distribute these products. If you are interested in
them, please contact TWG or SRI.

		Craig