NDIS 6 Performance Test (Compact 2013)

Artículo
03/28/2014

3/26/2014

The Network Driver Interface Specification 6 (NDIS 6) Performance Test is a performance test to send and receive throughput of the network using NDISv6 based driver. You can also use the NDIS 6 Performance Test to assess send and receive throughput of a network interface for a Windows-based desktop OS. This test gives you the raw speed at the NDIS level for your NDIS/RNDIS miniport. It is intended to be used only for performance investigations; there is no pass/fail result.

You can use the NDIS 6 Performance Test to perform the following tasks:

* Compare the send and receive throughput of a network interface at the NDIS level to the send and receive throughput at the Winsock level.

For more information about the Winsock Performance Test, see Winsock Performance Test.

* For a specified network interface, compare the send and receive throughput at the NDIS level in Windows Embedded Compact to the throughput in a Windows-based desktop OS.

* Find a performance bottleneck in a miniport driver or in NDIS.

Test Prerequisites

Your device must meet the following requirements before you run this test.

The following table shows the hardware requirements for the NDIS 6 Performance Test.

Requirement	Description
Windows Embedded Compact-based device with two network interfaces	A Windows Embedded Compact-based device with two network interfaces installed. One network interface is the interface for which performance is to be assessed. The second network interface is the interface over which the Windows Embedded Compact-based device communicates with the development workstation running Platform Builder for Windows Embedded Compact 2013 and the Windows Embedded Compact Test Kit (CTK). To monitor traffic on the test network with network monitoring software, you can install a second network interface on the development workstation and then connect the second network interface to the test network. The NDIS 6 Performance Test does not require a second network interface on the development workstation, but the second network interface can help you to troubleshoot problems that arise.
Supporting Windows-based desktop computer with one network interface	A Windows-based desktop computer that functions as a supporting desktop computer. You can use the development workstation on which Platform Builder is installed as the supporting desktop computer. On the supporting desktop computer, install a network interface that communicates with the tested network interface on the Windows Embedded Compact-based device. If the tested network interface for the Windows Embedded Compact-based device is wireless, the network interface for the supporting desktop computer must be wireless. The wireless interfaces must communicate via an access point. If the tested network interface for the Windows Embedded Compact-based device is an RNDIS interface, the interface for the supporting desktop computer must be an RNDIS host. If the tested network interface for the Windows Embedded Compact-based device is an Ethernet interface, connect the Ethernet interface to a switch to which you also connect the Ethernet interface for the supporting desktop computer. If the tested interface is a 100-megabits per second (Mbps) adapter, use a 100-Mbps switch and use a 100-Mbps adapter for the supporting desktop computer. If the supporting desktop computer is the development workstation on which the CTK runs, install two network interfaces on the development workstation. One network interface is the supporting network interface that communicates with the Windows Embedded Compact-based device. The second network interface is the interface over which Platform Builder and the CTK communicate with the Windows Embedded Compact-based device.

Windows Embedded Compact-based device with two network interfaces

A Windows Embedded Compact-based device with two network interfaces installed. One network interface is the interface for which performance is to be assessed. The second network interface is the interface over which the Windows Embedded Compact-based device communicates with the development workstation running Platform Builder for Windows Embedded Compact 2013 and the Windows Embedded Compact Test Kit (CTK). To monitor traffic on the test network with network monitoring software, you can install a second network interface on the development workstation and then connect the second network interface to the test network. The NDIS 6 Performance Test does not require a second network interface on the development workstation, but the second network interface can help you to troubleshoot problems that arise.

Supporting Windows-based desktop computer with one network interface

A Windows-based desktop computer that functions as a supporting desktop computer. You can use the development workstation on which Platform Builder is installed as the supporting desktop computer. On the supporting desktop computer, install a network interface that communicates with the tested network interface on the Windows Embedded Compact-based device. If the tested network interface for the Windows Embedded Compact-based device is wireless, the network interface for the supporting desktop computer must be wireless. The wireless interfaces must communicate via an access point. If the tested network interface for the Windows Embedded Compact-based device is an RNDIS interface, the interface for the supporting desktop computer must be an RNDIS host. If the tested network interface for the Windows Embedded Compact-based device is an Ethernet interface, connect the Ethernet interface to a switch to which you also connect the Ethernet interface for the supporting desktop computer. If the tested interface is a 100-megabits per second (Mbps) adapter, use a 100-Mbps switch and use a 100-Mbps adapter for the supporting desktop computer. If the supporting desktop computer is the development workstation on which the CTK runs, install two network interfaces on the development workstation. One network interface is the supporting network interface that communicates with the Windows Embedded Compact-based device. The second network interface is the interface over which Platform Builder and the CTK communicate with the Windows Embedded Compact-based device.

