kai@uicsrd.UUCP (04/24/87)
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%kailand@uxc.cso.uiuc.edu
BITNET: pat%kailand@uiucuxc
MILNET: pat%kailand@uiucuxc.arpa
CSNET: pat%kailand%uxc@uiuc.csnet
TELEX: 9102409772
PHONE: (217) 356-2288
US SNAIL: Kuck & Associates, Inc.
1808 Woodfield Dr.
Savoy, Il 61874hedrick@topaz.RUTGERS.EDU (Charles Hedrick) (05/05/87)
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.
cyrus@hi.UUCP (05/06/87)
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? 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: | @.......|..@ cyrus@hc.dspo.gov or cyrus@hc.arpa or | / | / {gatech|ucbvax|convex}!unmvax!hi!cyrus @/_________@/
lamaster@pioneer.UUCP (05/06/87)
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? > >Patrick Wol{e 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 lamaster@ames-pioneer.arpa Phone: (415)694-6117 ARPA lamaster@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")
martillo@athena.mit.edu (Yakim Martillo) (05/06/87)
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
wunder@hpcea.HP.COM (Walter Underwood) (05/07/87)
> 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 ... 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
andersa@kuling.UUCP (Anders Andersson) (05/08/87)
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)
titley@btnix.UUCP (05/19/87)
in article <45800001@uicsrd>, kai@uicsrd.CSRD.UIUC.EDU says: > 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 > I run a network of approximately 30 machines, ranging from workstations (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: NTitley@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.
norm@tc.fluke.COM (Norm Seethoff) (01/13/89)
We are in the process of configuring a system for a new application which
causes to be interested in Ethernet terminal servers. Would any of you
care to suggest your favorite terminal servers?
Do any of them directly support RS-422, or are they all still
RS-232 or 423?
What is their model of the world? Do they only support terminal
initiated (terminal to host) connections, or do they allow host
initiated (Ethernet) connection to terminal?
How are they with modem control? Can they do a reasonable job of
supporting dialup modems? Do any of them support enough modem control
flexibility to utilize hardware flow control with a Telebit TB+?
What kind of reliability have you experienced? What service options
were available to you if repair was ever needed?
Thanks for the help. I'll post a summary of the responses.
Norm Seethoff John Fluke Mfg. Co, Inc. (206) 356-5054
norm@tc.fluke.COM {uw-beaver,microsoft,sun}!fluke!normreh@ccd700.UUCP (reh) (01/14/89)
Norm asked about terminal servers and there is another question that I think should be asked, because it is a problem for me. We have a VAX 8700 with a couple terminal servers, and users logged into the VAX thru the terminal server are assigned virtual terminal names. This is because the server is capable of allowing the user to have multiple sessions from the same server port. The problem is that the host has no way of finding the physical port that the user is connected to. This makes it frustrating to debug bad ports or locate users. Is there any way to find out the physical port that a user is on? ...................................................................... Bob Harold 313-845-5404 Ford Motor Co., DPTC room B-206 ...!ihnp4!mibte!ccd700!eed090!bob 17000 Rotunda Drive Disclaimer: The views expressed might Dearborn, MI 48121-6010 not be those of my employer or myself Have questions about life? Read the original design manual - the Bible. ......................................................................
hedrick@geneva.rutgers.edu (Charles Hedrick) (01/17/89)
We use cisco and Bridge terminal servers, with TCP/IP. Both allow connections incoming or outgoing. Incoming is used for driving printers or when you have a machine that doesn't support TCP/IP. In the latter case, you back up a group of terminal server ports to a group of serial lines from the machine, and configure the terminal server to front for the machine. You can set up a rotary so that one IP address gets you the first free line in the group. Both support modem control. cisco doesn't have enough lines coming out of their connectors to handle all of the modem control signals. However they have several combinations of signals that they support. One combination does do hardware flow control. I suggest contacting latzko@topaz.rutgers.edu for details on how our Telebits are set up. I think we are using hardware flow control, but wouldn't want to swear to it. Note that rutgers.edu, which is a major UUCP node, does all of its async traffic through a cisco terminal server. It has had reliability problems, but they have been due to the modems, not the terminal server. Both the cisco and the Bridge hardware have been reliable. In both cases we keep enough spares that we can afford to have a unit down. So we just send the unit or board back. A service contract doesn't seem worth it. cisco claims to have designed for one failure per 10 years. We certainly get better than a year MTBF, and I'm fairly sure it is more than 3 years. Some of our hardware folks might be able to calculate it more accurately. Certainly our modems are far more trouble than the boxes they are connected to. Somebody commented in a response about problems figuring out where a user is coming from. I believe Encore makes their TCP port number map to the line number, so finger or who could be modified to show the line number. cisco's servers respond to "finger" requests. However if several users are connected to the same machine, it may be hard to tell them apart.
prc@maxim.ERBE.SE (Robert Claeson) (01/18/89)
In article <405@ccd700.UUCP>, reh@ccd700.UUCP (reh) writes: > We have a VAX 8700 with a couple terminal servers, and users logged > into the VAX thru the terminal server are assigned virtual terminal > names. This is because the server is capable of allowing the user > to have multiple sessions from the same server port. The problem > is that the host has no way of finding the physical port that the > user is connected to. This makes it frustrating to debug bad ports > or locate users. Is there any way to find out the physical port > that a user is on? It depends on what terminal servers you're using. If you have Encore's Annex terminal servers, you can create pty's (assuming you run UNIX) on the host that are tied to ports on the servers and let the host put a getty on that port. But then you cannot open multiple sessions. Or, you can have the Annex log all connections. It can use either the syslog facility on your host or its own log, or both. I do hope someone can get their act together and standardize on a consistent remote terminal or pty numbering scheme. Encore has done this with Annex'es connected to their own computers, the Multimax'es (provided you use their own distributed tty interface), and I guess that DEC has done something similar with their own LAT remote tty protocol. Disclaimer: Any opinions expressed in this article is solely those of my own. My employer might share them, but don't bet it. If you want to quote this article, please include this disclaimer. -- Robert Claeson, ERBE DATA AB, P.O. Box 77, S-175 22 Jarfalla, Sweden "No problems." -- Alf Tel: +46 758-202 50 EUnet: rclaeson@ERBE.SE uucp: uunet!erbe.se!rclaeson Fax: +46 758-197 20 Internet: rclaeson@ERBE.SE BITNET: rclaeson@ERBE.SE
mhyman@cup.portal.com (Marco S Hyman) (01/20/89)
Excuse my ignorance, but: Why use a terminal server? If I need more serial access to our local network my first thought would be to add more serial ports to one or more of the machines on the network. What advantages/disadvantages does a terminal server give me? --marc ...... Marco S. Hyman Note: Reply-to: UUCP: ...!sun!sfsun!hsfmsh!mhyman Domain: sfsun!hsfmsh!mhyman@sun.com not the address in the header.
hedrick@geneva.rutgers.edu (Charles Hedrick) (01/21/89)
Here are some advantages and disadvantages of a terminal server compared with directly connected terminals and modems. I'm thinking of TCP/IP's telnet protocol, but similar considerations should be true of other network technology. 1) If you are in a changing environment it's easier to plan. All terminal lines go directly to a terminal server and stay there. When you change computers, you don't have to move people from the old one to the new one, nor do you have to move people from one to another when their tasks change and they start using a different one. 2) There is only one kind of asynch interface to worry about. Every machine has a slightly different definition of RS232, with different handling of modem lines, grounding, etc. So our terminals people are saved from having to know about the details of all of them. 3) Many machines have substandard RS232 support. The terminal server does a better job. 4) If your primary machine is down, you can go play on another one. If you're directly connected, you lose. Before terminal servers, people typically had switches on their desk to connect them to one of several machines. This is no longer needed. 5) The telnet implementations on the terminal server is typically better than the telnet implementation in many hosts. 6) In public terminal rooms and for dialups, you get much better utilization. If terminals and modems are tied to a machine, they can only be used by people with an account on that machine. Sure, they can telnet elsewhere, but they have to be able to log into the first place to start with. 7) If you go through a multiuser system, your response time will be affected by the load on that system. So you now have to worry about the load on two systems, not just one. 8) If lots of people telnet from the machine they are wired to to others, you're using your hosts as terminal servers. They are probably more expensive per user than a real terminal server, and probably not as good. There are disadvantages as well: 1) You become critically dependent upon the state of your network. You had better have good network support. This is a non-trivial consideration. Rutgers puts a lot of effort into our network, both hardware and software. 2) You become critically dependent upon the quality of the software on your hosts that handles incoming connections. If it is substandard, you have to be able to fix it, or use "milking machine" configurations. 3) Every user goes through at minimum two computers: the real one and the terminal server. So there is more that can fail. This depends upon how often people use the same machine. If they typically use different ones, then they'll have to telnet out of their primary machine, and they are dependent upon two machines anyway. Normally terminal servers are rather simple pieces of hardware and are quite reliable. 4) Some "out of band" terminal functions become harder. The classic ones are ^S/^Q and clearing the output buffer. Rlogin and telnet both have provisions to deal with these problems. If you have good implementations on both the terminal server and host, the connection feels just about like a hardwired lines. If not, things can be unpleasant. ^S/^Q can be handled completely. Either use rlogin or use the new remote flow control option in telnet. Clearing the output buffer when the user types ^C, ^O, etc., can be done reasonably, but even with good implementations you'll get a few extra lines of output before they take effect.
blarson@skat.usc.edu (Bob Larson) (01/21/89)
In article <Jan.20.21.32.16.1989.540@geneva.rutgers.edu> hedrick@geneva.rutgers.edu (Charles Hedrick) writes: >Here are some advantages and disadvantages of a terminal server >compared with directly connected terminals and modems. The third alternative, of using a port selector (aka data pbx) shouldn't be ignored. (We use micoms here at usc, mostly 6600s, connecting over 4000 terminals and over 100 hosts.) >1) If you are in a changing environment it's easier to plan. >4) If your primary machine is down, you can go play on another one. >6) In public terminal rooms and for dialups, you get much better >utilization. >7) If you go through a multiuser system, your response time will >be affected by the load on that system. All true of port selectors. >2) There is only one kind of asynch interface to worry about. Terminal - port selector cables are constant. Computer - port selector cables can still be a problem. >5) The telnet implementations on the terminal server is typically better >than the telnet implementation in many hosts. One of the reasons we have terminal server boxes on our port selector. >8) If lots of people telnet from the machine they are wired to to >others, you're using your hosts as terminal servers. They are >probably more expensive per user than a real terminal server, and >probably not as good. And eathernet terminal servers are more expensive per port than port selectors, and rarely have the redundancy. >1) You become critically dependent upon the state of your network. >2) You become critically dependent upon the quality of the software >on your hosts that handles incoming connections. >4) Some "out of band" terminal functions become harder. Not true of port selectors. >3) Every user goes through at minimum two computers: the real one and >the terminal server. Micom 6600 and others have enough built in redundancy and servicability without taking it down I can't remember this ever being a problem. (Power outages and rare firmware upgrades are the only reasons I have seen them down.) Sometimes the connections between the port selectors become bottlenecks, but this is hardly unique to them. -- Bob Larson Arpa: Blarson@Ecla.Usc.Edu blarson@skat.usc.edu Uucp: {sdcrdcf,cit-vax}!oberon!skat!blarson Prime mailing list: info-prime-request%ais1@ecla.usc.edu oberon!ais1!info-prime-request
ron@hardees.rutgers.edu (Ron Natalie) (01/22/89)
The first reason is that most of our terminal traffic comes from public rooms and from dialins (most of the offices have dedicated workstations or PC's). In this case, it is not clear what machine people will want to connect to. So rather than having 8 modem lines going here, 8 going there, these terminals talk to one machine, these to another, we just pool all the resources on the terminal servers. From there the user can go anywhere. At Rutgers, we span seven campuses. Each campus has public facilities that need to make use of stuff on other campuses. TCP terminal servers make this easy. A couple of campuses have terminal servers but no login-able machines there. Another reason is that most of the popular machines around here (VAX's and Sun's) have lousy RS-232 ports. DEC has never been convinced that you shouldn't interrupt VMS on every character the users types and the 16 port Sun ALM units never were that reliable. Rutgers.edu is a USENET backbone hub, and we finally scrapped the ALM in favor of just putting the trailblazers and everything else on one of the terminal servers. -Ron
ron@hardees.rutgers.edu (Ron Natalie) (01/22/89)
>>Here are some advantages and disadvantages of a terminal server >>compared with directly connected terminals and modems. > > The third alternative, of using a port selector (aka data pbx) > shouldn't be ignored. (We use micoms here at usc, mostly 6600s, > connecting over 4000 terminals and over 100 hosts.) I've lived in both environments. When I started hooking things up at my previous job, the only Ethernet terminal servers on the market were pretty bad. We settled on a Gandalf PACX terminal switch. By and large it worked pretty well. Rutgers had a network of terminal switches as well. We had three INFOTRON switches that are interconnected together and then out to the machines. Port selectors are still a pain. Terminal servers have come a long way. The problem is I've got to run an RS-232 connection to each bloody host port that I want to hook up. I've got to worry about speed problems. Some lines won't autobaud, some will. Adding terminals to the terminal server is about the same level of work as adding them to the port selector, but adding hosts is easy. I don't have to touch the terminal servers. I just plug in the Ethernet interface of the new host and it is accessible to all 20 or so servers we have spread around (there may be more that are run by academic departments that I don't know about) and to all the other hosts on the network through out the state. People on the terminal servers can even get to the supercomputer center in Princeton. Developping an RS-232 switching system to do all this would be a night mare. If a group as a few more terminals to hook up, we can drop in the appropriate sized unit right near the terminals. Rutgers used to be a mess of Short Haul modems and line drivers to bring things back from each building to the switch. > And eathernet terminal servers are more expensive per port than > port selectors, and rarely have the redundancy. Not so. If you buy large terminal servers, you can get the cost per port down to the comparable RS-232 switch. We run 96 lines on a CISCO ASM unit. They're a lot smaller than the equivelent port selector and I don't seem them drop connections or fail as much as our infotrons and I never had to worry about clock jitter like I did with the Gandalfs.
prc@maxim.ERBE.SE (Robert Claeson) (01/23/89)
In article <13718@cup.portal.com>, mhyman@cup.portal.com (Marco S Hyman) writes: > Why use a terminal server? If I need more serial access to our local > network my first thought would be to add more serial ports to one or > more of the machines on the network. Do that. Go ahead and add, say, 16 more ports to each one of your 5 computers on the network, whereas you can add ONE terminal server with 16 ports on it to get the same accessability. Furthermore, assume that someone normally does his work on machine A, but he has his terminal connected to machine B simply because there's no more ports on machine A. Then machine B is only used as a very, very expensive network interface. Not to mention if it goes down... And can you use multiple sessions on a direct-connected terminal (there's C shell with job control, but everything in the world isn't BSD)? And what about shared printers, shared modems, SL/IP connections, high-speed serial communication (most computers can't go beyond 19.2 Kbps), etc etc? I don't mean that ports on the computer is a bad thing, but terminal servers are simply more useful/increases accessability/has better price/ performance ratio than the equal number of ports on each one of your machines. -- Robert Claeson, ERBE DATA AB, P.O. Box 77, S-175 22 Jarfalla, Sweden "No problems." -- Alf Tel: +46 758-202 50 EUnet: rclaeson@ERBE.SE uucp: uunet!erbe.se!rclaeson Fax: +46 758-197 20 Internet: rclaeson@ERBE.SE BITNET: rclaeson@ERBE.SE
kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) (01/24/89)
In article <14843@oberon.USC.EDU> blarson@skat.usc.edu (Bob Larson) writes: > hedrick@geneva.rutgers.edu (Charles Hedrick) writes: >>Here are some advantages and disadvantages of a terminal server >>compared with directly connected terminals and modems. > >The third alternative, of using a port selector (aka data pbx) >shouldn't be ignored. (We use micoms here at usc, mostly 6600s, >connecting over 4000 terminals and over 100 hosts.) > If you build your campus network as an internetwork (ie, IP routers, fiber backbones, etc) you can build very large "virtual dataswitches", something you can't as easily do with a port selector. If you already need an internet for ethernetted hosts, the campus "lines" for your virtual dataswitch are "free". There are many other advantages to keeping your terminal-host protocol running on the same foundation (IP) as your host-host protocol, like network management. Worldwide internet connectivity is also a "freebie", except for the router connection to the outside. In essence, telnet terminal servers are more "scaleable" than port selectors. Scaleability is becoming recognized more and more as an important aspect of communication protocols and hardware. Kent England, Boston University
phil@diablo.amd.com (Phil Ngai) (01/24/89)
| The third alternative, of using a port selector (aka data pbx) | shouldn't be ignored. (We use micoms here at usc, mostly 6600s, When my company adds a host on one of our Ethernets in California, Texas, or Japan, my Ethernet terminal server in California can instantly talk to it, without getting new Micom ports and hooking them up to the new host, without ordering new long lines, and without worrying about running out of Micom ports on the host. Data PBXs are for people who do small networks. Such situations never seem to last. Either they find themselves out of a job, or working on a large network. -- Phil Ngai, phil@diablo.amd.com {uunet,decwrl,ucbvax}!amdcad!phil "In Texas, they run the red light after it turns red." "In Taiwan, they run the red light before it turns green."
lamaster@ames.arc.nasa.gov (Hugh LaMaster) (01/26/89)
In article <Jan.20.21.32.16.1989.540@geneva.rutgers.edu> hedrick@geneva.rutgers.edu (Charles Hedrick) writes: >Here are some advantages and disadvantages of a terminal server >8) If lots of people telnet from the machine they are wired to to >others, you're using your hosts as terminal servers. They are >probably more expensive per user than a real terminal server, and >probably not as good. About 1 1/2 years ago, I looked at a number of our systems here when this issue came up. Typically, HALF of all terminal sessions on our collection of VMS VAXes were SET HOST to somewhere else. After pondering this for a few days, I decided that terminal servers, as a system, were more efficient than hardwired terminals. Then, I looked at the overhead. Well, at first it didn't look too good (old TWG TCP). But then, looking at Unix and new TWG TCP/IP, things looked much better. In fact, it may be more efficient now to use a terminal server even to get to a single host. And it is definitely more efficient overall if people typically log on to other systems a lot of the time. -- Hugh LaMaster, m/s 233-9, UUCP ames!lamaster NASA Ames Research Center ARPA lamaster@ames.arc.nasa.gov Moffett Field, CA 94035 Phone: (415)694-6117
scarter@caip.rutgers.edu (Stephen M. Carter) (01/27/89)
In article <Jan.20.21.32.16.1989.540@geneva.rutgers.edu> hedrick@geneva.rutgers.edu (Charles Hedrick) writes: >Here are some advantages and disadvantages of a terminal server >compared with directly connected terminals and modems. To add two more items to Chuck's advantages: 1) Host maintenance contracts are usually on per board basis. Some vendors charge very little for RS232 port boards, some charge a rather extreme amount. Almost enough to support a terminal server with an equal number of ports. 2) Both original O.S. costs, and monthly software support are sometimes calculated on "number of users". This is usually tied to number of hardwired RS232 ports. This is mostly true in the Unix world where AT&T's Unix license did not define virtual connections (eg terminal server) as a "user". Thus, it can be much cheaper to have as few RS232 ports as possible on any given host.