TTA to LTA time differences...

[Nigel Wright_1]

We have a terminal

TTA0:

$ sho term/full tta0:
Terminal: _TTA0: Device_Type: Unknown Owner: No Owner

Input: 9600 LFfill: 0 Width: 80 Parity: None
Output: 9600 CRfill: 0 Page: 24

Terminal Characteristics:
Interactive Echo Type_ahead No Escape
No Hostsync TTsync Lowercase No Tab
Wrap Scope No Remote No Eightbit
Broadcast No Readsync No Form Fulldup
No Modem No Local_echo Autobaud No Hangup
No Brdcstmbx No DMA No Altypeahd Set_speed
No Commsync Line Editing Overstrike editing No Fallback
No Dialup No Secure server No Disconnect No Pasthru
No Syspassword No SIXEL Graphics No Soft Characters No Printer Port
Numeric Keypad No ANSI_CRT No Regis No Block_mode
No Advanced_video No Edit_mode No DEC_CRT No DEC_CRT2
No DEC_CRT3 No DEC_CRT4 No DEC_CRT5 No Ansi_Color
VMS Style Input
$


We have a correspounding LTA terminal performing the same function - communicating with the same hardware device (unit) as is connected to the TTA0.

LTA801:
$ sho term/full lta801:
Terminal: _LTA801: Device_Type: Unknown Owner: No Owner

Input: 9600 LFfill: 0 Width: 80 Parity: Even
Output: 9600 CRfill: 0 Page: 24 Terminate on parity errors

Terminal Characteristics:
Interactive Echo Type_ahead No Escape
No Hostsync TTsync Lowercase No Tab
Wrap Scope No Remote Eightbit
No Broadcast No Readsync No Form Fulldup
No Modem No Local_echo No Autobaud Hangup
No Brdcstmbx No DMA Altypeahd Set_speed
No Commsync Line Editing Overstrike editing No Fallback
No Dialup No Secure server No Disconnect No Pasthru
No Syspassword No SIXEL Graphics No Soft Characters No Printer Port
Numeric Keypad No ANSI_CRT No Regis No Block_mode
No Advanced_video No Edit_mode No DEC_CRT No DEC_CRT2
No DEC_CRT3 No DEC_CRT4 No DEC_CRT5 No Ansi_Color
VMS Style Input
$

On the DECServer 200/MC the target port looks like:-

Local> sho port 1


Port 1: Server: DS2D9B

Character Size: 8 Input Speed: 9600
Flow Control: XON Output Speed: 9600
Parity: Even Modem Control: Disabled

Access: Remote Local Switch: None
Backwards Switch: None Name: PORT_1
Break: Local Session Limit: 4
Forwards Switch: None Type: Soft

Preferred Service: None

Authorized Groups: 0
(Current) Groups: 0

Enabled Characteristics:

Input Flow Control, Output Flow Control


When we run a test from the VAX to the unit via TTA0 it takes 7 mins, if we do the same test via LTA801 it takes 20 mins.

Has anyone any ideas why it is taking so much longer via the LTA route?

Many Thanks Nigel.

[Wim Van den Wyngaert]

TTA is a direct connection while LTA suffers from the network delay (LAT). Try increasing the speed.

Wim

[Duncan Morris]

Same device?

TTA0 - parity NONE, NO Eightbit, NoAltyp

LTA801 - parity EVEN, Eightbit, Altyp


Duncan

[Nigel Wright_1]

Sorry pasted the wrong TTA in - here goes:-

$ sho term/full tta1:
Terminal: _TTA1: Device_Type: Unknown Owner: No Owner

Input: 9600 LFfill: 0 Width: 80 Parity: Even
Output: 9600 CRfill: 0 Page: 24 Terminate on parity errors

Terminal Characteristics:
Interactive Echo Type_ahead No Escape
No Hostsync TTsync Lowercase No Tab
No Wrap Scope No Remote Eightbit
No Broadcast No Readsync No Form Fulldup
No Modem No Local_echo No Autobaud No Hangup
No Brdcstmbx No DMA No Altypeahd Set_speed
No Commsync Line Editing Overstrike editing No Fallback
No Dialup Secure server No Disconnect No Pasthru
No Syspassword No SIXEL Graphics No Soft Characters No Printer Port
Numeric Keypad No ANSI_CRT No Regis No Block_mode
No Advanced_video No Edit_mode No DEC_CRT No DEC_CRT2
No DEC_CRT3 No DEC_CRT4 No DEC_CRT5 No Ansi_Color
VMS Style Input
$

