jerry@oliveb.UUCP (Jerry Aguirre) (07/10/84)
I am looking for an improved method for connecting terminals to our
host systems. Our current configuration consists of 4 PDP-11/70s
(48 ports each), 1 Vax (48 ports) and >200 vt100s all connected by
a mass of individual cables in the walls and under the computer room
floor.
I am considering:
1 - An ethernet cable connecting the terminals and systems. I
have read about a device that Interlan makes which allows
10 async terminals to connect to the ethernet.
* Has anyone used this unit?
* Could one ethernet handle 200 terminals @9600 baud
(assuming ~50 in use)?
* How badly will the host ethernet/pseudo-tty processing load
the system (assuming ~10 in use per system)?
* Is the Interlan box difficult for a novice to use?
2 - A system which piggy-backs the data on the phone line. Each
user has a modem under his phone which splits the data and
voice. This system eliminates cabling to each terminal but
still requires a massive set going to the PBX. Also we
frequently have more terminals at a location than phone
lines.
3 - A conventional patch panel. If we were to go with conventional
cabling and a patch panel then cost would be the big issue as
it would not be buying us much.
If you use or know of any system that might be useful then I would
appreciate hearing about it.
Jerry Aguirre
{hplabs|fortune|ios|tolerant|allegra|tymix}!oliveb!jerryron@brl-tgr.ARPA (Ron Natalie <ron>) (07/12/84)
Here at BRL we haven't been overly impressed by the network methods of hooking terminals up to local computers. I mean using things like ethernet or RF cable with little multiplexors strewn about all over the place. I don't think that the technology has been moved along sufficiently yet. Originally we were going to have a real slick PBX that would integrate terminals with our regular phone systems but the government managed to get that screwed up. This is probably real nice. What we have now is a rather simple Gandalf PACX without any of their disgusting attempts at networking. It just takes RS-232 lines in and allows the use to switch to which port he is using out. A special daemon reads the logging port on the switch and snarfs up which physical terminal is connecting to which machine. This isn't really necessary, but it is nice since it allows getty to set the speed without autobaud and filling in TERM and the terminal location for finger appropriately. The nice thing about the GANDALF over other similar PABX's is that the statistics port has all the right informationa and that once the connection is established, the thing is mostly transparent. You can stty your speed, parity, etc...without doing anything to the Gandalf. MICOMs on the other hand are speed specific. To handle the wiring we just use what we call Kermit cable (named after the guy who bought it). This just thirty conductor wire which we wire from the PACX cabinet to about every other office. You only use 3 or 4 wires per terminal so you can get 7-10 terminals on one run. This greatly simplifies the one cable for terminal problem. In our environment, users tend to have their home computer (the one they spend the most time on) in the building they work in. Hence, we have one PACX per building typically for local machine access. Since they do need to access machines in other buildings frequently they can either use TELNET from their home machine or TAC's (stupid little computers that only do user TELNET) over our Campus network. -Ron