How We Test Wireless Adapters & Bridges – Revision 2

Photo of author

Tim Higgins

Introduction

Since we introduced a new test process for wireless routers and access points using the new octoScope testbed, it’s time to update our process for testing wireless adapters and bridges.

Our method uses the setup shown in the block diagram below. As before, the reference router RF connection is cabled and the device under test is antenna-coupled to minimize path loss. Only three antennas are used normally; the unused fourth path is capped off on both ends. If 4×4 adapters appear, we will add a fourth antenna; the testbed is already set up with cabling and attenuator for a fourth RF path.

Wireless Adapter / Bridge Test Setup

Wireless Adapter / Bridge Test Setup

The Dell Optiplex 9010 Small Form Factor (SFF) computer hosting the DUT has USB 3.0 ports built in for adapter testing and a TP-LINK TG-3468 PCIe Gigabit Ethernet adapter has been added to connect to bridges under test. A Dell Optiplex 790 Small Form Factor computer hosts the IxChariot console and the endpoint that drives the ASUS RT-AC66U that remains as our reference router. Refer to the V2 testbed article for other hardware details.

Test Setup

Note: "Downlink" means data flows from router to client device. "Uplink" means data flows from client device to router.

All testing is done on the LAN side of the router so that the product’s routing performance does not affect performance results, i.e. the IxChariot endpoint computer is connected to a router LAN port.

The reference router is set as follows:

  • Router reset to factory defaults, 3.0.0.4.374_726 firmware
  • WPA2/AES security enabled
  • 2.4 GHz band: 20 MHz bandwidth mode, Channel 6
  • 5 GHz band: 40 MHz bandwidth mode for N devices, 80 MHz bandwidth mode for 802.11ac devices, Channel 153

Here is what the ASUS RT-AC66U looks like in the bottom test chamber.

ASUS RT-AC66U cable connected in lower Test Chamber

ASUS RT-AC66U cable connected in lower Test Chamber

Instead of moving antennas from top to bottom chamber as in the previous process, we move the DUT host computer. The wireless adapter / bridge under test (DUT) is placed into the upper test chamber along with the host computer.

The DUT is positioned with its front surface facing the chamber antennas and centered on the turntable. This puts about 18" between the DUT and chamber antennas. Due to the directional nature of client adapters, we don’t rotate the DUT during testing.

Upper test chamber with DUT and host computer

Upper test chamber with DUT and host computer

Test Process

The general test process is as follows:

  1. Check / update latest device drivers / firmware
  2. Associate DUT to reference router. Check connection link rate.
  3. Run IxChariot manual test to check throughput
  4. Run test script
  5. Power cycle DUT and reference router. Repeat steps 3-4.

Two test runs are made in each band for dual-band devices.

Testing is controlled by a Tcl script modified from a standard script supplied by octoScope. The script executes the following test plan:

  1. Program the attenuators to 0 dB
  2. Start 90 second IxChariot test (throughput.scr with 5,000,000 Byte test file size) simultaneous up and downlink (0 dB only)
  3. Wait for test to finish
  4. Discard first 30 seconds of IxChariot data, calculate average of remaining data and save to CSV file. Save entire IxChariot.tst file.
  5. Repeat Steps 2 to 4 for downlink only (DUT to STA)
  6. Repeat Steps 2 to 4 for uplink only (STA to DUT)
  7. Increase attenuators by 3dB.
  8. Repeat Steps 5 to 7 until attenuation reaches 45 dB for 5 GHz test; 63 dB for 2.4 GHz test or DUT disconnects.

Note that we continue to use the throughput.scr IxChariot script instead of the High_Performance_Throughput.scr script used by many product vendors.

The main difference is the high performance script uses a 10,000,000 Byte default test file size, Microsoft’s Overlapped IO socket and sets the transmit and receive buffer sizes to 64 K bytes. The regular throughput script doesn’t use Overlapped IO, leaves the transmit and receive buffers at default and a 100,000 Byte test file size.
We found in testing that using the throughput script and adjusting the file size upward actually produced slightly higher throughput than the high performance script.

The CSV files from the two test runs are merged into a single Excel file and the average of the two runs calculated. The average of the two runs is the value entered into the Charts database.

Related posts

Everything You Need To Know About Wireless Bridging and Repeating – Part 1: WDS

"How do I extend my wireless network range?" is one of the most-asked questions we get at SmallNetBuilder. The first article of this series looks at one of the primary techniques for WiFi range extension: WDS-based wireless repeating.