Partager via

Troubleshooting the Winsock Performance Test (Windows Embedded CE 6.0)

  • Article

1/6/2010

This section describes problems that might be experienced with the Winsock Performance Test. For more troubleshooting help, see Troubleshooting the CETK Tests.

Problem Description Resolution

Winsock Performance Test Does Not Run

When you use Tux.exe to run the Perf_winsock2.dll client, an error message appears containing the text Unable to import Library.

This error occurs if a file required by the Winsock Performance Test is not present on the target device with the Perf_winsock2.dll client.

Before you run the Winsock Performance Test, verify that all required files are in the release directory or in the same directory on the target device as the Perf_winsock2.dll file.

Winsock Performance Test Does Not Provide Test Results

When you use Tux.exe to run the Perf_winsock2.dll client, an error message similar to the following error message appears:

Couldn't connect to server xxx.xxx.xxx.xxx

ConnectSocket() for control connection failed, WSAError=10038

Communication between server and client failed; terminating test

This error occurs if communication between the client and server cannot be initiated. Verify that Perf_winsockd2.exe is running on the server. Verify that the server has the IP address specified in the error message. If the server has a different IP address than the IP address specified in the error message, use the -s command line parameter to specify the correct server name or IP address.

Winsock Performance Test Shows UDP Packets Not Received

When you use the Winsock Performance Test to measure the performance of a gateway, UDP-related test cases including the UDP Ping test case indicate that packets fail to cross the gateway or indicate that the round trip time is zero.

The Winsock Performance Test relies on port numbers that are not translated. If a target device, such as a gateway, uses network address translation (NAT), a TCP or User Datagram Protocol (UDP) port on the private side of the gateway is translated when one of the following conditions is met:

  • Another client uses the port number for the port.
    To avoid conflicts with other clients, on the test network do not run anything other than the hardware and software required by the Winsock Performance Test.
  • The port number is outside of the range of port numbers that are not translated.
    For a Windows Embedded CE–based gateway, the default range of port numbers that are not translated is 1025 to 3000, inclusive. The Winsock Performance Test expects ports in the range of 1024 to 5000, inclusive, to be not translated. If you are testing a Windows Embedded CE–based gateway, use the following registry settings to extend the reserved port range.
    [HKEY_LOCAL_MACHINE\Comm\IPNat]
    "ReservedPortsStart"=DWORD:400
    "ReservedPortsEnd"=DWORD:1388

Winsock Performance Test Reports Packet Loss despite CPU Cycle Availability

Any of the UDP Receive tests report high packet loss, but CPU utilization is lower than 100%.

A bug in a miniport driver is likely to lead to this condition. Such a bug will often be echoed by low throughput figures seen in TCP send/receive tests, caused by many retransmissions in the network traffic for the test connection.

This may also arise when UDP socket buffer is not of sufficient size. In the UDP receive tests, the rate at which packets arrive at the miniport breaks down to a series of bursts with a delay between each burst. If the receiver cannot completely handle the packets arriving during a burst and its socket queue is not sufficiently large, then packets will be dropped. In this case, the low CPU utilization will be a result of only minimal work done to process small numbers of packets in the queue during the delay between each burst. To increase CPU utilization and increase the receive rate, the receive socket queue can be adjusted with the -q command line test parameter.

See Also

Other Resources

Winsock Performance Test