jsq@ut-sally.UUCP (John Quarterman) (07/18/85)
We're moving two thirds of our CS department into a new building here.
It will be wired with an Ethernet, which will be connected (probably
through an IP subnet gateway) to our other networks on campus, and to
the outside world through the ARPANET. Many people will be using
workstations, and will access larger machines only over the network.
Others may connect through a data switch, such as a MICOM, which would
be connected to a few large machines on the network. We are wondering
about the feasibility of doing away with the data switch, by using
Ethertips scattered around the building instead.
What I mean by an Ethertip is an Ethernet network node which serves
as a terminal concentrator and provides access to other hosts on the
network. Something like the old ARPANET TIPs or the current ARPA
Internet TACs.
Specifically, I am interested in the following information for such devices:
Product name.
Vendor (name and contact information).
Number of terminals it can handle.
Cost.
Protocols used above the network layer: TCP/IP/{telnet|rlogin}
preferred, XNS possibly plausible. CHAOSNET, PUP,
and especially 3BNET need not apply.
Some sort of estimate of the network and host load entailed.
While I realize a network login generally puts more load on a host than
a direct terminal login, yet, judging by the amount of network login
traffic we see from workstations, and by people logged in first on a
hardwired line and then across a network to another machine, it seems
unlikely that eliminating the data switch would raise the number of
network logins by a factor of two, and probably by less than 50 per
cent. So the dollar cost of the Ethertip per line, compared to that of
a more ordinary data switch, is the major consideration.
If someone has done a summary of this subject recently, please mail it to me.
Otherwise, please mail comments to me, and I will summarize to this newsgroup.
--
John Quarterman, UUCP: {ihnp4,seismo,harvard,gatech}!ut-sally!jsq
ARPA Internet and CSNET: jsq@ut-sally.ARPA, soon to be jsq@sally.UTEXAS.EDUjsq@ut-sally.UUCP (John Quarterman) (07/23/85)
A week or so ago, I requested information about Ethertips.
Here is a summary of the replies I have received.
At the time, I described an Ethertip like this:
What I mean by an Ethertip is an Ethernet network node which serves
as a terminal concentrator and provides access to other hosts on the
network. Something like the old ARPANET TIPs or the current ARPA
Internet TACs.
It seems I need to be more specific, as there are actually three related
classes of devices in question. Each serves as a terminal concentrator
and provides terminal access to hosts. Two of them use Ethernet as the
transport medium, while the other uses twisted pair.
Data switches: An individual cable runs from each terminal to the switch.
The switch has outgoing cables to ordinary terminal ports on the
target machines. These are also known as port contention devices
or port selectors, and commonly known models are made by MICOM
and Gandalf.
Milking machines: Like a data switch, except that there are two parts,
connected by Ethernet. One part has the terminal cables connected
to it, and the other connects to host terminal ports. Though
the host end may be a special device, still, it looks like a
DH, DMF, DMZ, or some other ordinary terminal controller to the
host operating system: terminal traffic through such a device
uses an independent hardware interface at the target host
from other network traffic. These are sometimes called
Ethernet port selectors.
Ethertips: Terminal cables connect to the Ethertip, which communicates
with the target hosts through their ordinary Ethernet interfaces,
not through terminal ports. The only network hardware required
on the host end is that which is already there for general networking.
The milking machine approach is not what we are looking for in our setup,
as it has one of the main disadvantages of the data switch approach to us:
the target host has to have special hardware on it, thus limiting what
hosts can be target hosts. It is true that the milking machine approach
can avoid a lot of cable runs over the data switch approach, though.
The load on the target operating system for the data switch or milking
machine approach is presumably the same as for a directly connected line.
The load for the Ethertip approach may be lower or higher. Assuming most
of the load is caused by traffic from the target host to the terminal
screen, a DZ-11 type device will transfer such data a character at a time,
a DH-11 type device will transfer it in DMA chunks of about 64 bytes,
and Ethertip data will be transferred by the usual networking software
in larger chunks, possibly as large as 1024 bytes. Thus the actual
data transfer from the host to the Ethertip should cause *less* load
than a directly connected line. However, in an implementation like
4.2BSD there is an extra process, telnetd, involved. So transfer
of data from a program to the terminal involves context switches
between the program and telnetd, which can impose noticable load.
There is also the overhead of the pseudo-tty driver. And, for some
sufficiently large number of network logins, the Ethernet board will
become a bottleneck.
It looks like we can't afford to go completely with Ethertips,
but we may buy a couple of small ones to complement the data switch,
and we will probably let some of our Suns workstations do double
duty as Ethertips.
Below is the information I have received, grouped by class of device.
First is a brief summary of the various devices mentioned, then some of
the text of the responses I received. Information indentifying the
respondents has been filed off, as for any group of even this small
size, there is always someone who didn't realize that their response
would be posted in the summary. Also, the responses have been ruthlessly
edited. Thanks to all who responded.
WARNING: I have not yet contacted most of these vendors, and do not
know what relationship the information below has to what they are
currently selling. There are no warranties or guarantees of any kind
on this information, especially on the prices. CAVEAT EMPTOR.
Ethertips:
Vendor Product Protocols Cost/Line
Bridge two products both speak either
IP/TCP/TELNET, or XNS,
and support ARP
Bridge CS/1T $16K/32lines ($500/line)
Bridge CS/100 $5400/14lines ($386/line)
SMI sun-2/170 ARP,IP/TCP/TELNET $25000?/50lines ($500?/line)
Stanford Ethertip PUP ?
DEC Poseidon LAT LAT (proprietary) $2600/8lines ($325/line)
Milking machines:
Interlan NTS-10 ? $?/8lines
Bridge ?
Ungermann-Bass ?
Others ?
Data switches:
various around $250/line
----------------------------------------------------------------------
Ethertips:
------------------------------
Bridge makes products that will talk standard TCP/IP telnet. I believe
that they're the only ones you'll find right now that will do that.
------------------------------
Description from TCP/IP IMPLEMENTATIONS AND VENDORS GUIDE, July 1985
(available from SRI-NIC as <netinfo>tcp-implementations.txt):
2.3.1. v BRIDGE
PRODUCT NAME: The Communications Server 1 (CS/1)
TYPE: Communications server
DESCRIPTION:
Bridge's CS/1 server with TCP/IP software performs the
function of a terminal or host server, allowing up to 32
asynchronous devices (e.g. terminals, printers, computers) to
access host computers that support TCP/IP and are attached to an
Ethernet LAN. The CS/1 also supports the User Datagram Protocol
(UDP) and the Ethernet Address Resolution Protocol (ARP).
Bridge Communications also offer gateway servers which interface
the CS/1 to X.25 public data networks and the IBM SDLC world.
IMPLEMENTATION-LANGUAGE:
C
DISTRIBUTOR:
Bridge Communications Inc.
1345 Shorebird Way
Mountain View, CA 94043
CONTACT:
J. Patrick Malone, 415-969-4400
PROPRIETY-STATUS:
Product of Bridge Communications
------------------------------
The CS/1T supports up to 32 RS232 devices, and
provides TELNET user and server protocols (serial ports can be hooked up
to terminals or tty ports on hosts with no TCP/IP support). The price
is around $16K for 32 lines, maybe a little less. The user interface is
fairly complete, and last I heard they were considering adding rlogin as
well as telnet. Advantages: reliable, up to 4 or more simultaneous
connections for each connected terminal, each port has its own
configuration file stored on disk, lots of features too numerous to
mention. Disadvantages: small packet size (supposedly it was tuned for
good performance with 4.2bsd, but it could be made faster if it allowed
larger segments), no way for the user negotiate binary mode (though it
works if the host asks for it).
------------------------------
CS-100/TCP:
Number of terminals it can handle. 14, however if you want multiple
sessions open for a single terminal (a desirable feature),
we recommend putting no more than 9 on it. This is not
a performance limit, but rather a limit in memory.
Cost. $5K
Protocols used above the network layer: TCP/IP Telnet
If you aren't in a big hurry, you should wait for their new model,
which will haves more memory. The current CS100 can only have 18
sessions open at once. If all users are using the 14 ports, this
means few of them can use multiple sessions. If the terminals ae
lightly loaded, this is of course no problem. For our systems
staff, we would prefer to have an average of 2 sessions each, and
thus try to limit use to 9 people. For end users, this is typically
no problem.
------------------------------
Bridge offers two types terminal servers (as well as a wide range of
gateways into SNA and I think even XNS). The one we opted for is the
CS/100 which provides 14 ports for $5,400 + $250/yr for the TCP/IP
software. Checking around, I have found that this box is the best
performing hardware around (it uses 2 68000's + custom hardware). It's
probably the best cost/line you'll find, especially if the link into
your hosts is direct (ie. not via async ports).
The other box Bridge offers is the CS/1 which handles 8-32 ports, but 32
ports costs out to $15,600 w/o software (as compared to 42 ports for
16,200 with 3 CS/100's).
Having just spent several weeks looking, I'm pretty sure that this is
the only TCP/IP terminal server currently available (Interlan &
Ungermann Bass both "promise" one soon, but I've never respected their
promises before- I've been watching LANs closely for 4 years in various
professional capacities).
------------------------------
Recently we have sucessfully auditioned the Bridge Corp. series
of TCP/IP-based TIPs which they call a "Communications Server". Details
follow;
Product Name - CS/1 Communications Server (big box, Multibus based,
maximum of 32 lines by adding I/O cards.)
CS/100 Communications Server (low profile box, single
board for everything, maximum of 14 lines.)
Vendor - [ see above ]
Cost - These prices are rough, I don't have a price list handy.
Full retail is something like the following-
CS/1 $10,000 for minimum configuration (8 ports?)
$12,000 for maximum configuration (32 ports)
CS/100 $4,000 for minimum configuration (4 ports?)
$5,400 for maximum configuration (14 ports)
Protocols - Either XNS or TCP/IP. "Compatible with Ethernet
Version 1.0 and IEEE 802.3 specifications."
Performance - We have the most experience with the older CS/1 model.
Throughput can be a problem with heavily loaded TIPs. This is true for
the Stanford homebrew TIPs running PUP and is certainly going to be the case
for a TIP running protocols with much higher overhead. On the other hand,
loading of TIP lines works by the averages so it's not as bad as it might be.
Running "ttime" on 4.2 BSD (a program which outputs a steady stream of
chars and does timing) we can get a full 9600 baud stream from any given
Bridge TIP port. A scope shows solid back-to-back chars. This is very good
single port performance. We don't have any numbers for multiple Bridge port
response as yet. With something like 4 or 5 users all running 9600 baud, no
flow control, there haven't been any complaints. But that's hardly a stringent
test.
Booting of the Bridge TIPs is from a 5 1/4 floppy disk. I prefer
that things boot down the network, but since there isn't any standard boot
protocol for TCP/IP I can't blame Bridge for this. We haven't had any
problems with the floppy.
The Bridge can use either a name lookup table located on the floppy,
or a designated host on the network for name service. It would be nice to
have the capability of designating more than one host for network name
service.
The hardware handshaking for modem control on the CS/1 is difficult
to make work properly. We finally got an answer modem hooked to the
box, but it could use some more handshaking lines to really do things right.
I don't know what the status of this is on the newer CS/100
In general we are satisfied with the performance of the Bridge
TCP/IP based TIP for small numbers of users. We haven't really stressed
one yet and so we can't make any predictions of how the response will be
for many users. The users hooked to the Bridge TIPs here are mostly running
async terminals into 4.2 BSD running on VAXen. The TIPs have been very
reliable and the users are happy with their connections.
------------------------------
You can use Sun Microsystems products to put together what you want.
Buy a Sun-2/170 rack mount or Sun-2/120 deskside workstation without
the graphics board. You can plug in up to three SYSTECH terminal
controllers with 16 lines each. Add in the 2 console ports and that
is 50 terminals per box. You could run diskless if there is a file
server on the network, or get a small disk. You could allow users to
do some small amount of computing on the system, or just limit it
to a terminal concentrator by running a customized telnet. Sun uses
standard TCP/IP protocols, with other standard protocols available.
The cost of course has to be traded off against quality of service,
but this configuration would be about $500 - $1000 per user. Note that
the cost on the server host is almost nil, compared to the usual terminal
switch approach in which you need a corresponding demultiplexor on the
host side as well. Also University discounts can be negotiated, so
don't be discouraged by high list prices.
[ Also, if you've already got the suns for use as workstations,
it may be plausible to hang some terminal lines off them at little
extra cost. -jsq ]
------------------------------
I am part of the team that developed an "EtherTip" at Stanford about
four years ago. Since then the software has been rewritten, but they
now have several hundred terminal lines throughout campus going in through
these boxes. Unfortunately Stanford still uses PUP, so that code is
probably not useful to you.
------------------------------
The Stanford Ethernet has 30 subnets linked by homebrew gateways
and terminal traffic is primarily accomplished with homebrew TIPs. There
are well over 1500 terminal lines hooked up to something like 50 different
TIPs scattered about on the various subnets. These homebrew TIPs presently
use PUP but are being re-written to use TCP/IP.
----------------------------------------------------------------------
The other thing I'm looking at is [DEC Poseidon] LAT, which runs about
$325/line w/o modem control for an 8-line box that sits on the ethernet
and is booted from any TOPS-20 or VMS system (maybe Ultrix too). It's
great for several reasons, but the only OS's that support it come from
DEC, so unless you use Ultrix or want to do some work you probably
won't be interested; send me mail if you'd like more info.
----------------------------------------------------------------------
Milking machines:
------------------------------
Other companies make terminal-concentrator products that connect to
Ethernets and talk secret protocols to each other to get the job done.
Bridge also has these products, as does Ungerman-Bass. Both are, I
think, based on XNS to some extent, so routing may not be as bad as one
might assume. These products would take the basic "milking machine"
approach, which is a kludge, but may be better on system overhead as
things stand now. Hmmm. Bridge might also make a milking machine that
talks IP. Some companies are putting their concentrators on DMF32
lookalikes, which gets rid of the milking machine mess. I can't
remember right now who is doing that, though.
------------------------------
Have you talked with the MICOM people recently? I don't know
if they have what you want, but they did acquire Interlan sometime
around January.
Interlan has a small 8 port box that will sit on an ethernet and
talk to another 8 port box. They are rather expensive in that you
need to connect a box to ports on your system. The product is the
NTS-10. I evaluated a set a few months ago and it seems to work pretty
well. you can name ports on both ends and specify whether a port
is a command port, a called port or both. You can also require
passwords on any ports you want.
I haven't talked to them recently, but they may have added to the line.
------------------------------
Interlan makes a box that's more accurately called an Ethernet port selector --
you still have RS-232 ports on your host, but the terminals are hooked
to another RS-232 box on the same cable. I think they now have a variant
host end that plugs into the UNIBUS and looks like a DMF-32, but I'm not sure.
We had a loaner unit here for a week or two, but it wasn't suitable, since
we couldn't enable flow control.
------------------------------
Interlan (617) 890 6448 in Waltham Mass has exactly what you
specified in the article. They even have an Ether board that
plugs into a VAX and that talks to the terminal
concentrators and looks like a DH (or something).
[ Actually, that makes it a milking machine, not an Ethertip -jsq].
----------------------------------------------------------------------
Data switches:
These are left as an exercise for the reader.hedrick@topaz.ARPA (Chuck Hedrick) (07/24/85)
Both the Bridge TCP boxes and the DEC LAT boxes can be used as either true terminal servers or "milking machines". That is, you can have the following: user terminals \ \ \ / / / -------- | | | | -------- | ===================================================== | | ---------- ---------- | | | Host | | | | A | ---------- ---------- |||||||||| ---------- | Host | | B | ---------- Host A connects directly to the Ethernet. It gets packets directly from the TIP that the users talk to. Host B does not talk directly to the Ethernet. It is frontended by a black box (probably identical to the TIP) with RS232 output, which goes into the host just like any other terminal line. It is useful to have this configuation freedom. A direct arrangement (A) is least expensive for a machine that is going to have any Ethernet connection anyway (e.g. for FTP). The "milking machine" arrangement makes sense in any of the following cases: - the machine is not otherwise going to be on Ethernet, and won't need many network connections (e.g. our RSTS system, where we just want a couple of TA's at a time to be able to log in from our campus net) - there are going to be lots of network connections, and the host operating system has high overhead for telnet connections. (We won't mention any names here.) - the host does not support the protocol used by the boxes (e.g. if you decide to use LAT and have a couple of non-DEC machines. DEC refers to this configuration as "reverse LAT").
jsq@im4u.UUCP (07/25/85)
> Both the Bridge TCP boxes and the DEC LAT boxes can be used as > either true terminal servers or "milking machines". That is, you > can have the following: Good point: I forgot to mention that. The picture should straighten out the distinction (which seems to be confusing many people) between {EtherTIP|EtherTAC} and {milking machine|Ethernet port selector}. Milking machines may be quite useful, but all the machines we're interested in providing terminal access to already have Ethernet connections. I've gotten a couple more responses. It appears DEC makes a DECNET based thing. Several more raves about Bridge (including one from the vendor), of which I quote part of one (not the one from the vendor). Something from U. Alberta, on which I leave the identifying marks, as it wouldn't make sense otherwise. As before, there are no guarantees on any information in this article. I will wait another week, and if I have received anything else worth posting by then, I will post another summary. ---------------------------------------------------------------------- DEC has a thing called a DECSA which multiplexes 32 terminals onto an Ethernet for $20,000. I gather that internally it's a PDP-11, and it speaks everybody's favorite protocol, DECnet. Call 603-884-7993 for info. ------------------------------ John - as far as I know, if you want TCP/IP (as we do), the only game in town is from Bridge Communications (they're in Silicon Valley somewhere.) They have two products: the CS/1, which costs $10K for an 8 port model and can expand to 32 ports at $2K per 8 ports; and the CS/100, which costs $4K for 4 ports, $5K for 10, and $6K for 14. If you work out the math, the CS/100 always costs less, but the CS/1 is more expandable (it has a multibus) so new products come out for the 1 first. Bridge is an XNS company, but they do support TCP/IP, and it's a pretty good product. We have one of each and are basically happy; we are buying a pile of CS/100's. If you are willing to take XNS, you can look at Bridge's XNS software for the CS/1 or 100, or Interlan's similar products. AMD was going to do an Ethertip (we call them a TAC, since that seems to be the preferred ARPA term these days - Terminal Access Controller) but they dropped the project. I understand DEC has one too, but it only supports DECNET. The CS/* support both user and server telnet. You can plug in a dumb hosts on RS232 ports and the CS/1 will accept telnet connections for it and get you one of the RS232 ports. They jump through hoops; you can have multiple connections open from a port and switch between them dymanically, you can set flow control and the like dynamically, program in macros which can be invoked with a simple command or on power up, display network stats, etc. There are two levels of super user. Here are the minuses. Most are minor. (1) It won't talk to a 3B2 3Bnet board. We suspect a hardware incompatibility, since the 3Bnet won't talk to an Interlan board either. This is major to us but probably not to you. It talks fine to an Interlan, DEUNA, Excelan, and 3Com. (2) It's fussy about dynamic configuration of baud rate and parity. To get it to recognize baud rate you have to type .CR. which is worse than many that you only have to type CR . The parity for a port has to be set and it really cares - this makes dialups difficult (you have to pick a standard parity and require everyone dialing in to use it.) (3) We've had a couple of hung connections, one beat on the CPU of our VAX. They don't reproduce often enough to track down (2 in 6 months.) (4) The non-Bridge transceiver cable we connect it to doesn't fit well (this is a general Ethernet gripe) and sometimes I have to wiggle the cable when it goes off the net. (5) It doesn't like HP 2621's for some reason I can't recall - you have to cut one of the RS232 leads to make it talk to a 2621. ------------------------------ Date: Mon, 22 Jul 85 09:53:42 mdt >From: ihnp4!alberta!myriasb!ref (Dick Foster) Subject: Re: Ethertips In-Reply-To: USENET article <2394@ut-sally.UUCP> The University of Alberta Computing Science Department has Ethertips that were put together in house. An individual Ethertip consists of a SUN 100 workstation (without a monitor or keyboard) with an Ethernet board and 2 octal serial interface boards (providing 16 terminal lines). The "system" software is a port of the BSD4.2 networking software along with a minimal amount of machine dependent support code (about 800 lines for the ethernet interface routine, 350 lines for the octal serial interface, and 300 lines for miscellaneous support routines). It would be a simple task to port this code to a different hardware configuration. The interface to the "user" level code is of course the same as in BSD4.2, so writing the upper level protocol code is easy. Telnet is supported, and a similar protocol which allows the Ethertip to echo locally when possible to reduce network traffic. The ability to "stack" login sessions on several machines is included. If you would like more information or are interested in obtaining a copy of the source code, contact me or Steve Sutphen (..ihnp4!alberta!steve) . (I am no longer working at the University, but I developed the code for the Ethertips and am willing to help with any problems). Dick Foster ..ihnp4!alberta!myrias!ref ------------------------------ -- John Quarterman, jsq@ut-sally.ARPA, {ihnp4,seismo,ctvax}!ut-sally!jsq