X25 Terminals

Jim Santmyer writes:- >From: jims@pdx.csd.mot.com (Jim Santmyer) > > I am working on a project where an informix database is located at a > central site running on a UNIX system V CPU and users are located at > remote sites using dumb ascii terminals over an X.25 network. We are > experiencing a severe network performance problem. > > Our communications hardware vendor tells us the reason for the > performance problem is that we are doing "Host echo" (the informix 4gl > application does the echoing). He continued to say that if the terminal > could be setup in block mode and do it's own echoing or if the local > X.25 hardware is configured to do echoing, we would eliminate at least > 50% of the network traffic, increasing performance significantly. (i.e. > when doing "host echo" every key stroke creates two network packets, one > to send the keystroke to the host and the second for the host to echo it > back to the terminal. If we can eliminate the need to do host echo and > perform local echo each keystroke creates at most one packet, thus > cutting network traffic by 50%, and if we can send a field of data to > the host at one time instead of each keystroke we cut down on network > packet over head even more.) > Jim Your problem is exactly the same as the one I had at my previous company. I'm afraid that i don't have solutions for your immdeiate questions but I do have some pointers for you. The problem arises because X25 was designed as a packet switching network for data transfer not for online data enquiry/update. As such it takes time and packets to transfer possibly only one character key presses. Our supplier told us that X25 would quite happily handle terminal traffic, which it did for those users where fast data entry was not an issue. They also told us that block transfers were much more efficient but as we used the network for a number of different applications such as uniplex we didn't have that option open to us. They did come in and tune the network for us. In X25 there are lots of things that can be tuned that might make performance bearable for your applications. (eg. Smaller packet sizes, Shorter time out time when packet transmitted if not full) these actually increase the number of packets but because of the nature of terminal interaction can make the system faster. Depending on your equipment there may be many more tuning facilities. We found that this satisfied all but our very heavy users. For these users we took a hardware solution instead of using an 8 port pad we used an 8 port mux into a single port pad at both ends. This effectively gives you the same performance as mux over leased phone lines and as the packets fill faster there is very little delay waiting for packet filling (Of course if only one user of the eight is working you can be back with the original problem - good tuning helps here). Some suppliers (We used CASE/DOUGHTY) are building X25 comms boxes now with muxes built in at the central location with direct outlet onto ethernet or whatever along with mux/pad combination boxes for the remote sites. The above solutions worked well for us and it saved us very expensive software changes and the application usage restrictions that using block mode transfer imposes. Hope this helps. Jim -------------------------------------------------------------------- Name: Jim Gordon Internet: jgordon@ssf-sys.DHL.COM Company: DHL Systems Inc Phone: (415) 358-5911 Address: 1700 S. Amphlett Blvd. Fax: (415) 571-6429 San Mateo, CA 94402 --------------------------------------------------------------------