Company Products/Technology Services News/Events Support Spacer Contact Partners Customers
English    日本語
Products Photo

Product Documentation for Enterprise-Managed AP

Documentation Home for Self-Managed and Enterprise-Managed APs | Evaluation Guide

Evaluation GuidePreviousNextIndex

 


Appendix C. Performance Tuning

This section describes how to create an evaluation and testing environment designed to obtain the best throughput performance results from your Devicescape Enterprise-Managed APs. Becoming familiar with these setup procedures and tests (and perhaps even repeating some of them in your own lab), will help you identify key factors that can impact performance and understand the most effective strategies for optimizing access point (AP) performance.

Information is provided on the importance of reducing obstructions to the radio frequency (RF) signal, creating clear, line-of-sight paths from APs to clients where possible, avoiding overlapping channels, and so forth. Also included are details on our own performance testing (with Iperf), and results we have obtained on various platforms (access points from different vendors). We also provide references to information on performance testing with NetIQ Chariot (in the section on Performance Testing Software).

RF Environment

Figure 11 Lab Setup for Performance Tests

For optimal over-the-air results:

  • The distance between the AP and the wireless client should be approximately 6 feet.
  • The alignment and position of omni-directional antennas should be: upright position (relative to the floor). For cardbus station cards; the cards should be positioned flat (parallel to the floor). This is done to avoid polarization issues.
  • AP omni-directional radio antennas should be placed approx 6 cm (0.2 ft) apart if antenna diversity is turned on.
  • There should always be a direct line-of-sight between the AP antennas and the client antennas.
  • The channels used for the test should be clean and non-overlapping. In IEEE 802.11g there are 3 non-overlapping channels 1,6, and 11. Even though these channels are non-overlapping, our internal testing has shown that depending on the RF filter implementation of the STA vendor, one might get significant leakage from the radio across the 802.11g band, which did significantly alter the results in some cases. Thus, for 802.11g testing, it is highly recommended that there be no activity or devices on any 802.11g channel except for the device under test (DUT).
  • Some suggested channels are shown in the following table.
    Radio Mode
    Channel
    IEEE 802.11g/b
    1
    IEEE 802.11a
    40
    Atheros IEEE 80211a Turbo 5GHz (static)
    42
    Atheros IEEE 802.11a Turbo 5GHz (turbo prime)
    40
  • The channels are checked to be completely free before and during the performance test. Nearby channels (up to channel 6 for 11g) are verified to be clean. These checks are performed with a wireless sniffer.

  • For 802.11g testing, all IEEE 802.11b stations in range must be switched off.
  • Required signal strength at the STA is verified to be atleast -44 dBm . In windows clients the signal strength is verified to be "Excellent" in the Windows ZeroConfig supplicant.
  • One needs to ensure that the throughput performance is in no way limited by the performance of the endpoints.

Test Setup Device Specification

The Wired Endpoint

Component
Description
PC
Dell™ PowerEdge™ 600SC (Pentium 4, 2.4GHz, 128MB memory)
Operating System
Microsoft Windows® XP operating system with Service Pack 1
Ethernet Card
The onboard card - Intel gigabit e1000

The Wireless Client Endpoint

Component
Description
Client PC
Dell™ PowerEdge™ 600SC (Pentium 4, 2.4GHz, 128MB memory)
Operating System
Microsoft Windows® XP operating system with Service Pack 1
Bridge

Software Used for Performance Testing

Client Drivers Software

The software versions of the drivers of the different wireless cards are the most recent versions available from the manufacturer.

Performance Testing Software

Purpose
Tool
Description
Traffic Generation and Performance Measurement
Iperf Version 1.7.0
NetIQ Chariot 5.0
Information about Iperf can be found at http://www.dast.nlanr.net/Projects/Iperf/. (This document focuses on using Iperf as the testing tool.)
Information about the NetIQ Chariot product can be found at http://www.netiq.com/products/chr/default.asp. If you go to the dowloads page, the trial download will default to version 5.0 or the latest version.
Details on peformance testing using Chariot are not included in this document. However, if you are a Wi-Fi Alliance member, you can access Wi-Fi alliance test plans (for IEEE 802.11b/g/a and so on) which provide thorough descriptions of performance testing with Chariot including command sequences, thresholds, expected results and so forth.
For more information, see the Wi-Fi Alliance Web site at http://www.wifialliance.com/.
Plotting and Graph Generation
Microsoft® Excel
Spreadsheet software.

Expected Results

Traffic direction is identified as either downstream (from AP to client station) or upstream (from client station to AP). In the tables below, downlink represents traffic flowing from the AP to the client station and uplink represents traffic flowing from the STA to the AP.

A test length of 60 seconds is recommended for optimal results. In some cases it takes the client station and the AP a few seconds (up to 10 secs in some cases) to reach a steady state.

If you are using Chariot, it is worth noting the difference between RTP and Iperf UDP.

Notes
Real-Time Transport Protocol (RTP) is an Internet protocol for transmitting real-time data like audio and video. It does not guarentee delivery but provides support mechanisms for the sending and receiving applications to enable streaming data. RTP typically runs on top of the UDP protocol, but can support other transport protocols as well.
User Datagram Protocol (UDP) is a connectionless protocol that runs on top of IP networks. UDP neither guarantees delivery nor does it require a connection. It is lightweight and efficient. All error processing and retransmission must be performed by the sending or receiving applications. It is used mainly for broadcasting messages over a network.

Iperf sends acknowledged UDP packets, and thus the maximum throughput achievable on the channel under test cannot be measured with Iperf. However, with Chariot, RTP is an unacknowledged UDP protocol, and thus with RTP one can measure the true maximum throughput in each direction.

Downlink (AP to Client Station)

Wireless Mode
Traffic Type
TCP
UDP
RTP
IEEE 802.11g/b
 
21
24
31
IEEE 802.11a
 
23
26
34
Atheros IEEE 80211a Turbo 5GHz (static)
 
28
31
42

Uplink (Client Station to AP)

Wireless Mode
Traffic Type
TCP
UDP
RTP
IEEE 802.11g/b
 
19
21
31
IEEE 802.11a
 
22
24
34
Atheros IEEE 80211a Turbo 5GHz (static)
 
27
28
42

Traffic Generator Parameters and Iperf Commands

To get a full list of Iperf commands and options, type "iperf -h" at the Iperf command line.

Some sample commands to generate traffic for testing are shown in the table below.

Component
Iperf Command
Server
iperf -s -u -i 1 -l 1470
This command starts the Iperf server using UDP packet with a packet length of 1470.
Client
iperf -c <serverIP> -i 1 -b 1000000000 -t 60 -l 1470 -f m
This command starts the Iperf client running against the Iperf server at a bandwidth of 1000 Megabits for 60 seconds with a packet length of 1470.

Evaluation GuidePreviousNextIndex