I used two applications during testing, Zap and Chariot. These examine UDP and TCP packet performance, respectively. You don’t see UDP tested very often. Everybody simply loads up Chariot or iPerf, does some time tests, and that’s about it. For conventional file transfers and similar everyday tasks, this is an appropriate methodology. However, UDP is what you use for streaming video. It’s a faster protocol because the server system doesn’t have to sit around waiting for receipt confirmation from the client. With UDP, you simply blast out a stream of high-speed packets and hope they get to their destination, come what may.
You’ve probably never heard of Zap because Ruckus developed it in-house for testing video streaming performance. To the best of my knowledge, this is the first extensive use of the tool in a mainstream review. As it was, I was sworn to not let the application out of my sight, so apologies in advance for not making it available to readers.
With that said, there’s no dark magic to Zap. It simply takes a reference load of data and sends it between the server and client using UDP. The transfer is divided into percentages of the total work load, with each step being one-tenth of a percent. At each step, throughput rate is recorded and the number shown by the software is the lowest packet speed recorded up to that point in the transfer job. This is why Zap numbers look really fast at 1%, average at 50%, and very slow at 99 percent.
For our purposes, we’re most interested in the average and lowest numbers. When it comes to video, you don’t care what the fastest or average sustained rates are. You care about the slowest speeds, the weakest link in the wireless chain, because this will be the key factor in determining your video-watching experience. If you sustain a 70 Mbps connection 95% of the time but occasionally drop to 15 Mbps for whatever reason, then those drops are going to translate into dropped frames and hiccups if you’re watching an HD stream with a 19.2 Mbps data rate. You can see a real-world example of this in the chart shown here, which (spoiler alert!) is the Chariot throughput data for Cisco’s 1142 access point at short range.
As mentioned previously, many things can impact wireless throughput, including the orientation of the client. There are three antennas in most 802.11n-equipped laptops, and in three dimensions these work (once again) a lot like rabbit ears. So I actually ran each test four times, rotating the laptop a quarter-turn for each test. The results were then averaged together.
Additionally, since each access point has the ability to run at either 2.4 or 5 GHz, I ran all tests on both radio bands. It’s possible for a client that associates on one band to hop to the other if conditions deteriorate, but it’s not common. Client sessions tend to stay loyal to whichever band they first associate with. Hence it’s important to get a good idea of how both bands perform.
Not least of all, I made sure that power management in the Intel client driver was set to “highest.” Otherwise, when running on battery power, performance can be more prone to fluctuation. If you’re curious, that command line business sitting under the driver window shown here is Zap at rest.
- Open-Mouthed Amazement
- Beamforming Basics
- Inside On-Chip Phased Arrays
- The Client That Could Be
- On-Chip Challenges
- Ruckus And On-Antenna Phased Arrays
- Can You Hear Me Now?
- Test Gear: Ruckus 7962
- Test Gear: Cisco Aironet 1142 And Aruba AP125
- Test Environment
- Test Apps And Methods
- Zap In 2.4 GHz, Average
- Zap In 5 GHz, Average
- Zap At 2.4 And 5 GHz, Minimum
- Chariot At 2.4 GHz
- Chariot At 5 GHz
- Angelini Weighs In On Beamforming At Home