From:	SMTP%"Info-VAX-Request@Mvb.Saic.Com" 15-SEP-1994 08:39:25.88
To:	EVERHART
CC:	
Subj:	Re: RE: Info needed on LAT circuit timer

From: raspuzzi@mrlat.enet.dec.com (Michael D. Raspuzzi)
X-Newsgroups: comp.os.vms
Subject: Re: RE: Info needed on LAT circuit timer
Date: 14 SEP 94 22:09:11
Organization: Digital Equipment Corporation
Lines: 56
Message-Id: <358aur$4rm@mrnews.mro.dec.com>
Nntp-Posting-Host: mrlat.enet.dec.com
To: Info-VAX@Mvb.Saic.Com
X-Gateway-Source-Info: USENET


In article <9409140309.AA15731@uu3.psi.com>, Jerry Leichter <leichter@lrw.com> writes...
>
> [...]
>
>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.

This is true for 99% of the terminal servers but it is not true for X
terminals.  LAT has a negotiation scheme at virtual circuit startup between
master and slave that allows either side to use a transmit window that is
greater than 1.

For VMS, it will allow a VXT to use up to 10 messages in a row without
acknowledgement.  These 10 messages could conceivably come out of the VXT back
to back if there was enough data to send to the host that would consume all 10
messages (assuming credit availability).  This is also true for VMS to VMS SET
HOST /LAT connections - a transmit window is negotiated so the master can
pipeline multiple messages when it has large volumes of data.

When a LAT X session is run, their can be large amounts of data going in either
direction from time to time.  Because LAT is timer based and the VXT runs a
circuit timer (default 30ms) it was noticed that this can sometimes cause undo
delays with X applications.  So, the VXT can 'cheat' the circuit timer if the X
event that causes data to be sent from VXT to host requires a response (i.e. it
is considered a roundtrip piece of information).  In this case, the VXT will
cheat its circuit timer and transmit a message to the host at the next 10ms
clock tick of its CPU.

Thus, the upper limit on the amount of data going in any one direction (master
to slave or slave to master) is a function of the negotiated circuit transmit
window and the number of credits available on any particular sessions(s) that
have data available.  Because the host allows the VXT to use a transmit window
of 10 messages, it extends 60+ credits per session (assuming a large amount of
data, 6 credits would be consumed 1 message).

With all that said, there was a problem in earlier versions of LTDRIVER where
it would try and pipeline many small messages instead of aggregating data in a
few large messages.  This can make a congested bridging problem go from bad to
worse to almost impossible to keep a virtual circuit up.

If you are running OpenVMS VAX V5.5 (or V5.5-1, V5.5-1), I suggest you get
CSCPAT_0511 V3.6 (any version of LTDRIVER V6.0-405 or higher) to try and see if
this helps cut down on circuit timeouts caused by bridge congestion.  I believe
there is a comparable kit for OpenVMS VAX V6.0 as well (CSCPAT_0579 maybe?) and
the V6.0-405 dirver logic for bridge congestion is contained in OpenVMS VAX
V6.1.

I believe this fix was in OpenVMS AXP V1.5 and higher.

--
Mike Raspuzzi (raspuzzi@mrlat.enet.dec.com)
Digital Equipment Corporation