To install the NDIS Netcard Driver Tester (TestProt), copy Nettpdrv.inf to the Inf subdirectory of your Windows directory, and copy the appropriate Tpdrvr.386 and Tpdrvr.sym to the System subdirectory of your Windows directory. Start Windows, and from the Network Control Panel, add the Microsoft NDIS Netcard Tester to your protocol list, binding it to the network card under test. Restart Windows, and Testprot will be ready to run.
This version of Testprot has been modified to meet the NDIS 3.1 addendum to the NDIS 3.0 spec, specifically to support the dynamic loading and unloading of media access control drivers. From the media access control developer's perspective, nothing has changed. This is a simple recompile of existing NDIS 3.0 sources with the new header files in this DDK. In addition, all NDIS function calls now use the standard calling convention, which is faster and allows binary compatibility with Windows NT 3.5 NDIS miniport drivers. The correct compiler flag to create standard calling convention components is included in the new Ndis.mk file.
The TestProt provided in this DDK may not fully support Arcnet or FDDI. The code is in, but has not been tested. TestProt also does not support QueryStatistics (which calls MacQueryGlobalStatistics). The test scripts included in this release contain support for this, but this support is disabled. This functionality will be provided in a future release.
For Token Ring testing, a cyclical test will require the packetsize variable be submitted as well. Current test functionality starts sending with packets set at the minimum packetsize, incrementing size by one up to packetsize. For Token Ring, packetsize is variable. Current scripts use 2028 as the max_frame_size, which is the minimum for the original IBM(r) 4MB Token Ring card. If the card under test has a different maximum packet size, set the max_frame_size accordingly. The corresponding log files will differ as well.
On Ethernet, one cyclical test will consist of 1459 packets. On Token Ring, one cyclical test will consist of 1987 packets (assuming a max_frame_size of 2028).
Stress testing in the TestProt environment can cause Windows 95 to do many strange things that are not real world. When running a test suite on a very fast computer, it is possible to get TestProt into a state that mimics driver failure. In any case where a script fails, rerun the specific failing script (for example, \1\2\3\1\5.tps) by itself after power cycling the computer. If the failure reproduces, then there is a genuine bug. In general, if TestProt crashes, Testprot.log and the Script.log files will probably be crosslinked. In these cases, run chkdsk to recover.
There is a new type of packetmakeup - ONE Buffer. A set of scripts can be created to add to the suite (window both on and off) that uses this, in order generate maximum stress on the card. For an example, using just such a stress test, the Ne3200.386 driver was able to peak out the theoretical maximum for Ethernet: 1000 packets/sec of 1514 bytes/packet.
When a stress test runs without the window on, the probability that one card may overflow the second card in the test increases. Use good judgment in choosing a set of cards for a given test. They should be matched for reasonably similar expected performance. If one card has a significant inherent architectural speed advantage, the other card in the test will be flooded and will not exercise good send/receive interaction. This is not poor design if the intent is to see how well a card performs under overwhelming stress. When packets are used from a pool, the throughput will increase as well. These factors will have an effect on the logs created, and they should be kept in mind when comparisons are drawn with the master logs.
Many of the speed differences between the Windows NT version of TestProt and the Windows 95 version are related to the Windows 95 version doing no memory allocations during the test if possible. Memory allocations are very expensive in Windows environments.
Because of the potentially large differences in expected and actual throughputs achieved by a card under test, the BETWEEN_VALUES parameters in the tps scripts may need to be modified. In general, for two evenly matched cards running without the window on and with packets from the pool, the second card (server in the stress test) should receive and echo back about 25 percent of all packets sent by the client. Likewise, when running the Acknowledgment (Ack) stress tests, the BETWEEN_VALUES may need to be examined to be sure that they are reasonable.