[Wim Van den Wyngaert]

Also post show server of the decserver. Consider decreasing the circuit timer.

Found this :

LAT is a timer-based protocol: A terminal server simply gathers
up incoming data into buffers. When the circuit timer goes off, the server
takes as much data from the buffers as will fit into a packet and sends the
packet off to the host. Then it goes back to gathering more data. No matter
how much data arrives, the server won't send anything until the circuit timer
goes off; and when the timer *does* go off, it will send exactly one packet.
The effect of this is to place an absolute upper limit on the amount of
Ethernet bandwidth a circuit can use; and, more important, to place an
absolute upper limit on the rate of interrupts a single circuit can generate.

The 80ms value for terminal server to VAX connections was chosen because it
resulted in essentially identical load for LAT connections and traditional
async mux connections. Larger values produce a lower load, but beyond about
100ms you start seeing an objectional delay in character echoing.

Wim

[Nigel Wright_1]

That info about the timer wqs very interesting.

here is the sho server:-


Local> sho server

DECserver 200 V3.3 BL39 LAT V5.1 ROM BL20 Uptime: 4 02:16:22

Address: 08-00-2B-09-C3-FF Name: DS2D9B Number: 0

Identification:

Circuit Timer: 80 Password Limit: 3
Console Port: 1 Prompt: Local>
Inactivity Timer: 30 Queue Limit: 24
Keepalive Timer: 20 Retransmit Limit: 8
Multicast Timer: 30 Session Limit: 32
Node Limit: 100 Software: PR0801ENG

Service Groups: 0

Enabled Characteristics:

Dump, Lock


Thanks Nigel.

[Jon Pinkley]

Nigel-> "When we run a test from the VAX to the unit via TTA0 it takes 7 mins, if we do the same test via LTA801 it takes 20 mins."

What are you using for a test? Is the data going primarily from the VAX to TTA or is the TTA device sending a significant amount of data?

Running something like a kermit transfer from a device to the VAX via LTA in general will take longer, especially if the sender is waiting for an acknowledgment from the VAX before sending the next "packet".

The upside is that I would expect the interrupt mode time used on the VAX to be less than the case for the TTA device.

The timers in LAT are to attempt to "coalesce" the input traffic, so a burst of input characters is more likely to all be sent in a single ethernet packet.

I am not sure if there are timers on the VAX side that you can control. However, in general, output from the VAX (think a human using a terminal) will have some large chunks of data, and the small stuff is the result of echoing character input. The point is that for bulk output, the baud rate is normally the limiting factor, and for input (to the VAX) the timers are usually the limiting factor.

Remember there is a nearly fixed cost to send an ethernet packet. Think of it like a bus, whether there is a single passenger or 40, it requires nearly the same resources for a trip.

If your test was your actual application, then the only control you have is to adjust the timers, and possibly the baud rate. The timers are "terminal server global", so any change will affect all ports on the terminal server.

The cost of lowering the timer is that it will increase the utilization of your ethernet (may not be a problem depending on your network utilization), and will increase the interrupt load on the VAX. This is similar to lowering quantum on a CPU bound system; it improves the interactive responsiveness but increases the overhead.

Good luck,

Jon

[Nigel Wright_1]

A bit more info about what we are doing here - there's an application (in-house) that runs on a VAX that talks to a card that is in a test unit.

The first test results were:-

TTA0: 3 mins
LTA: 20 mins


I altered the server circuit timer to 30, the lowest allowed, and we then re-ran the test and got the following results:-

LTA: now 7 mins.


Have newer DECSevers a lower circuit timer value, so we can get the time approaching the TTA time?

Thanks for all the replies so far.

Nigel.

[Karl Rohwedder]

I checked with a DS90M using NAS software V2.3A: it allows a minimum of 20ms for circuit timer.

regards Kalle

[Nigel Wright_1]

On the transfer - I have asked the people who wrote the program and they say the flow is pretty well equally balanced.

Regards Nigel.

[Wim Van den Wyngaert]

What is between the decserver and VMS node ?
It could go thru some routers and those have LAT config too (also a circuit timer ?).

Is there any other load on the decserver ?

Is the network saturated ?

