USB High Speed EHCI (2.0) Interface Performance Tests (Compact 2013)
3/26/2014
The USB Performance Test measures host-side and device-side performance at the bus level in order to debug general performance issues. The tests include several modes that allow the user to narrow down possible issues. The USB performance test performs transfers at the lowest level of the bus, allowing tracking of performance issues in the bus driver itself.
Test Prerequisites
Your device must meet the following requirements before you run this test.
The USB Performance Test requires two platform devices. One device acts as the USB host under test, while the second acts as a USB function device. The USB function device that has been tested is a CEPC with a NetChip NET2280 USB function card, but can be any platform supporting USB function that has the appropriate drivers supplied.
The following table shows the hardware required for the USB Performance Test.
Requirement |
Description |
|---|---|
USB Host Device Under Test |
Host platform under test containing either a host controller card or an on-board host controller. |
USB Function Device |
This test has been verified using a CEPC with a NetChip NET2280 USB function card. However, you can use another platform (or another instance of the same platform) as the USB function device, if the required USB function drivers are available. |
USB cable |
Required for setting up the test. |
The following table shows the software required on the HOST device for the USB Performance Test.
When run through the CTK (Test Kit), performance data graphs are made available as part of the results. To enable this graphable output, ceperf.dll, perfscenario.dll and guidgenerator.dll will need to be available. Because the test is a kernel-mode test, ceperf.dll must be included in the image itself (setting IMGCEPERF=1 in the project build options) or available in the release (or an alternate release) directory prior to boot. If ceperf.dll fails to load once in a process, it will not try again for that process (in this case NK.exe).
Requirements |
Description |
|---|---|
Tux.exe |
Tux test harness, required for test execution |
Kato.dll |
Kato logging engine, required for logging the test data |
Ktux.dll |
Kernel mode test utility |
ceperf.dll |
Performance test utility module (for graphable output) |
perfscenario.dll |
Performance test utility module (for graphable output) |
guidgenerator.dll |
Performance test utility module (for graphable output) |
Usbperf.dll |
Test module |
USB host controller driver |
USB support required (EHCI/OHCI/UHCI) |
The following table shows the software required on the FUNCTION device for the USB Performance Test.
Requirements |
Description |
|---|---|
Lufldrv.exe |
Tool that loads the loopback driver. |
LpBkPerfCfg.dll |
Configures a USB function controller that provides distinct allocation of endpoints and corresponding throughput, to allow maximum possible performance for USB 2.0 on the three types of pipes - Bulk, Interrupt and Isochronous. |
LpBkCfg1.dll |
Configures a USB function controller with six end-points in addition to end-point zero |
LpBkCfg2.dll |
Configures a USB function controller with four end-points in addition to end-point zero |
Net2280.dll |
Netchip NET2280 USB 2.0 function bus driver (assuming a CEPC with a NET2280 function card is used as the function device). |
The lufldrv.exe executable as well as the loopback configuration files can be found at the following default installation path: C:\Program Files\Windows Embedded Compact Test Kit\tests\target\<CPU>\.
Subtests
The table below lists the subtests included in this test.
SubTest ID |
Description |
|---|---|
1001-1037 |
Normal Performance Tests. The tests submit all buffers to the host driver in a tight loop, provide a callback pointer to a completion routine, set USB_NO_WAIT flag (in the case of asynchronous completion tests), then wait for a certain period of time for all transfers to complete. There are six categories of transfer type: * Bulk pipe loopback tests, asynchronous return from the driver with USB_NO_WAIT set (tests case IDs: xxx1) * Interrupt pipe loopback tests, asynchronous return from the driver with USB_NO_WAIT set (tests case IDs: xxx2) * Isochronous pipe loopback tests, asynchronous return from the driver with USB_NO_WAIT set (ltest case IDs: xxx3) * Bulk pipe loopback tests, synchronous return from the driver (ltest case IDs: xxx5) * Interrupt pipe loopback tests, synchronous return from the driver (ltest case IDs: xxx6) * Isochronous pipe loopback tests, synchronous return from the driver (test case IDs: xxx7) IN and OUT transfers are exercised independently: * IN transfer test cases are numbered xx1x or xx3x. * OUT transfer test cases are numbered xx0x or xx2x. |
1101-1137 8101-8137 |
Full Queue Performance Test This type of transfer is typical for streaming applications, where a new transfer is issued as the previous one completes (form of double-buffering). A callback pointer is provided and USB_NO_WAIT flag is set. The first few buffers are submitted "at-once", then the transfer mode changes. Subsequent buffers are submitted to the queue from within the completion callback. Test cases 8xxx use physical memory instead of virtual memory. |
1203-1737 8203-8737 |
Isochronous Microframe Performance Test The error level in isochronous transfers can be reduced if higher micro-frame frequency is used. A streaming application which needs high quality may modify this factor. Microframe divisors of 1, 2, 4 and 8 are employed: * 2x microfame rate test cases are numbered x2xx or x3xx * 4x microframe rate test cases are numbered x4xx or x5xx * 8x microframe rate test cases are numbered x6xx or x7xx Two sub-groups - "All-Buffers-At-Once" and "Full Queue" are also tested here: * All-Buffers-At-Once test cases are numbered x2xx or x4xx or x6xx * Full Queue test cases are numbered x3xx or x5xx or x7xx Test cases 8xxx use physical memory instead of virtual memory. |
15001-36311 |
Additional performance tests with emphasis on measuring performance on either host or function side. In this scenario either host side or function side will issue a large transfer equivalent to total data transfer for the test, and other side will perform transfers at the various block sizes. This allows for a more accurate measurement of performance on the side where the various transfers occur as a function of the payload size specified, as there is no queuing delay from its counterpart. This test will measure performance for the bulk category of transfers. The variations are as follows, where the five-digit test case number is represented as LMNPx. Transfer time calculation (Lxxxx): * L = 1 for host side calculation * L = 2 for device side calculation * L = 3 for a synchronized calculation that takes place on both sides Blocking side (xMxxx): * M = 5 for host side blocking * M = 6 for device side blocking Physical memory usage (xxNxx): * N = 1 for host side use of physical memory * N = 2 for device side use * N = 3 for both side use IN or OUT transfers (xxxPx): * P = 0 for OUT transfer * P = 1 for IN transfer |
Setting Up the Test
This test has no additional requirements, beyond the standard test environment setup.
Running the Test
Setting up the USB Performance Test requires downloading images to both the function and host devices, executing command lines on each, and when prompted, connecting the host to the function with a USB cable. Do not connect the USB cable until prompted by the test.
1. Download run-time images to both host and function devices. Two instances of Platform Builder will be required to do this, however both instances of Platform Builder can be hosted on the same PC. Do not connect the devices to each other with the USB cable at this time.
2. On the function device, start the loopback driver (ex. s lufldrv.exe -p) with options to suit your testing purposes. See the table below for common testing scenarios.
3. On the function device, use "gi mod" to verify that "LpBkPerfCfg.dll" (or the desired loopback configuration module) is loaded.
4. On the host device, launch the test by running the command "s tux -o -n -d usbperf.dll". See the table below for the command-line to use for full-speed performance testing.
5. When prompted by the host device, connect the host and function devices with a USB cable.
The same basic procedure is used for a variety of different configurations (high-speed/full-speed/composite, etc). The following table shows which commands to execute for the most common test scenarios.
|
FUNCTION-SIDE COMMAND |
HOST-SIDE COMMAND |
|---|---|---|
High Speed [EHCI(2.0)] |
s lufldrv.exe -p |
s tux -o -n -d usbperf.dll |
High Speed [EHCI(2.0)], composite config |
s lufldrv.exe -p -c |
s tux -o -n -d usbperf.dll |
Full Speed [OHCI(1.1)/UHCI(1.0)] |
s lufldrv.exe -f |
s tux -o -n -d usbperf.dll -x 1001-1003,1011-1013,15001-36311 |
Full Speed [OHCI(1.1)/UHCI(1.0)], composite config |
s lufldrv.exe -f -c |
s tux -o -n -d usbperf.dll -x 1001-1003,1011-1013,15001-36311 |
Note: To enable testing against a composite function, ensure that the USB function device image is built with the following SYSGEN set: SYSGEN_USBFN_COMPOSITE=1.
It is possible to alter the functionality of the test using command-line parameters. On the FUNCTION device side, the command line parameters to lufldrv.exe allow you to configure the loopback driver. Sample usage: "s lufldrv.exe -f -c"
Command-line parameter |
Description |
|---|---|
lufldrv.exe |
Loads the specified loop-back configuration driver. |
-p |
Specifies that lufldrv.exe loads the Loop-back Perf Configuration driver, LpBkPerfCfg.dll. Use this option only for high-speed (USB 2.0) testing. |
-1 |
Specifies that lufldrv.exe loads the Loop-back Configuration #1 driver, LpBkCfg1.dll. |
-2 |
Specifies that lufldrv.exe loads the Loop-back Configuration #2 driver, LpBkCfg2.dll. |
-3 |
Specifies that lufldrv.exe loads the custom loop-back driver you created: LpBkCfgNew.dll. For more information about creating a custom loop-back configuration driver, see the "USB High Speed EHCI (2.0) Interface Regular Packet Size Test" documentation. |
-f |
Causes the device to operate at full-speed, rather than at the default high-speed. |
For further USB Host Performance test coverage, consider adding the following scenarios to your testing matrix:
* Execute the performance tests through a USB hub.
* Execute the host tests using a full-speed reflector (s lufldrv -f) against a high-speed host. If full-speed and high-speed host controller drivers reside on the same device, executing the test against a full-speed reflector will cause a handoff from the high-speed to full-speed host controller driver. If no full-speed driver is available, the test will need to take place through a hub. This latter scenario is the so-called "golden bridge" test, and is the only scenario in which a USB 2.0 host-controller performs split transfers.
Verifying the Test
When the test completes running, verify that "PASSED" appears in the test log for all sub-tests.
Troubleshooting the Test
* Observe the debug output for failures. If source code is available, attempt to pinpoint the source of the error.
* On some platforms, you may encounter a limitation with regard to the amount of physical memory allocated for your host controller. This may cause memory problems when you run these tests. To correct this situation, increase the value for gcTotalAvailablePhysicalMemory in the appropriate system.c file that corresponds to your host-controller driver.
* For graphable perfscenario-formatted .xml output, ensure that ceperf.dll is included in your run-time image (set IMGCEPERF=1 in the project build options), or is available in the release (or an alternate release) directory prior to boot.