eriks@yunexus.UUCP (Eriks Rugelis) (01/22/88)
About a week ago, I posted this article to INFO-VAX and BIG-LAN from
my BITNET attached host. I saw the article appear on BIG-LAN but not
on this list. This is a re-posting. My apologies if you've already
seen it.
-----------------------------------------------------------------
Hello NetLand!
I am soliciting commentary on experiences/gut-feelings with respect to
running TCP/IP terminal servers as the exclusive terminal connection
method for VAX/VMS systems. We at York University are in the process
of putting together a budget wish-list for the coming fiscal year and
some of the items are replacement systems for our UNIBUS based VAXen.
DEC's own corporate strategy is leaning heavily toward LAT based terminal
servers. However, since DEC is keeping the LAT protocol proprietary it
has no competitive market to drive prices down (good for DEC, not so good
for us penny-pinched university types). In addition, a TCP/IP based
solution makes it possible for any given terminal to also speak to a
non-VMS host. This has increasingly greater attraction to us but
all the same, in this instance, the primary concern IS to provide access
to the VMS boxen.
I suppose my primary concern in the matter is the performance aspect.
Are any of the commercially available TCP/IP-on-VMS implementations
built to handle 70-80 concurrent TELNET or rlogin connections on
a MicroVAX 3000 scale CPU? Presently DEC has entered into cooperative
marketting agreements with TWG and NRC for the WIN/TCP and Fusion
products. I welcome any user-experience information with either of
these products. Any other products that anyone cares to recommend or
warn me away from are also of interest (FTP Software, Excelan?).
If you feel that you have a particularly inflamatory comment that you
do not wish to share with the rest of the net, please reply to me
directly and indicate that you do not wish to be quoted. I promise
discretion. In general, you can mail to me directly and I will
summarize back to the lists to which this message is posted.
Thank you in advance for any responses,
Eriks
--
Voice: Eriks Rugelis Ma Bell: 416/736-5257 x.2688 NetNorth: eriks@yulibra
Soon to be: eriks@libra.yorku.ca UUCP: seismo!mnetor!yunexus!eriksgjc@BU-IT.BU.EDU (George J. Carrette) (02/11/88)
The most efficient from a host-load point of view is probably the EXCELAN implementation. The EXOS 201 board has a processor on which is implemented ICMP, IP, TCP, and UDP, and even TELNET. For the special case of TELNET they supply a vms terminal-driver that makes an incoming telnet connection look like a regular terminal. Other implementations either require a seperate TELNET process for each connection, forcing data through pty type device, *or* they hack kernel-level telnet implementations for efficiency. At least the excelan implementation works through normally supported user-written VMS driver techniques. What EXCELAN is doing about the BI-BUS stuff is a good question, best to give them a call. I have used both the wollongong TCP and the EXCELAN one. -gjc
KASHTAN@IU.AI.SRI.COM (David L. Kashtan) (02/16/88)
Having been involved with TCP implementations for quite some time, I wanted to get my 2 cents in... I used to be a big supporter of the idea of off-board (separate processor) TCP implementations. It turns out that none of the "supposed" advantages of these cards really pans out. Usually the reason put forward for these boards is that they offload the CPU. You need to look very carefully at this -- there are still some very significant communication costs to these boards (and the VMS kernel still needs to do data multiplexing/de-multiplexing). It turns out that a good software-only TCP implementation will do just as well as the off- board implementation. The 2 TCPs for VMS that I have been involved in have TELNET service that consumes no more processor than hardwired DZ-11 terminal interfaces and they connect to the VMS terminal driver in standard way. Both the aforementioned implementations are based on the 4.3bsd UNIX networking code and any improvements made in the UNIX world (and, like it or not, that IS where the major TCP work is being done) can be quickly imported to the VMS world. I don't know how the off-board processors are right now, but 6 months ago (the last time I looked) they were all still running code based on 4.2bsd which had MAJOR performance bugs. Also note that off-board implementations can't act as gateways. Sometimes you need to get special hooks into the network to do special things. I have just completed a VMS NFS (Network File System) server that needed special hooks into the network in order to get good enough performance to act as a serious file server. Try to do that with an off-board implementation. Don't dismiss the software approach, David -------