The following tables show the software requirements for the NDIS 6 Performance Test on the Windows Embedded Compact-based device.

Requirement	Description
Tux.exe	Tux test harness, required for test execution
Kato.dll	Kato logging engine, required for logging test data
Ndp6.dll	MS_NDP 6 protocol driver
perf_ndis6.dll	Test library

The following tables show the software requirements for the NDIS 6 Performance Test on the supporting desktop computer.

Requirement	Description
Tux.exe	Tux test harness for desktop, required for test execution
Kato.dll	Kato logging engine, required for logging test data
perf_ndis6.dll	Test library for desktop
Ndp6.sys	File for MS_NDP 6 protocol driver for desktop
Ndp6.inf	File for MS_NDP 6 protocol driver for desktop
snetcfg.exe	Desktop utility to install or uninstall the MS_NDP 6 protocol driver

Subtests

This test has no subtests.

Setting Up the Test

On the supporting desktop computer, you must install the MS_NDP 6 protocol driver. You must also determine the bind name of the network interface for the supporting desktop computer.

How to install the MS_NDP 6 protocol driver on the supporting desktop computer:

1. Create a directory, and then copy to that directory the following files from <CTK installation root>\Program Files\Windows Embedded Compact Test Kit\tests\target\NT):

* Perf_ndis6.dll

* Ndp6.sys

* Ndp6.pdb

* Ndp6.inf

* Snetcfg.exe

2. To the directory that you created, copy the following files from <CTK installation root>\Program Files\Windows Embedded Compact Test Kit\harnesses\target\NT:

* Tux.exe

* Kato.dll

3. In the directory that you created, run the following command:

snetcfg -v -l .\ndp6.inf -c p -i ms_ndp

4. Run the following command to verify that the MS_NDP 6 protocol driver is installed:

snetcfg -v -q ms_ndp

How to uninstall the MS_NDP 6 protocol driver from the supporting desktop computer:

1. In the directory that you created that contains the Snetcfg.exe file, run the following command:

snetcfg -u ms_ndp

Finding Names for a Network Interface:

If the network interface for the tested Windows Embedded Compact-based device is a wireless network interface and behaves as an access point (AP), the network interface for the supporting desktop computer must be a wireless network interface. Configure the wireless network interface for the supporting desktop computer to start in ad hoc network mode.

If the network interface for the tested Windows Embedded Compact-based device acts as an AP, associate the network interface for the supporting desktop computer with the AP. Verify that no other wireless client connects to the AP.

1. To find the display name of the network interface for the supporting desktop computer

a. From the Start menu, choose Control Panel.

b. If Control Panel is set to Category View, choose Network and Internet Connections.

c. Choose Network Connections.

d. From the View menu, choose Details.

e. For the network connection, note the value under Device Name.

2. To find the bind name of the network interface for the supporting desktop computer

a. From a command prompt, navigate to the directory that you created that contains the files for the NDIS Performance Test.

b. Run the following command: tux -o -d perf_ndis6.dll -c "-enum"

c. From the list of network interfaces, note the bind name of the network interface whose display name matches the device name displayed in Network Connections of Control Panel. The bind name has the format \Device\{GUID}.

Note: Make sure the desktop computer does not have security policies enabled. For example, do not use the in-domain machine when the domain has security policies enabled). The firewall should also be disabled.

Running the Test

You must run the NDIS 6 Performance Test on both the Windows Embedded Compact device that you want to test and on a supporting desktop computer that the device communicates with.

Important:Do not run this test on the VMINI network interface. It is intended for an installed network card, not a virtual network interface.

To run the NDIS6 Performance Test on the supporting desktop computer

1. Set up the supporting desktop computer to run the NDIS 6 Performance Test. See Setting Up the Test section.

2. Navigate to the directory that you created that contains the Perf_ndis6.dll file, and then run the following command, where \Device\{GUID} is the bind name of the network interface on the supporting desktop computer:

tux -o -d perf_ndis6 -c "-ndisd -ip [YourIPAddr] -port [PortNumber] \Device\{GUID}"

e.g. tux -o -d perf_ndis6 -c "-ndisd -ip 172.23.168.185 -port 10001 \Device\{C09ECA87-B4A9-4E59-BF5D-54F02E7758C6}"

On the supporting desktop computer, the NDIS6 Performance Test displays its output in the command window.

To run the NDIS Performance Test on the Windows Embedded Compact-based device

1. Build a run-time image with support for the network interfaces that you want to test.

2. Download the run-time image to the target device, and then verify that the network interfaces for the target device are functional.

