LAT drops info

[George Robbins]

In article <99 at fedeva.UUCP> bill at fedeva.UUCP (Bill Daniels) writes:
> Hardware: DECstation 5000, DECserver 300, Xyplex 5500
> Software: Ultrix 3.1D
> 
> We are running a test application on a DECstation 5000 using the built-in
> Thinwire port and terminal servers for serial output.  Our test application
> involves writing data to 32 terminal server ports which have their serial
> ports looped directly to another 32 terminal server ports which are read
> into a file.

I think you need to work with the understanding that LAT is input thruput
limited, determined by the amount of input buffering provided by the server
and the ethernet loading.  If you application can tolerate flow control,
either x-on/x-off or one of the "hardware" flavors supported by the terminal
server you may be able to work with this, otherwise it's basically open-loop.

It's also possible that the Xyplex server may have some other internal buffering
constraints such that it drops output packets if the input activity level is
high.  I'd do some cross-brand testing to investigate this.

You want to look very closely at whatever LAT/ethernet statistics the server
provides and how to interpret them.  The DECservers show input buffer overruns
as part of the port statistics, as if they were terminal errors - I don't know
how compatible the Xyplex stuff is.

You may want to evaluate a TCP server for this application - I'd expect loading
to be higher, but you might avoid the "terminal oriented" design that makes
LAT (alledgely) efficient, but also less general.

The DEC person who I talked to about this indicated that the DECserver 200's
had the least buffering per port, it's possible that newer servers and 3'rd
party servers are better or worse in this respect.

-- 
George Robbins - now working for,     uucp:   {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing:   domain: grr at cbmvax.commodore.com
Commodore, Engineering Department     phone:  215-431-9349 (only by moonlite)