Terminal servers (Was: Looking for a big Unix box)

[Neil Gorsuch]

In article <EMV.90Feb28121751 at duby.math.lsa.umich.edu> emv at math.lsa.umich.edu (Edward Vielmetti) writes:
>In article <24573 at princeton.Princeton.EDU> tr at samadams.princeton.edu (Tom Reingold) writes:
>   Neil Gorsuch talks about how using an ethernet-based terminal server
>   can eat up your net bandwidth.  My understanding is that the
>   packets for rlogin and telnet are so few and small that they are
>   insignificant compared with NFS.  Am I wrong?
>Neil Gorsuch is selling a product which competes with
>ethernet-based terminal servers, and his opinions on
>the subject should be considered in that light.

I'm Neil Gorsuch 8-).  While I love to sell product (entrepreneurial
types tend to be that way), I posted the original article to provide a
counterpoint to the "you need a big EXPENSIVE computer to handle
multiple users" and "you need a big EXPENSIVE workstation to be a
server for desktop workstations" attitudes which I find somewhat
repugnant.  Sometimes, big EXPENSIVE computers are better, sometimes
they're not.  I would just stress that it is very much worth people's
time to investigate and consider non-traditional approaches.
Especially considering the wave of under $5000, double digit MIPS
workstations just over the horizon.  And don't let the people that
sell the EXPENSIVE computers be your information source for "small"
computer capabilities 8-), or the other way around.  If you noticed,
the system that I proposed would work equally well whether the
terminals were hanging off the ethernet or elsewhere.  "Elsewhere"
just offers a some technical advantages and some cost savings.  My
postings are an argument for "smaller is sometimes VERY cost
effective", not an argument for "elsewhere".

>NFS will eat up your net well before telnet traffic.

It depends what you're doing.  If you have a bunch of diskless clients
hanging off one ethernet, NFS will almost certainly dominate.  If,
however, you have 1 or 2 large machines with their own disks and a 100
or so users logged in through the ethernet, as was being discussed,
there should be almost no NFS traffic, but a lot of character traffic.
>From what I have been told, with TCP/IP encapsulation, about the best
that a single ethernet can do is about 150,000 actual characters a
second.  If you have 100 people doing editing, with a screen update
every 10 seconds, you get 100*24*80/10=19200 characters per second,
which is a noticable, but hardly crippling, fraction of the ethernet
TCP/IP capability.  I know of one case where many, many diskless
client workstations are contemplated that will have 32 users each
running a single special application system that involves a lot of
screen updating.  Since they are going to put about 15 diskless
clients per server, each server's private ethernet leg will require
15*32*24*80/10=92160 characters per second which would be almost
impossible to have co-exist with the NFS read/writes associated with
480 users.  Whereas, if you have the character data transfers
"elsewhere", it works out very nicely, and enables a BIG cost savings
in computer costs.  And on that note illustrating an advantage of my
particular technology, I will conclude (probably not too many of you
have made it to this point 8-) by saying that no one technology is
better than others.  Particular technologies and strategies will be
better and/or save you money in particular cases, and it behooves
system designers to be open-minded and consider uncommon
configurations.
--
Neil Gorsuch     INTERNET: neil at uninet.cpd.com      UUCP: uunet!zardoz!neil
MAIL: 1209 E. Warner, Santa Ana, CA, USA, 92705     PHONE: +1 714 546 1100
Uninet, a division of Custom Product Design, Inc.   FAX: +1 714 546 3726
AKA: root, security-request, uuasc-request, postmaster, usenet, news