[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference csc32::consolemanager

Title:	POLYCENTER Console Manager
Notice:	Kits, Scans, Docs on CSC32:: as PCM$KITS:,PCM$DOCS:, PCM$SCANS:
Moderator:	CSC32::BUTTERWORTH

Created:	Thu Aug 06 1992
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	1541
Total number of notes:	6564

561.0. "bridged LAT distances/speeds?" by TROOA::GILBERT () Tue Jan 17 1995 18:25

I have a customer with 2*7000 systems, a couple of 4100s and a 3100 model 80
in his computer room, and 8 4100s located in 8 remote locations.  His network
is bridged, with mostly 56KB connections, although 2 are 19.2KB.  I am
involved in the account because they are looking to us to upgrade a number
of products at all of their sites, and they anticipate us having to fly to
each location due to lack of remote control of consoles.

I want to propose a PCM solution as part of this work.  I think a good part of
the cost would be covered by the reduced time and expense required to do their
upgrades if they could be done from the home site.

I need a few questions answered before I feel comfortable proposing this 
solution.

1. Are the line speeds a concern?  I have done a few VCS installations, but
the nodes were always in the same building.  I never tried to go over large
bridged networks.

2. Should I go VAX or Alpha (since this is likely a standalone system).  I
would like to think an AlphaStation of some size would do the job, rather
than proposing a VAXstation.  They have no Unix so OSF/1 is out.

3. If their terminal servers are telnet-able, would I be better to propose
telnet vs. lat for the remote sites?  Has any testing been done to determine
which would be better?

I've got a good shot at making this happen, but I want to be sure it will work
before they buy it.  What a concept!

Thanks,

Peter

T.R Title User Personal
Name Date Lines

561.1 Some answers. OPG::SIMON Wed Jan 18 1995 10:27 65

T.R	Title	User	Personal Name	Date	Lines
561.1	Some answers.	OPG::SIMON		`Wed Jan 18 1995 10:27`	65
	Peter, >1. Are the line speeds a concern? I have done a few VCS installations, but >the nodes were always in the same building. I never tried to go over large >bridged networks. The trouble with the above question is it's a bit like asking how long is a piece of string. A lot depends on how much data you expect down the lines. I would think the 56k lines will be OK and as long as your users dont expect stunning response so will 19.2k. As far as we are concerned as long as the underlying transport i.e. LAT or TELNET can cope with latency on the slow lines we wont mind. >2. Should I go VAX or Alpha (since this is likely a standalone system). I >would like to think an AlphaStation of some size would do the job, rather >than proposing a VAXstation. They have no Unix so OSF/1 is out. Go for Alpha with plenty of memory ( we tend to be a bit memory hungry in PCM). $ for $ you get more bang for the buck with Alpha as well. >3. If their terminal servers are telnet-able, would I be better to propose >telnet vs. lat for the remote sites? Has any testing been done to determine >which would be better? Pros and Cons. I am assuming there is no routing involved over this network at all. I.e. if you use TELNET there will not be seperate nets or subnets as this would incur extra traffic on the network. Because TELNET is a very basic protocol it does not have any keepalive timers and seems to cope rather well with latency. We unplugged the network on a terminal server using TELNET connections and waited several seconds then plugged in again and it carried on. In fact the terminal server had also buffered the extra data. LAT is far less tolerant of that and notices the link break, it then shuts the connection. Now the above raises both good and bad issues: 1) TELNET copes with the break in service better than LAT. 2) LAT error handling is better, because really it should notice the line going away. 3) LAT because it notices the line going away is likely to be quicker for us to be able to reconnect. With TELNET we have to send a TELNET GetStatus periodically and wait for a set time to see if the line responds, so it is inherently slower to reconnect. From customer cost point of view LAT is free i.e. bundled with system. TELNET will cost them for UCX. Now the big question I do not know the answer to is which is the most efficient protocol i.e. bits sent down the wire per byte of real data. You will have to ask LAT and TELNET gurus this. Hope this has helped. If you need any more please ask and I shall try to answer you. Cheers Simon... it ca I've got a good shot at making this happen, but I want to be sure it will work

Peter,

>1. Are the line speeds a concern?  I have done a few VCS installations, but
>the nodes were always in the same building.  I never tried to go over large
>bridged networks.

The trouble with the above question is it's a bit like asking how long is a
piece of string. A lot depends on how much data you expect down the lines. I
would think the 56k lines will be OK and as long as your users dont expect
stunning response so will 19.2k.

As far as we are concerned as long as the underlying transport i.e. LAT or
TELNET can cope with latency on the slow lines we wont mind.

>2. Should I go VAX or Alpha (since this is likely a standalone system).  I
>would like to think an AlphaStation of some size would do the job, rather
>than proposing a VAXstation.  They have no Unix so OSF/1 is out.

Go for Alpha with plenty of memory ( we tend to be a bit memory hungry in PCM).
$ for $ you get more bang for the buck with Alpha as well. 


>3. If their terminal servers are telnet-able, would I be better to propose
>telnet vs. lat for the remote sites?  Has any testing been done to determine
>which would be better?

Pros and Cons.

I am assuming there is no routing involved over this network at all. I.e. if
you use TELNET there will not be seperate nets or subnets as this would incur
extra traffic on the network.

Because TELNET is a very basic protocol it does not have any keepalive timers
and seems to cope rather well with latency. We unplugged the network on a
terminal server using TELNET connections and waited several seconds then plugged
in again and it carried on. In fact the terminal server had also buffered  the
extra data. LAT is far less tolerant of that and notices the link break, it then
shuts the connection.

Now the above raises both good and bad issues:

1) TELNET copes with the break in service better than LAT.

2) LAT error handling is better, because really it should notice the line going 
   away.

3) LAT because it notices the line going away is likely to be quicker for us
   to be able to reconnect. With TELNET we have to send a TELNET GetStatus
   periodically and wait for a set time to see if the line responds, so 
   it is inherently slower to reconnect.

From customer cost point of view LAT is free i.e. bundled with system. TELNET 
will cost them for UCX.

Now the big question I do not know the answer to is which is the most efficient
protocol i.e. bits sent down the wire per byte of real data. You will have
to ask LAT and TELNET gurus this.

Hope this has helped. If you need any more please ask and I shall try to answer
you.

Cheers Simon...
it ca

I've got a good shot at making this happen, but I want to be sure it will work