Check mc latcp show node/cou on the vms node for duplicates etc.

Check show server count on the decserver too.

Wim

[Heinz W Genhart]

Hi Wim

** It could go thru some routers and those have LAT config too **

I thought LAT is non routable. Am I wrong ?

Regards

[Nigel Wright_1]

What is between the decserver and VMS node ?

It could go thru some routers and those have LAT config too (also a circuit timer ?).

It just goes through they network on site - just 2 routers I beleve



Is there any other load on the decserver ?

None what so ever.



Is the network saturated ?

No it's fine.



Check mc latcp show node/cou on the vms node for duplicates etc.

$ mc latcp show node/cou

Node Name: XXXXX

Seconds Since Zeroed: 8287810 Multiple Node Addresses: 0
Messages Received: 0 Duplicates Received: 0
Messages Transmitted: 0 Messages Retransmitted: 0
Slots Received: 0 Illegal Messages Received: 0
Slots Transmitted: 0 Illegal Slots Received: 0
Bytes Received: 0 Solicitations Accepted: 0
Bytes Transmitted: 0 Solicitations Rejected: 0
Multicast Bytes Rcvd: 600560710 Solicitation Failures: 0
Multicast Bytes Sent: 100685498 Transmit Errors: 0
Multicast Messages Rcvd: 2894440 Last Transmit Error: 0
Multicast Messages Sent: 825291 Virtual Circuit Timeouts: 0
No Transmit Buffer: 0 Discarded Output Bytes: 0
Multicast Messages Lost: 0 User Data Lost: 0
Multicast Send Failures: 0 Resource Errors: 0
Controller Errors: 0 Incoming Solicits Accepted: 0
Last Controller Error: 0 Incoming Solicits Rejected: 0


Check show server count on the decserver too.


Local> sho server counters

DECserver 200 V3.3 BL39 LAT V5.1 ROM BL20 Uptime: 0 01:28:25

Seconds Since Zeroed: 5305 Frames Sent, 1 Collision: 16
Bytes Received: 2943306 Frames Sent, 2+ Collisions: 1
Bytes Sent: 1464124 Send Failures: 2
Frames Received: 53943 Send Failure Reasons: 0000100000
Frames Sent: 31810 Receive Failures: 0
Multicast Bytes Rcv'd: 448582 Receive Failure Reasons: 0000000000
Multicast Bytes Sent: 954 Unrecognized Destination: 4039
Multicast Frames Rcv'd: 2382 Data Overrun: 0
Multicast Frames Sent: 9 User Buffer Unavailable: 0
Frames Sent, Deferred: 42 System Buffer Unavailable: 0

Messages Received: 46118 Duplicates Received: 0
Messages Transmitted: 30401 Messages Re-Transmitted: 2
Solicitations Accepted: 2 Illegal Messages Rcv'd: 0
Solicitations Rejected: 0 Illegal Slots Rcv'd: 0
Multiple Node Addresses: 0 Illegal Multicasts Rcv'd: 0


Local>

[Wim Van den Wyngaert]

Seems ok to me.

LAT is non-routable but the routers or bridges must pass all packets to all networks. Don't now how thet do that but it could have config too. CISCO ?

I found that latcp show node also shows a circuit timer (80 ms over here). Try to set that to 10 (or whatever) too.

Wished LAT was more open (=documented).

Wim

[Kelly Stewart_1]

Nigel,

It seems that the LAT transmission timer that Wym pointed out is the key. As I understand it, changing the timer from 80ms to 30ms changed the test time from 20 min to 7 min.

20 * 30 / 80 = 7.5, a pretty close correlation.