3. Connect the Windows Embedded Compact Test Kit (CTK) to the target device.

4. Run the NDIS6 Performance Test without modifying the command line to determine the device name of the network interface to test. The log file generated by the test shows the device names of all network interfaces recognized by the target device.

5. In the test's property window in the CTK application, modify the command line for the NDIS 6 Performance Test to specify the device name of the network interface to test.

For example, to test send throughput for a network interface with the device name PCI\NE20001, specify the following command line:

tux -o -d perf_ndis6 -c "-mode send -ip 172.23.168.185 -port 10001 -wsock -s PCI\NE20001"

6. Run the NDIS 6 Performance Test

Command Line Parameters for the NDIS 6 Performance Test

You can modify the behavior of the NDIS Performance Test by editing the Current Command Line field in the test's properties window. To specify one or more of the following optional command-line parameters for this test, use the -c command-line parameter. The -c parameter forces Tux to pass the specified string into the test module.

The following table shows the command-line parameter options for the NDIS 6 Performance Test

Command Line Parameter	Description
-ip	(Required) IP address of the adapter on the other side of the network connection.
-port	(Required) Port on which backchannel traffic should go.
-<?\|help>	Displays a list of command-line parameters for the test.
-enum	Enumerates all network adapters present and displays information about each adapter.
-mode <send\|recv>	Specifies whether to test send throughput or receive throughput.
-wsock [-hsize n]	Runs the test in the same way as the Winsock Performance Test. The value n is the total header size. The default value for n is 40+14. For TCP, n=54. For UDP, n=42.
-ndisd	Runs the test in the role of supporting desktop computer.
-s	Locates and then uses the supporting desktop computer.
-v n	Specifies logging verbosity on a scale of 0 to 15. A value of 0 specifies minimum verbosity and a value of 15 specifies maximum verbosity. The default value is 10.
-packets n	Specifies the number of packets to send. The default value is 10000.
-size n	Specifies the size of each packet. If you specify this parameter, the test ignores the -min, -max, and -step parameters.
-min n	Specifies a minimum packet size. The default value is 64.
-max n	Specifies a maximum packet size. The default value is 1514.
-step n	Specifies the increment in packet size. The default value is 64.
-pool n	Specifies the number of packets in the pool of packets to use in the test. The default value is 64.
-nounbind	Disables unbinding of other protocol drivers from the tested adapter before the test is run.
-apacketsend	Uses the NdisSend function instead of the NdisSendPackets function for send operations.
-ubdelay n	Specifies the length of the delay after protocol unbinding. The default value is 1000 milliseconds (ms).

Verifying the Test

The send and receive test transmits packets in increasing sizes from the device to the desktop, slowing down the transmission until all packets are received for a certain size. When the test completes, the result will show in output window. If ceperf/perfscenario modules are available in release folder, it will create a CePerf log file, perf_ndis6.xml.

The "Sent" line will always report that all packets were sent: there is no way to accurately count the number of packets sent since NDIS does not indicate failure on a per packet basis but rather on a per NetBufferList basis.

The Mbps received during the send test should steadily increase with increase in packet size. For an Ethernet miniport, the speed usually goes from approximately 10 Mbps to approximately 60 Mbps or more.

Your Wi-Fi miniport should send/receive all packets for each packet size eventually. If not, there is some performance problem with your send/receive logic.

Both tests print out a summary of the performance achieved while transmitting all packets across. Note that this is a coarse-grained measure - the test does not account for how many packets were received while slowing down the transmission. So if 9995 out of 10000 packets were received, the test will still slow down the send side, possibly by a much larger amount than necessary to get the 10000 packets across thus resulting in a depressed send perf number. You should be able to check the logs to see if your actual perf is better than what the summary table shows.

This test is meant only to investigate the results of the Winsock performance test.

Troubleshooting the Test

If you find that the performance numbers are lower than expected, try the following to find the root cause of the issue:

1. First, use the -packets and -size parameters to narrow down the test to the scenario you want to debug. For example, if you find that large packet receive performance is bad, then you can run on the device with:

-mode recv -packets 1000 -size 1514

2. Collect CePerf information for a performance run with these parameters.

* Look at the CePerf information in remote kernel tracker: see if you are doing excessive thread switching, have lock convoys, or some other issue like that.

* If you ran this test because you have poor Winsock receive performance, but found that the NDIS performance numbers are acceptable, then that means that the TCP/IP layer is not emptying buffers as fast as NDIS is filling them, and packets are getting lost.

* To confirm this, you can run perf_winsock2 test (Winsock Performance Test) but progressively increase the priority of the perf_winsock2 receive thread and see if that improves your Winsock performance.

Compartir a través de