Network Redirectors Revisited
by Stuart Baker
As usual, the annual Interchange meeting was very interesting and informative. I am already looking forward to Interchange 93 in Texas! My personal thanks to Ellen MacDonald and the executive committee for a job well done. Question, do computers in Texas have to run slower to keep pace with the drawl?
Networking was definitely the big topic at the Interchange 92 meeting. Every computer at the show was connected to the Ethernet. This years demonstration of network redirectors attracted a lot of attention. So again I am writing about a subject that is of interest to many of you.
It is hard to believe that it has been a full year since my first article on network redirectors. Within that year, I have gained a lot of experience with networks and network redirectors. This article will fill you in on our current network setup and bring everyone up to speed on this important topic.
At the end of my last network redirector performance article, I expressed concerns about the stability of the InstantCom//CS software. The problems that I encountered were never corrected and I feel that I can not recommend their product. Following the writing of that article, I discovered another network redirector product. In the intervening months, I have spent many hours working with the CROSS CONNECT product from Cross Communications Company. I have done extensive testing and have never encountered any system problems. The product is very resilient and is always available when I need it. At this time ALL connections to our OS/32 system and high speed modem are through the network and everything works great. It is really nice to find good reliable software.
Now lets get down to business. First, a quick refresher on PC communications. Since the introduction of the original IBM PC, it's ROM BIOS (Basic Input Output System) supported communications over serial ports through the use of INT 14. This basic support exists virtually unchanged in today's 486 machines (shall we call that a standard?). While this design was not suitable for high speed serial communications, it offered a common ground useful in communicating over networks. The BIOS performance is poor because it does not perform data buffering or use the serial port interrupts. Network redirectors overcome both of these problems.
In our office, our PC's are connected together with a Ethernet network. We share disks, a PostScript printer, streaming tape and 6 serial ports to an in-house 3212 system. Our network consists of four PCs and one 3212. One PC is a dedicated communications server and it does not even have a monitor or keyboard attached to it. The communications server has an Ethernet card for the network connection and an 8 Channel DigiBoard for connections to the OS/32 system. When the communications server is powered up, it connects to the network and creates 8 virtual serial ports (COMM01 through COMM08). For those of you that are visually orientated, refer to the following figure for a representation of the communications server connections.
Since the OS/32 system does not have any software support for standard PC based networks like Novell or LANtastic, connections must still be made using serial communications. Network redirectors and a communications server is your answer if you have a need to let users of PCs access your OS/32 system over a network. The server can have a pool of serial ports connected to your OS/32 system, allowing users from any PC on the network to access the OS/32 system as if they were directly connected. This eliminates the problem of running point to point serial connections from every PC, and reduces the number of serial ports required on your OS/32 system.
A network redirector is a TSR (Terminate and Stay Resident) program that intercepts the INT 14 request and performs the function for your program. The process is very similar OS/32's intercept function. This TSR effectively replaces the original ROM BIOS INT 14 support and simulates the original functions. In the case of an Ethernet network, characters that you type are placed into a packet and transmitted over the network. When a packet with data arrives, the characters are supplied to your program as if they had arrived over the serial port. In general, your program is not aware that the intercept is occurring. Because you are sending data over a high speed network, the problem of poor performance is eliminated. The data is buffered and error checked by the very nature of the network.
Our system uses CROSS CONNECT to access the serial ports at 19,200 bps. We have control over DTR (Data Terminal Ready) and can send a line break. Most network redirectors use INT 14 as the logical starting point for their support. Because of the limitations on the original INT 14 support, each network redirector extends the basic support to allow access to functions like sending a break and controlling signals like DTR. In addition, CROSS CONNECT allows you to select the specific virtual serial port you want. You can choose from any one of up to twenty ports. We utilize this feature by having a batch file called OS32 that automatically selects the first available port from COMM01 through COMM04. Another batch file called VCF makes the connection to the Virtual Console Facility. This means we can go to any PC on the network, type OS32 and voilą, we are connected. All this is accomplished with only one small Ethernet cable connecting the computers.
Your next question might be, what kind of performance can I expect accessing my OS/32 system over the network? The answer is, you would be hard pressed to look at someone using a PC and determine if they are directly connected or using the network! The remainder of this article will addresses the performance one can expect when using network redirectors to access an OS/32 system running MTM and Reliance. We will run two types of tests. One is a throughput measurement of the terminal emulation software and the other measures file transfer throughput. In both cases we will compare the results with a hard wired connection.
Before performance figures have meaning, one must define the hardware and software involved. I performed the tests using four PCs and an OS/32 system. The following describes the pertinent hardware and software.
PC System #1: (INT14)
PC System #2: (INT14)
PC System #3: (INT14)
PC System #4: (SERVER)
References to a direct connection refer to PC-Passport running on PC#1 using the Dell's serial port connected directly to the 3212. The direct connection tests were performed with the network software up and running in order to have the same system loading.
The network connection uses all five computers. The four PCs are linked together using LANtastic Ethernet. The LANtastic software provides a NETBIOS interface. The CROSS CONNECT software uses the NETBIOS interface and creates extended INT 14 support on PC#1 through PC#3 with its NETDEV program. On PC#4 the CROSS CONNECT MULTICOM software establishes a server to control the PC's 8 serial ports. Of these 8 ports, five are connected to the OS/32 system and one to a high speed modem. All connections are at 19,200 bits per second (bps).
Before getting down to actual numbers, I will discuss the general impressions received when running directly connected verses the network connection. To be honest, I was not able to determine the method used to access the system by visually observing the performance. I ran a variety of applications on MTM as well as Reliance, and could not see or feel any difference between the network and the direct connection. In Reliance, all of the screens snapped up very quickly. By all appearances, both methods of access were much quicker than the real 6312 terminal. I was able to send a break to stop a display files, I even had control over DTR to allow disconnecting a modem. I was not able to detect any delay in response at the keyboard. All in all, I was very impressed.
Now lets measure what the eye can't see. To determine the throughput of a 6312 terminal, I use a program called SCRNTEST. This program starts a timer and then outputs a continuous stream a data consisting of 10 full screens, ending with a "send status when ready" escape sequence. When the status is returned, the timer is read to calculate the actual bps rate achieved by the terminal. As long as there are no other users on the OS/32 system, the timing results are very consistent and accurate. Repeated tests on directly connected lines usually do not vary by more than two bps.
In the following discussion, I will use the directly connected PC-Passport as the basis of comparison. To define the baseline, I ran SCRNTEST against PC-Passport first. The measured throughput was 19,160 bps. Next, I ran SCRNTEST on a real 6312 terminal. The measured throughput was 14,670 bps. The real 6312 is 23% slower, that explains why the Reliance screens seemed a little snappier on PC-Passport.
Now for the real test, PC-Passport connected through the network redirector. The performance was extremely impressive, with the slower 386 (PC#2) achieving an average throughput of 18,913 bps! In this test, the network only slowed things down by about 1%! I did notice that the throughput results varied more than expected from one run to the next. To better determine the throughput, I ran the program 15 times. The minimum throughput was 18,842 and the maximum was 18,950, for a total delta of 108 bps. For those of you who are mathematically inclined, the following table presents the average speed and standard deviation for each PC alone and then all three at once.
When you look at the table you will notice some unusual results. The first is the rather large difference in standard deviation between PC#1 and PC#2. I expect the fact that PC#2 has a cache might account for the difference. The other notable difference is that the throughput of machine #2 and #3 increased slightly when all three PCs were running the test concurrently. I will not even attempt to explain the speed increase. What is illustrated is that the network has no trouble handling three ports all running continuously at 19,200 bps and should easily handle a lot more. Another interesting figure is the average throughput obtained by the IBM XT. It amazes me that the XT is capable of running on an Ethernet network in the first place, much less obtain performance figures of about half of the real 6312 terminal.
For the next test, let's perform a Xmodem file transfer. I chose a 403 KB ZIP file for this test. The throughput, when sending from the OS/32 system to the PC, was 15,028 bps over the network, compared with 17,280 bps on the direct line. This is slower than one would expect from the previous test. When sending the same file from the PC to the OS/32 system, the throughput dropped dramatically to 979 bps compared with 16,702 bps. That difference was much greater that expected. Again, I will not attempt to explain this variation, but I will be talking with Cross Communications to try and understand the slowdown. Hopefully something can be done to increase the throughput. I have my suspicions as to the cause of the slowdown, but further investigation is warranted before making any further statements.
As you can see from the above figures, network redirectors are capable of delivering impressive performance. Bear in mind, these tests were conducted under ideal conditions, no other users were on the test system. In real life, and with larger networks, I am sure you will experience more of an impact on performance using a network redirector but I don't have a large enough network to slow things down.
I have worked with all of the software used in this test on a daily bases. The LANtastic network has performed flawlessly, regardless of how heavily loaded it was. The CROSS CONNECT product has also performed admirably. I highly recommend all of these products.
Well that about does it for this issue. I am looking forward Interchange 93. Start making your plans early so we have a good turnout.
The software products and interface cards mentioned in this article are available from the following companies:
MS-DOS V 5.0
LANtastic Network Operating System V 4.10
CROSS CONNECT Version 4.0
DigiCHANNEL PC/8 - 16550 UARTs
This SBSW.COM page has been optimized for printing.