Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!topaz!hedrick
From: hedrick@topaz.RUTGERS.EDU (Charles Hedrick)
Newsgroups: comp.dcom.lans
Subject: Re: ethernet terminal servers
Message-ID: <11755@topaz.RUTGERS.EDU>
Date: Tue, 5-May-87 16:23:12 EDT
Article-I.D.: topaz.11755
Posted: Tue May  5 16:23:12 1987
Date-Received: Thu, 7-May-87 05:06:36 EDT
References: <45800001@uicsrd>
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 18
To: kai@uicsrd.CSRD.UIUC.EDU


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.