bill@fedeva.UUCP (Bill Daniels) (05/30/90)
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. There is a process for each of the write tasks and a process
for each of the read tasks for a total of 64 processing writing and reading
as fast as possible. Things begin to slow considerably on the DS5000 during
the test. The read processes put the correct number of bytes into the data
files when running to the DECservers MOST OF THE TIME BUT NOT ALL OF THE
TIME. The read processes never put the correct number of bytes into the
data files when running to the Xyplex servers (8-port cards in a rack). This
data loss seems to be load related because running fewer ports (32, 16, 8)
provides NO data loss. During the 64 port test to the DECserver 300, the
DS5000 reports approx. 9000 frames received and 9000 frames transmitted over
the course of 150 seconds or so using "lcp -c". The same command run after
a test of the 8-port cards in the Xyplex rack reports approximately 17,000
frames.
Is there a buffer associated with "lta" that may be getting overrun? This
seems to be implied by the Xyplex servers with lower port density using
more frames and more data loss. If there is a buffer that is getting
overrun, what can be done about it? What is a reasonable number of bytes
and packets to expect LAT to handle correctly under Ultrix?
HELP ME PLEASE!!!
bd
--
bill daniels
federal express, memphis, tn
{hplabs!csun,mit-eddie!premise}!fedeva!billgrr@cbmvax.commodore.com (George Robbins) (05/30/90)
In article <99@fedeva.UUCP> bill@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@cbmvax.commodore.com Commodore, Engineering Department phone: 215-431-9349 (only by moonlite)
thomas@mipsbx.nac.dec.com (Matt Thomas) (05/30/90)
> 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. There is a process for each of the write tasks and a process > for each of the read tasks for a total of 64 processing writing and reading > as fast as possible. Things begin to slow considerably on the DS5000 during > the test. The read processes put the correct number of bytes into the data > files when running to the DECservers MOST OF THE TIME BUT NOT ALL OF THE > TIME. You really haven't given enough information to determine the problem. How do the programs set up the ports? What speed are the ports set to? etc. Without that I can't begin to tell you where you're problem may lie though I can probably guess. > The read processes never put the correct number of bytes into the > data files when running to the Xyplex servers (8-port cards in a rack). This > data loss seems to be load related because running fewer ports (32, 16, 8) > provides NO data loss. During the 64 port test to the DECserver 300, the > DS5000 reports approx. 9000 frames received and 9000 frames transmitted over > the course of 150 seconds or so using "lcp -c". The same command run after > a test of the 8-port cards in the Xyplex rack reports approximately 17,000 > frames. I've never used Xyplex server so I can't say how good/bad their LAT implementation is. The frame count does seem excessive but that might be just ineffeciency on their part with no protocol violations. Note that if Xyplex is less efficient than that means ULTRIX must process more LAT messagess per character (than compared to a DECserver) which would result in less overall throughput (and more data overruns). > Is there a buffer associated with "lta" that may be getting overrun? This > seems to be implied by the Xyplex servers with lower port density using > more frames and more data loss. If there is a buffer that is getting > overrun, what can be done about it? What is a reasonable number of bytes > and packets to expect LAT to handle correctly under Ultrix? If flow-control is used then you should never run see data overruns. If flow control is not being used then you will varying amounts of data overruns. There are no ways to eliminate them. -- Matt Thomas Internet: thomas@wrl.dec.com DECnet-ULTRIX Development UUCP: ...!decwrl!thomas Digital Equipment Corporation Disclaimer: This message reflects my own Littleton, MA warped views, etc.
ix@cosmo.UUCP (Redaktion ix) (06/04/90)
Reading your question I like to aks you for more information. We got some terminal-servers, which works with TCP/IP and LAT. The troubles are, that there are no German autors, which are able to test this cards with LAT, so the review, we'll publish, will only describe the perfomance under TCP/IP. I would be gradeful recieving an answer. ys Ralph Huelsenbusch
ix@cosmo.UUCP (Redaktion ix) (06/04/90)
We still searching for authors for our magazin. We got some terminalservers for TCP/IP an LAT. The problem is, that there are only TCP/IP users here, so we need informations about LAT. ys Ralph Huelsenbusch
ix@cosmo.UUCP (Redaktion ix) (06/04/90)
We are still searching for writers, which are able to work with LAT. We got some terminalservers for TCP/IP and LAT. Teh problem is, that we couldn't find an author, wo is able to work with LAT. ys Ralph Huelsenbusch