ethernet terminal servers
k...@uicsrd.uucp
How do different Ethernet terminal servers affect network performance,
user-perceived responce time (especially for editing), network
management, and the company bank statement?
I would like to hear from administrators and users of any Ethernet
terminal servers. We are about to outgrow our 16 terminal ports, and
already have Ethernet working between two UNIX boxes using a DELNI.
I appreciate the chance to benefit from your previous experiences.
Patrick Wol{e
System Manager
UUCP: {seismo,pur-ee,ihnp4,convex}!uiucuxc!kailand!pat
INTERNET: pat%kai...@uxc.cso.uiuc.edu
BITNET: pat%kailand@uiucuxc
MILNET: pat%kai...@uiucuxc.arpa
CSNET: pat%kailand%u...@uiuc.csnet
TELEX: 9102409772
PHONE: (217) 356-2288
US SNAIL: Kuck & Associates, Inc.
1808 Woodfield Dr.
Savoy, Il 61874
Charles Hedrick
We use TCP/IP terminal servers from both Bridge and Cisco. Under
ideal conditions, there is no difference in feel between a line on the
terminal server and a direct hardwired line. However if your Ethernet
is overloaded, then obviously that can cause delays. Also, the
typical Unix implementations of telnet can introduce delays. The
telnet server (telnetd) runs as a user-mode process. It reads each
character from the network, feeds it back out into a pty, and then
when the echo comes back, reads it from the pty and writes it to the
network. So each character typed causes two extra process activations
and a bit of CPU time. (Obviously large outputs like screen refreshes
get handled in a group.) It is typical to see several percent of the
CPU going to telnetd. If you have a machine with lots of users this
could matter. But in terms of response, which is what you asked, the
process activations are probably more serious. Under a heavy load,
there can be enough of a delay that response is noticably sluggish.
What we do is put the telnet protocol handling into the kernel on our
large timesharing systems (Pyramids). For machines with one or two
users (Suns, typically), this is not a problem, so we don't bother.
cy...@hi.uucp
>
>How do different Ethernet terminal servers affect network performance,
>user-perceived responce time (especially for editing), network
>management, and the company bank statement?
Ethernet terminal servers are great. They give users access to
every computer that is on the net (assuming that they talk to
correct protocol). A problem thought is that they add A LOT
of little packets to the net. For instance we have several
Bridge tcp/ip terminal servers. The problem is that for every
character the user types, a packet is sent. Since the minimum
ethernet packet size is 64 bytes, there is A LOT of overhead.
Now that is not to say that there isn't a way to get the Bridge
terminal server to put more data into a packet, it is just that
you can expect a lot of minimum sized packets flying around
the net. We have one section of our local net that has
3 14 port Bridges on it. Although there are a lot of packets
moving around, we are only at about 10-15% of the total bandwidth.
Hope this helps.
--
@__________@ W. Tait Cyrus (505) 277-0806
/| /| University of New Mexico
/ | / | Dept of EECE - Hypercube Project
@__|_______@ | Albuquerque, New Mexico 87131
| | | |
| | hc | | e-mail:
| @.......|..@ cy...@hc.dspo.gov or cy...@hc.arpa or
| / | / {gatech|ucbvax|convex}!unmvax!hi!cyrus
@/_________@/
lama...@pioneer.uucp
>user-perceived responce time (especially for editing), network
>management, and the company bank statement?
>
We have been testing an Encore Annex terminal server here at Ames. It works
very well, and is very conveniently arranged (auto reboot,
nameserver, domain name server, rwho, rlogin ,telnet, etc.) In my personal
experience, it is a very good choice. (naturally, your milage may vary, etc.)
Hugh LaMaster, m/s 233-9, UUCP {seismo,topaz,lll-crg,ucbvax}!
NASA Ames Research Center ames!pioneer!lamaster
Moffett Field, CA 94035 ARPA lama...@ames-pioneer.arpa
Phone: (415)694-6117 ARPA lama...@pioneer.arc.nasa.gov
"In order to promise genuine progress, the acronym RISC should stand
for REGULAR (not reduced) instruction set computer." - Wirth
("Any opinions expressed herein are solely the responsibility of the
author and do not represent the opinions of NASA or the U.S. Government")
Yakim Martillo
Does anybody have figures for obtained packet rates for asynchronous
terminal concentrators over ethernet?
I mean the configuration where the host has an ethernet interface and
lives on the same LAN as the asynchronous terminal concentrator which
supports say 8-16 terminals.
I think DEC has a product of this type called LAT (LAN Asynchronous
Terminal?). I would suspect that because protocol layers 3 and 4
would not need to be implemented that better performance would be
obtained than with telnet or rlogin based terminal concentrators
(although internetting would be impossible). I would still be
interested in figures for telnet or rlogin style terminal
concentrators as well. Also while the maximum packet rate at the
concentrator is of interest, I would really like to know what sort of
packet rates people consider good on the host side.
Yakim Martillo
Walter Underwood
> Terminal?). I would suspect that because protocol layers 3 and 4
You still have to do all the work that TCP does, because you can still
lose packets. With multiple bridges and buffered repeaters, it is
possible to get duplicte or out-of-order packets.
So, you cannot get rid of the TCP overhead. You can optimize it for
your exact application, particularly if you make the transport protocol
aware of block mode and VT-100 ESC sequences and all sorts of other
grot.
Recommended reading on the subject:
RFC-872 TCP-ON-A-LAN M. A. Padlipsky
Abstract
The sometimes-held position that the DoD Standard
Transmission Control Protocol (TCP) and Internet Protocol (IP)
are inappropriate for use "on" a Local Area Network (LAN) is
shown to be fallacious.
Walter Underwood
Anders Andersson
>user-perceived responce time (especially for editing), network
>management, and the company bank statement?
As terminal servers normally adhere to the standard protocols to be useful,
I think performance probably depends more on the kind of site configuration,
the user community and the hosts than what brand of terminal server you have.
We have 43 8-port Net/One terminal servers (Ungermann-Bass) on a single
logical LAN (five physical segments with non-filtering repeaters), installed
in January this year. This makes 344 ports, of which about 110 are office
terminals, 68 student, 16 modem, 112 "backwards" on non-ethernet hosts,
3 printers and the rest (35) is surplus (to be used later on).
I just checked the statistics (we have a SpiderMonitor constantly running).
Over a period of 63 hours the network has transmitted in total some 18
million packets, while each terminal server is responsible for something
between 100,000 and 1 million packets. The average packet size seems to be
pretty close to 64 bytes. As we don't do any excessive file tranfers or
such at the moment, the terminal traffic (which is TELNET on TCP/IP, by the
way) is the main issue here. The network doesn't seem to be heavily loaded,
the maximum peak (under normal condititions, not while "testing" the net)
has been around 10% of theoretical bandwidth, but maybe our user community
is a little inactive at the moment...
We have sometimes seen slight delays in user response time, but I don't
think they've been annoying. Any *major* delays seem to be the result of
the host being overloaded rather than the network itself. Some of this
might be reduced by having the TELNET in the kernel on hosts with many
users.
Screen editing doesn't seem to be more affected by slow responses than
any other interaction.
We will be putting more equipment on the network in the near future,
probably some laser printer, (diskless) workstations and similar things.
If network overload becomes a problem, I guess we'll consider isolating
the workstation environment.
The kind of network management involved may vary between different brands.
What we have is a beta-release of Ungermann-Bass' TCP/IP product. They use
a central PC for server configuration (through a dedicated menu driven
program) and downloads. It's somewhat tedious to configure 43 servers for
the first time, but there are operator-definable templates that may be used
to set up the numerous port parameters in a standard fashion.
There are still bugs in this release, requiring us to manually reboot a
server now and then (protocol problems, weird packets on the net may hang
the entire server or such - we've eliminated most of the weird sources as
a work-around). Having servers connected "backwards" to non-ethernet hosts
using multiple RS-232 lines is another source of potential problems with
flow control deadlocks and alike (primarily on printer lines). The name
server functionality is only partial - it works with the "backward" hosts,
but not with the ethernet ones. The latter require IP numbers...
We had the opportunity to evaluate a couple of brands before picking this
one. Below is what I learned from them. Please note that this info is from
fall -86, and that enhancements may have been done since (some of which
I've heard about, some not).
Bridge Communications servers may be either centrally or locally managed.
In both cases a floppy disk is used to store configurations and download
programs. We heard from one of their customers that these floppies were
quickly worn out - he had a network somewhat smaller than ours, and had
the impression they needed replacement every month or something like that.
When testing a server, we found that the floppy was accessed every time a
user connected to a host using its name instead of just the IP number (and
that names were case-sensitive).
Spider Systems Ltd of Edinburgh, UK, has a small box with either 10, 6 or
even 2 (!) ports. No central server, configuration is done on the box (in
EEPROM I believe). The one we tested had to be configured from one of the
physical ports, but we were told that later releases should be possible
to reconfigure remotely via a standard TCP connection. This "SpiderPort"
allows "backward" coupling to non-ethernet hosts, but our problem was that
it didn't allow ports on several servers to share the same name, making 10
the maximum number of ports with a common name (U-B allows the same name
on any port in the network, and Bridge solves the problem by providing
64-port bauta-servers).
The Encore Annex with 16 9-pin RS-232 ports is configured and downloads
from any UNIX machine you might have on your network, often the Encore
Multimax I guess (if I'm wrong I'll blame that somewhat unclear
documentation we were provided with). No "backward" coupling functionality.
I wanted to configure a printer port, but the documentation referred to
some mkrnod(8) utility, unknown to my BSD VAX. Host names (the only way
to refer to a host whatsoever) were supposed to be supplied by the rwho
daemons on the particular hosts, but I'm told that since release 2.1 (Feb?)
the Annex has a name server capability of its own.
The Annex has some unusual features, though, like daisy-chaining of up to
four Annexes on the same transceiver without the use of a multiport, and
some fancy GNU emacs user interface which I never had a chance to see.
DEC seemed unable to provide us with what we wanted - TCP/IP was an
explicit requirement of ours.
I think we had to pay roughly $400 per terminal port, but budgeting has
never been my business (I'm not even sure of the exchange rates this week).
Take it with not more than 0.66 significant digits.
--
Anders Andersson, Dept. of Computer Systems, Uppsala University, Sweden
Phone: +46 18 183170
UUCP: and...@kuling.UUCP (...!{seismo,mcvax}!enea!kuling!andersa)
tit...@btnix.uucp
> Nf-ID: #N:uicsrd:45800001:000:792
> Nf-From: uicsrd.CSRD.UIUC.EDU!kai Apr 24 12:42:00 1987
>
>
> How do different Ethernet terminal servers affect network performance,
> user-perceived responce time (especially for editing), network
> management, and the company bank statement?
>
> I would like to hear from administrators and users of any Ethernet
> terminal servers. We are about to outgrow our 16 terminal ports, and
> already have Ethernet working between two UNIX boxes using a DELNI.
> I appreciate the chance to benefit from your previous experiences.
>
> Patrick Wol{e
> System Manager
>
(Suns and MG1s) up through microVaxen, 750s and a 785. We have settled on
telnet and tcp/ip on ethernet as our common communication system. We use the
excelan tcp/ip product on our vaxen and spiderport terminal servers. We have
a total of 90 or so engineers, each with a terminal, using the system mainly
for editing using screen editors (EDT, TPU, Emacs and E). Average ethernet
loading is less than 1% and response is mainly satisfactory although worse
than a direct line. Reliability is good apart from bulk file transfers under
System V using the Excelan product which is prone to lock up. We have found
that Spider products are uniformly good (we also have a link to another
ethernet, some 100 miles away using X21 at 64K and a Spiderbridge which we
use for file transfers, mail feed (SMTP) and remote logins).
I feel that we have made the right choice. No other system could offer us
the flexibility, ease of administration and cost.
Nigel Titley
Email: NTi...@axion.bt.co.uk
Snail: British Telecom Research Labs, Martlesham Heath, Ipswich, Suffolk, UK
--
..ukc!btnix!titley
Sergeant! Search america, and don't forget to look under the bed.