|
|
|
| PCANDIS - PCAMPR
|
 | Packet Loss - The primary measure of performance for a packet collection driver is "packet loss". Better performance simply means fewer lost packets. |
| CPU Usage - It is essential that the packet collection process
should be as efficient
as possible. For sure, operation of the packet collection system must not
consume
system resources to the point that software that uses the collected packets
cannot
operate. |
Rawether V5.02.15.53 introduces a new "multi-packet read" NDIS protocol driver. The new PCAMPR driver is not intended to be a replacement for the existing PCANDIS protocol driver. Instead, it is an alternative driver to be considered for demanding situations.
Our measurements indicate that the new PCAMPR NDIS protocol driver has the
capability
to support operation on 1000Mbps Gigabit Ethernet in demanding situations. Out
test
facilities are not sufficient to provide an estimate of the upper limit of its
ability,
but it should easily reach 500Mbps sustained operation and hopefully further.
Here are the key differences between the original PCANDIS driver and the new
PCAMPR driver:
| PCANDIS "Single-Packet Read" Driver - This driver supports multiple
concurrent single-packet reads.
|
In contrast, the new PCAMPR driver fills a large buffer with data from
multiple packets
and passes the multi-packet buffer to the user-mode application when it is
filled.
| PCAMPR "Multi-Packet Read" Driver - This driver supports multiple
concurrent multi-packet reads.
|
The important difference is that there are far fewer kernel-to-user transitions using the PCAMPR driver.
The test bed that was used for these measurements is built from off-the-shelf Windows workstations and readily available network components. Although the test bed is not capable of fully saturating a 1 Gbps network, it does stress the workstations and network sufficiently to gain insight into the performance that is achievable.
The testbed consisted of two HP workstations connected via a 1000Mbps switch:
| Test Item | Description | Network Hardware |
| TCP Transmitter "HP9870" |
HP Pavilion 9870 Single 1.3GHz P4, 128 MB |
LinkSys EG1032 Instant Gigabit Network Adapter, 32-bit PCI |
| 1000 Mbps Switch | LinkSys EG0008 | 10/100/1000 8-Port GigaSwitch Full Duplex |
| TCP Receiver "TwoEye1000" |
HP Visualize P-Class Dual 1GHz PIII, 256 MB |
NetGear GA622T 100/1000 Copper Gigabit Ethernet Card, 64-bit PCI |
TCP Transmitter/Receiver Test Software
The test used the well-known "Test TCP" (TTCP) socket application originally developed for the Unix platform. The test used PCAUSA's "PCATTCP" port of TTCP to the Windows platform. Source and executables for PCATTCP can be found at the PCAUSA Test TCP(TTCP) Utility web page.
For some tests PCATTCP was modified to allow the transmitter to run continuously instead of stopping after a specified number of transmitted buffers.
Rawether Test Software
The Rawether software that was used for the test consisted of the following:
| PCANDIS Driver Test - Was performed using the HookPeek Packet Monitoring Application. |
| PCAMPR Driver Test - Was performed using the MPRead Packet Monitoring Application. |
The tests were performed using the V5.02.15.53 versions of these applications.
The Rawether test software is run on the TCP Receiver workstation, a dual 1GHx PIII workstation.
The Rawether packet monitoring application is run in the "quiet" mode. This means that individual packets are not displayed on the console as they are received. Instead, statistics are displayed at 10-second intervals.
For this test the PCATTCP transmitter is setup to send 16,384 buffers that are 8,192 bytes in length. A total of 134,217,728 bytes of TCP data is sent for each test.
At then end of each test the PCATTCP and Rawether packet monitoring application output is saved.
Here is a summary of the test results for this initial comparison test between the PCANDIS and PCAMPR drivers:
| Driver | TCP Throughput KB/sec |
NDIS Throughput KB/sec |
Packet Frequency Pkt/sec |
Packet Loss |
| PCANDIS | 14,558 | 8,780 | 9,110 | 1,894 Packets |
| PCAMPR | 23,084 | 11,848 | 12,288 | zero (0) packets |
Note 1: The NDIS throughput is lower then the TCP throughput because the Rawether application was started before the TCP transmitter and was stopped after the TCP transmissions were finished.
The primary result of interest is that the PCANDIS driver did drop 1,894 packets during this test and the PCAMPR driver did not drop any packets.
A second point of interest is that the TCP throughput was actually higher during the PCAMPR test. This is because the TCP receiver and the Rawether packet monitoring application were both running on the same workstation. Because of the increased efficiency of the PCAMPR driver the receiver workstation was able to accept data at a higher rate.
The CPU utilization when testing the PCAMPR driver ranged between 25% and 35% throughout these tests. Understand that the test host was concurrently running both the TTCP receiver Winsock application and the MPRead packet collection application. CPU utilization ranged between 15% and 25% with the TTCP receiver alone. This indicates that the PCAMPR driver and MPRead application were using less then 15% of the CPU resource.
These tests were performed on a local network using a MTU of 1500 bytes.
The design of a multi-buffered NDIS protocol driver is relatively insensitive to decreasing the MTU (i.e., smaller packet sizes). For the same throughput, as packet size decreases the packet frequency increases. However, since the throughput rate is constant the rate that the driver buffers are filled remains (roughly) constant.
Looking for a moment at the detailed PCAMPR test data:
Ave RxByte Rate: 14218105; Ave RxPkt Rate: 14746; Ave RxBuf Rate: 229
If the RxByte rate was (somehow) kept at 1,421,805 bytes/second while the MTU was decreased by a factor of ten(100) to about 150 bytes, the RxPkt rate would increase by a factor of ten(10) to about 147,460 packets/second.
However, since the RxByte rate (which determines how fast the packet buffers are filled) is constant the RxBuf rate would remain at a very low 229 buffers/second.
Since other tests show that the PCAMPR driver can operate at both higher throughput rates and much higher RxBuf rates, it is probable that the driver will perform well with smaller MTU. The throughput bottleneck will more likely be in components that must perform work on individual packets: the lower-level adapter and its driver or the higher-level application that is consuming the large buffers returned by the PCAMPR driver.
Here are the links to the test results details:
| PCANDIS/HookPeek Performance Test Results |
| PCAMPR/MPRead Performance Test Results |
Other tests were performed, and the results are included in the Rawether Guide help file that is provided with the product. None of these tests are sufficient to establish an upper performance limit on the PCAMPR driver.
| Continuous Operation Test |
| Higher Rx Buffer Frequency Test |
| Higher Byte Transfer Rate Test - Received packet rate over 40K packets/second. |
Mailing Lists ·
PCAUSA Newsletter
·
PCAUSA Discussion List
|