But in lowering the timer further, you may need to consider the size of the message that the card is sending to the VAX. If you make the timer too short to allow for a complete message, your system will need two timer periods to complete a transaction. If my calculations are correct (don't bet on it!), at 9600 baud, 30ms allows for 26 bytes, 20ms for 17 bytes, and 10ms for 8 bytes.

Also check the port setup options for any newer DECServer you are considering. I believe that at least one -- the DECServer 90L+ -- does not support even parity.

Regards, Kelly

[Wim Van den Wyngaert]

Just noticed you are using a very old decserver 200 with LAT 5.1.

Read this :

Before LAT Version 5.2, LAT allowed only one outstanding message at a time on a virtual circuit. This could limit the performance of large access servers. For example, only one Ethernet packet of data could be in transit at a time. With LAT Version 5.2, nodes can indicate that they are willing to receive more than one message at a time. During virtual circuit startup, each side communicates to the other how many outstanding messages it is willing to accept.

Wim

[Jon Pinkley]

Nigel,

You have told use the VAX is connecting to a piece of test equipment via an RS232 interface on the test equipment.

What was the reason for replacing the TTA connection with LAT?

If it was because you need test equipment in a location that has only ethernet connectivity to the VAX, and you want to approach the latency characteristics of a direct RS232 connection, you will need to consider something other than LAT (at least with timers supported by the terminal servers I am aware of). With a timer of 20ms, you will be limited to 50 timeouts per second, and if your "packets" are small, that is going to limit your effective characters per second.

I would expect telnet to provide a lower end-to-end delay than LAT. This assumes you have a TCP/IP stack on the VAX, which you may not, and terminal servers that support TCP/IP (the DS200 does not). Also, a host initiated telnet session is not as straightforward as a host initiated LAT connection, at least in my opinion.

You also don't say if this is a prototype for a large deployment, or if this is a one-time event.

For a one-time event, to minimize the engineering development, you may want to consider something that will allow a longer distance RS232 connection, as in a "short haul modem".

If you are going to deploy many of these, where you can spread the cost of the development over a wider base, then I would at least consider using a PC near the test equipment as a "middle man", and communicate with the PC via a network protocol like IP sockets, and from the PC to the test equipment with RS232. The PC could then handle the low-level communication protocol with the test equipment, and the network could pass the higher-level "commands" and data transfer.

Jon

[John Gillings]

Nigel,

LAT is a dead protocol. Years ago when the network world was (truly) local area networks connecting VMS hosts with serial terminals, with a few serial printers scattered around, LAT was KING, but those days are long gone.

Yes, I know there are lots of sites still using it, but there has been no engineering effort on LAT for at least a decade, and it's unlikely there will be any in the future. As others have pointed out, LAT is non-routable, which imposes some very serious limits on where you can use it, and how you can configure your network (just say "LAT" to any switch, router or bridge manufacturer and stand back for the tirade!).

Rather than using LAT, try configuring your terminal server to use TCPIP (if it's capable? - if not, pick up a slightly more recent model from a scrap heap somewhere).

Compare the performance using telnet. Note that from the user's perspective there's no significant difference between LAT and TCPIP, but from a network management point of view having a single protocol makes life much simpler.

[labadie_1]

A sidenote: I like to connect twice, one with Lat and the other with IP or Decnet.
Lat is the first protocol to fail, so when my Lat session is disconnected, I know that we have some network problems. IP and Decnet are more resilients.

[Nigel Wright_1]

Many thanks again for all the replies.

The reason we choose LAT is that we have it enabled here and we also have the hardware.

It is only this time issue which is causing a problem.

As for using old technology; reliablilty and repeatablilty are more important to us, than using the the most upto date protocol.

We do use PCs as suggested they access VMS files via Pathworks to run the tests on the cards, but the VAX is the only hardware FLIGHT QUALIFIED to run the final tests - they have to be run in the end on the VAX.

Not sure at all how to configure the equivilant of set host /dte lta801: in TCPIP that points to a DECServer that is communicating via TCPIP?

Before we explore this route can anyone advise how this works comapred to the LAT method?

The question was asked about if it was development ect. We use it for both development and final testing.

Many Thanks Nigel.

[Karl Rohwedder]

Nigel,

we use the attached DCL Routine to create TNA-ports on IP-based terminalservers to connect BDE-terminals.

To connect your terminal to such a beast just do a TELNET node port.

regards Kalle

[Nigel Wright_1]

>>We use the attached DCL Routine to create TNA-ports on IP-based terminalservers to connect BDE-terminals.<<

Sorry can't see the attached file.

Nigel.

[Wim Van den Wyngaert]

Don't agree with labadie.

If we have network problems, it's most often routing problems. And which one always works ? Yes ... LAT (the dead one).

In 10 years had not 1 failure.

Wim

[Karl Rohwedder]

Opps, I have no problem reading/downloading it.

Beside parameterchecking ... the essence is:

TELNET /CREATE /PROTOCOL=NONE /TIMEOUT=(NOIDLE,RECONNECTION=00:00:05) -
'server 'port' 'line'
e.g. SERVER 2012 998

regards Kalle