The Effect of LAN Driver Choice on Client Performance
Articles and Tips: article
Novell Systems Research
01 May 1996
Those who are working in a DOS/Windows environment with the 16-bit (NetWare DOS Requester) client typically have 16-bit network interface boards already installed in the workstations. If an upgrade to 32-bit network boards is planned, four viable upgrade options present themselves:
Upgrade to a full 32-bit client environment (NetWare Client 32 with 32-bit LAN drivers)
Upgrade to the 32-bit client but keep using 16-bit LAN drivers
Stay with the 16-bit client but upgrade to 32-bit LAN drivers
Stay with the 16-bit client software and 16-bit LAN drivers
Which option will offer better performance? Obviously, the full 32-bit client environment is the best alternative. But what if a 32-bit LAN driver is not available for your new network boards? Is it better to stay with the 16-bit client, or go ahead and upgrade to Client 32 and use a 16-bit LAN driver? Studies at Novell Systems Research have found several performance advantages associated with the "32-bit client in a 16-bit environment" model. Not only does the end-user see a 20 to 25% performance benefit, but server resource utilization is reduced when implementing Client 32 for DOS/Windows.
Rather than addressing every aspect of network performance associated with Client 32 and the DOS Requester, this NetNote will touch on some of the common issues faced in a networking environment: server CPU utilization, initial client lag time, and total time to perform a given task.
Imaging Test Bench
Since continual image retrievals is one of the fastest ways to tax a server or client, we decided on an imaging environment to test network performance. In our lab we set up 18 386/25 workstations to run our IMGTEST test bench (see LAN-based Imaging Tests Revisited" in the December 1995 AppNotes for details on this test bench). For the sake of comparison, we had two Pentium/100 machines running the same tests. All machines had 16-bit NE2000 network boards with NE2000 LAN drivers. Each machine was running MS DOS 6.22 and Windows 3.1.
The IMGTEST test bench consists of 200 image retrievals performed over a single LAN channel. In our comparative test runs, we performed four basic tests: 16-bit client with 16-bit drivers, 32-bit client with 32-bit drivers, 16-bit client with 32-bit drivers, and 32-bit client with 16-bit drivers (abbreviated 16/16, 32/32, 16/32, and 32/16, respectively).
Note: Although there is a caching option available with Client 32, we did not use this option in our testing, since the 200 files are retrieved in a steady stream without ever recalling the same file twice. Such a test to recall files from local cache will need to be performed in a future test. Yet even so, we observed about 20 to 25% better performance with Client 32 and 16-bit hardware than with the 16-bit client and LAN drivers.
Figures 1 through 4 show server CPU utilization for each of these test combinations. There is a slight server utilization improvement with the 32/32 client over the 16/16 client; however, by itself, this is not sufficient justification for switching to a 32/32 client system. Remember that in this scenario we are utilizing a 16-bit operating system (Windows 3.1) with 16-bit hardware on 386 machines. This architecture provides a stable foundation for the 32/32 and 16/16 client models.
According to the CPU utilization graphs on the 32/16 and 16/32 "hybrid" clients, the processes on the 32/16 client tend to be "tighter", or in more rapid succession. The two CPU graphs look similar, and the baseline in both cases average at about 20 percent server utilization.
The greatest difference is seen when comparing the "straight" client systems with the hybrid systems. Both the 32/32 and 16/16 graphs have baselines that linger around the 13 percent server utilization mark. This is not a significant increase. However, if you were to increase the number of workstations or processes taking place at the server, this slight difference would become a more predominant factor in your implemented networking system's performance.
Figure 5 shows the total time it took to complete the test bench. Overall, the 32/32 client model outperformed the others. Second to it was the 32/16 model, followed by the 16/16 and 16/32 models. This is additional justification for moving to the straight 32/32 model. However, one other issue must be addressed: the initial time from startup (initial lag). Lag time affects client loads, which slows down the overall completion time. Figure 6 shows lag time for our tests.
The initial lag for the 32/32 model was 21 seconds, as opposed to 19 seconds on the 16/16 model. The initial startup differences between the 16-bit and 32-bit client models is perhaps due to the conversion factor between the operating system and the client layers. The 16-bit client model tends to be slightly faster due to fact that it doesn't have to change the flow of data to the next "channel." It should also be noted that the 16/16 client model has been around for a while and has been optimized on a number of occasions, while the 32/32 client model has yet to be optimized. We must also remember that in both graphs these statistics are a result of averaged figures of all client workstations. Where one machine may do excessively well, another machine may lag due to internal factors.
Technical Background Information
To better understand these test results, it is helpful to understand the interplay between hardware and software in a client workstation. The function of a network board is to transfer packets of data from the board to the wire (and vice versa). The LAN driver transfers data packets from the board to the current application or process (and vice versa). A 16-bit network board can send and receive only 16 bits of data on the wire at any one time. Since the LAN driver communicates directly with the board, it is limited in the same fashion: a 16-bit LAN driver can only send 16 bits of data at a time to the board.
Although the network board is highly dependent on the LAN driver, there is some flexibility in choosing between a 16-bit and a 32-bit driver. For example, if you have a 16-bit NE2000 board, you can use either NE2000.COM (16-bit LAN driver) or CNE2000.LAN (32-bit LAN driver). Speed differentiation between the board and driver is not an issue. The reason is that the hardware and software work together to perform network processes, with each component performing exactly half of a full function (such as taking one command from a workstation and sending it to the wire). The hardware physically sends packets down the wire; the software translates the packets into usable pieces for the workstation.
Consider the case where you have a 32-bit LAN driver with a 16- bit board. Here, packets from the client are sent to the board 32 bits at a time. It is only when the packet is accepted by the board that the data is translated into 16 bits. The board then sends the data in 16-bit chunks out to the wire. The overall data round-trip time is slightly better because of the initial data being sent at 32 bits.
The operating system does have some say in the final translation of the information being distributed. However, that does not necessarily mean that the performance will be exactly the same for a 16-bit client as for a 32-bit client, given the same 16-bit operating system environment. The 32-bit client will initially feed 32 bits of data to the operating system. Thereafter, the information will be translated into 16-bit blocks. Since the data transfer is initially running in a true 32-bit mode, performance is slightly better. What is being utilized with Client 32 is the computer's ability to form packets and transfer data. Obviously, 32 bits will run significantly faster than 16 bits.
If you have a 32-bit board, you will want to use 32-bit LAN drivers. Saddling a 32-bit board with a 16-bit LAN driver decreases performance, and you would defeat your purpose in having purchased the 32-bit hardware.
In summary, the performance of a straight 16-bit client with 16-bit drivers on 16-bit hardware compared to a 32-bit client with 32-bit drivers on 16-bit hardware gives about a 20 to 25% improvement for the 32-bit technology. You will also see better performance with "straight" systems (16/16 or 32/32) than with hybrid systems (32/16 or 16/32). In fact, server resource usage (LAN channel throughput, disk I/O, and CPU utilization) is increased with a hybrid system. The end-user also sees a performance decrease in such areas as increased initial lag time and client response time. Based on our performance test results, the best option is to implement a straight 32-bit client with 32-bit drivers. Even in a 16-bit environment, using NetWare Client 32 offers performance benefits for both the client and the server.
* Originally published in Novell AppNotes
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.