Ultrix 3.1 vs. LAT

[George Robbins]

In article <7432 at cbmvax.UUCP> grr at cbmvax.UUCP (George Robbins) writes:
> In article <7412 at cbmvax.UUCP> grr at cbmvax.UUCP (George Robbins) writes:
> > In article <7402 at cbmvax.UUCP> grr at cbmvax.UUCP (George Robbins) writes:
> > > In article <7399 at cbmvax.UUCP> grr at cbmvax.UUCP (George Robbins) writes:
> > > > Sigh...

Gee, only a compeat idiot would keep responding to his own articles...

Anyway, the status currently is that the Support Center is "working on"
resolving the problem with Ultrix engineering.  Rumor thru other paths
has it that some of the latest 3.0 patches need to be reworked for the
3.1 distribution.  It seems that it will be a week or two before any
real fixes surface.

While talking to the Support Center representative that's been handling
this problem with me, it became obvious the he was actually *very*
knowledgable about LAT and terminal servers in general.  It seems that
CSC is massivly commited to using servers and they had a lot of problems
getting everything working reliably.

We talked a while about LAT problems and what sort of problems seemed
to have shown up in the 2.x -> 3.0 change and whether these problems
might still be unresolved in 3.1 even after the (future) patches are
applied.  No real conclusions, but some intersting facts fell out that
are worth repeating.

1) If you are using DECSA's or the like make sure you have upgraded
   to the LAT 3.0 software release.  This fixes a number of problems
   that result in hangs or degraded performance after the server hasn't
   been rebooted in a while.  Anything 2.2 or older is likely to have
   a lot of problems.  DECserver 200's should be a current software
   release too, (I think it is 2.0) though this seemed to be less crucial.

2) The way servers/LAT works is that they accumulate characters and
   forward them every 80 milli-seconds.  They wait up to a second for
   acknowledgement from the host before retrying.  Buffers are of
   very finite size (~200 bytes on DS200), so that if you have network
   conditions resulting in long delays or retries, then you are going
   to see overruns on imcoming protocols that use large packets.

3) This has some consequences - protocols that use larger packet sizes
   or run in "blast" mode cannot be guaranteed to work under degraded
   network conditions at > ~200 char/sec _with_flow_control_disabled_.
   Large packet size Kermit and X-modem can run into problems here and
   something like Z-modem or sliding window protocols that always have
   more than one packet outstanding can lose big-time.

4) If this sort of thing is going on, then the server counters should
   be incrementing retrasmissions, duplicates or other errors at the
   same time the "overrun" erros are accumulating.

5) The 80 milli-second "circuit timer" is tuneable and it might make
   sense to reduce it in an environment where the server supports
   incoming high-speed tranfer in addition to manual input.  Obviously
   this increases network loading and host overhead, and it's not
   clear it fixes anything. 

6) It's also possible that other activity like incoming Trailblazer
   connections at 9600+ baud, may hammering the system hard enough
   that time spent at serial interrupt level processing to delay LAT
   responses.  If so, then one should be unable to duplicate the
   problems with the modems turned off and the system lightly loaded.

7) There's still no obvious reason why LAT performance/functionality
   should have changed between 2.X and 3.0.  The 3.0 LAT patches
   seem to represent fixes to things that were outright broken, rather
   than performance issues/parameter changes.

I've dug out my old 2.2 build pack to run some A/B tests in hopes of
pinning down something that works reliably under 2.2 and fails always
with 3.0.  This is a pain, since it seems that everybody has their
own private versions of [a-z]modem plus random terminal emulators/file
transfer programs on their personal systems.

-- 
George Robbins - now working for,	uucp: {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing	arpa: cbmvax!grr at uunet.uu.net
Commodore, Engineering Department	fone: 215-431-9255 (only by moonlite)