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!bill
grr@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.