Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mcvax!enea!kuling!andersa
From: andersa@kuling.UUCP (Anders Andersson)
Newsgroups: comp.dcom.lans
Subject: Re: ethernet terminal servers
Message-ID: <293@kuling.UUCP>
Date: Thu, 7-May-87 22:59:24 EDT
Article-I.D.: kuling.293
Posted: Thu May  7 22:59:24 1987
Date-Received: Sun, 10-May-87 05:41:41 EDT
References: <45800001@uicsrd>
Reply-To: andersa@kuling.UUCP (Anders Andersson)
Organization: Uppsala University, Sweden
Lines: 105

In article <45800001@uicsrd> kai@uicsrd.CSRD.UIUC.EDU writes:
>How do different Ethernet terminal servers affect network performance,
>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: andersa@kuling.UUCP (...!{seismo,mcvax}!enea!kuling!andersa)