Improving WiFi Performance

Many things affect WiFi testing. Here are some suggestions for improving throughput.

• Tweak Antenna Positioning
  Antenna configuration has a huge impact on WiFi throughput, especially when using 802.11n. A good starting point is to have two antenna parallel, and the third perpendicular to the other two. You can also try rotating the AP and/or LANforge WiFi box so that the chassis do not block the signals. For maximum throughput, ensure there are no objects between the AP and LANforge box.
• Use Attenuators when using SMA cables.
  If you are using SMA cables instead of antennas to connect LANforge to a network-under-test, you should have about 30db of attenuation added to the cable. This can be done with a programmable attenuator or a much cheaper fixed attenuator module. Performance is quite bad if you do not have this attenuation in place because the signal is too strong for the NIC's receiver logic.
• Increase TCP Send/Receive Buffer Sizes.
  The kernel defaults do not perform well in our testing. Use the Advanced button in the Layer-3 Modify window to configure the send and receive buffers. Our testing shows that 2MB-4MB send and receive-buffer size is often optimal for high-speed TCP and UDP connections.
• Increase LANforge Payload (PDU) Sizes.
  By default, LANforge will use a 1024 byte payload. This often leads to smaller than MTU sized packets on the wire, which decreases over-all throughput. For UDP, try using PDU size of 1472. On most networks, this means one LANforge PDU will use exactly one MTU sized packet. On weaker systems such as the Atom based CT520, you will get better performance setting UDP PDU size to something larger like 24000. For TCP, try 64000 or some other larger value. TCP will create MTU sized packets on the network automatically, and doing larger write sizes means less CPU work on the LANforge.
• Use fixed-rate LANforge traffic.
  Setting the Max rate to larger than the minimum rate will cause LANforge to randomly change it's TX rate between those ranges. This is perfectly legal, but it may decrease performance, especially with TCP traffic. This is due to the underlying TCP protocol algorithms. So, just set the Max value to 'Same' and adjust the Minimum value to the requested rate.
• Be careful of bi-directional trffic.
  WiFi is a half-duplex environment: Only one station or AP can transmit at a time on a particular channel. This means that bi-directional traffic (sending and receive lots of packets on a station) decreases total bandwidth. Station-to-station traffic is especially stressful for WiFi, as each packet goes over the network twice (LANforge -> AP -> LANforge). This does not mean it is wrong to generate bi-directional traffic, but just be aware that the traffic will not run as fast in this scenario. Using pure download or upload (Wired to Station, or Station to Wired) traffic often performs best, and many commercial APs appear to be optimized for download (Wired to Station) direction.
• Upload v/s Download.
  When sending Upload traffic (from Station towards AP), LANforge will normally be limitted by the amount of data the station interfaces can transmit. The operating system will apply back-pressure up the stack and LANforge will be slowed down appropriately without dropping many packets.

  For download (Wired to Station), LANforge may be able to send at or near full line rate. For UDP especially, this can overload the AP with more frames than it can process causing excessive loss and decreased overall performance. We see best results when LANforge is being asked to transmit just slightly more than the system-under-test can handle.

• Layer-3 Multi-conn feature.
  The LANforge Layer-3 protocol has a 'Multi-Conn' feature that allows LANforge to create a stand-alone process that handles all traffic for that endpoint. First, this can improve CPU utilization since these processes will be able to run concurrently on multi-core CPU systems.

  For TCP, a second improvement may be seen as you increase the multi-conn value since it will create duplicate TCP streams. This often helps smooth out TCP traffic since if one connection slows down due to some dropped frames, the other connections may be able to continue at optimal speed. A good suggested value is to set the A side to 10 and B side to 1 (for B side, anything greater than zero is treated the same way..it is the A side that originates the multiple connections.)

  Recent testing has shown that Multi-Conn is not always an improvement. We are investigating this further.

• NAT and Firewall on AP.
  NAT and firewall options may decrease and AP's performance. You could try using the AP in bridge mode or as a simple router if you believe this is the case. When NAT is enabled, make sure that the 'B' side of the LANforge cross-connect is on the wired LANforge port. The B side acts as the server, so this will emulate a client connecting to the internet. LANforge UDP traffic may work only in the upload direction when the AP is using NAT (this depends on how smart the NAT logic is on the AP..good ones may allow bi-directional traffic.)
• Check Ethernet Port.
  Make sure the wired Ethernet port is running at full speed (1Gbps, Full Duplex for most LANforge WiFi systems). You should almost always configure LANforge to auto-negotiate the Ethernet link speed. You can check the link speed by double-clicking the Port row on the Port-Mgr tab and taking a look at the top of the window that pops up for the rate information. You may also check for CRC or other low-level packet errors reported in the table on the Port-Mgr screen. If you see excessive CRC errors, you may have a bad cable, bad network under test, or possibly bad LANforge NIC hardware.
• Check low-level Driver information.
  LANforge uses the ath9k WiFi driver/hardware for /a/b/g/n WiFi, and it offers many low-level details that can help a user figure out why performance is not meeting expectations. The first place to look is in the LANforge-GUI on the Port-Mgr tab. If you scroll to the right, you will find an Activity column. This reports the WiFi NIC's estimate of how busy the channel is. This includes all traffic detected on the current channel, so it takes non-LANforge machines into account. In our testing, we do not normally see activity go above 85%.

  The ath10k driver (a/b/g/n/AC) does not have as many diagnostics at this point.

  While you are looking at the Port Mgr tab, check the Retry counters. These indicate packets that could not be retransmitted. If these numbers are increasing steadily, the LANforge machine cannot send packets as fast as it wants to, for some reason (probably due to congested wifi network or poor signal/noise ratio).

  To get an even lower-level picture of the transmit queues, you can look at the driver debug files directly. Log into the LANforge machine as root, and run these commands:

  cd /debug/ieee80211/wiphy0/ath9k
  cat xmit
  

  There are lots of stats in this file, but for this case, the primary interest is the queue backlogs:

  txq-memory-address:   f5159c0c   f5159c90  f5159b88  f5159b04
  axq-qnum:                    2          3         1         0
  axq-depth:                   2          0         0         0
  axq-ampdu_depth:             2          0         0         0
  axq-stopped                  0          0         0         0
  tx-in-progress               0          0         0         0
  pending-frames              35          0         0         0
  txq_headidx:                 2          0         0         6
  txq_tailidx:                 2          0         0         6
  

  The system above is running as fast as it can on a very weak signal/noise ratio caused by our LANforge WiFi Attenuator. It has 35 packets in the driver transmit queues waiting to be transmitted. If you 'cat' this xmit file several times in a row and usually see pending-frames reported, then this indicates the NIC is transmitting as fast as it can. If you do NOT see any significant amounts of pending-frames, then the LANforge software (or perhaps TCP stack) is not sending packets at maximum speed. Using UDP may work around TCP retransmit issues and help keep the wifi network at maximum load. You may also need to tune the LANforge connections to use larger packet (PDU) sizes so that it is more efficient at sending data to the NIC.