Sunday, 24 March 2013

Metageek Eye PA Review

I like pictures of stuff. Some people understand and learn more easily through hearing the spoken word, some through reading text and others prefer pictorial representations of ideas, concepts and information. For me, it's definitely pictures, which is why I love Metageek's Eye PA product. In this article, I take a look at the Eye PA wireless network analysis tool and talk about why I'm so enamored with this product.

If you're like me, one of the first things you do when visiting a new building, venue or customer site is to fire up your copy of Metageek's free (and incredibly useful) WiFi tool: inSSIDer. It's always interesting to see just how many SSIDs organisations are still trying to cram on to the 2.4GHz band or are perhaps creating themselves and their neighbors a whole heap of trouble by not using non-overlapping channels. Here's how things look for me, sat at home, as I write this article:

inSSIDer

However, I now have an additional habit when visiting a new site. In addition to firing up my copy of inSSIDer, I'm now also just as likely to fire up my latest purchase: Eye PA (also from Metageek).

Eye PA is a fantastic piece of software that allows you to to visualize what is happening on your wireless network. You simply take a network capture of wireless packets that can be heard over the air and Eye PA will summarize what is going on in a very flexible, graphically-rich style. With a few clicks, you can filter exactly what you are interested in and get incredible insights in to what is going on over the air.

I don't want to sound like a marketing brochure, so I'll explain precisely what's involved in acquiring wireless data from the network and then taking a look at what's going on.(Disclaimer: I've got nothing to do with Metageek at all, I'm simply a very happy customer).

To capture frames for analysis, you can use other tools such as Ominpeek or Wireshark, if you're so inclined, but I chose to purchase an AirPcap Nx card when I bought Eye PA. This allows me to capture traffic directly with the Eye PA application.

Once I've plugged AirPcap Nx card in to my (Windows) laptop, I simply fire up Eye PA, select the band and channel I want to use and hit the 'Start' button:

Data Capture in Eye PA
When I've captured for a while, I simply hit the 'Stop' button and Eye PA immediately starts crunching its way through the data it's collected. After a few seconds, I get  a summary of everything that Eye PA has captured, immediately giving me masses of information about what's going on around me. Here's an initial screen shot of what I saw when running Eye PA for this article:

Initial Analysis in Eye PA
At first glance, you may be a little confused by the visual onslaught, but after taking a few seconds to look around the screen, you can immediately pick out some incredibly valuable information.

Looking along the top panel of the screen-dump above, you immediately get an indication of the levels of air-time that are being used on this channel. Looking in the middle-right panel, you can see the number of BSSIDs and clients using the channel. In the lower-right panel you can see the SSIDs that can be heard, together with the numbers of clients, bytes, air-time, data rates and retry rates for each SSID.

Without even having seen this tool before, you can immediately gather some incredibly useful information!

But, when you turn your attention to the 3 colorful circles in the bottom left of the screen, you will start to see why I really love this product. As soon as I explain what the various colors mean in the 'Treepies' (those colorful circles), you'll see the genius of how the traffic on this wireless channel has been represented.

Each of the treepies is divided in to 4 concentric circles. The inner circle represents each SSID, the second inner circles represents the clients on each SSID, the 3rd circle shows the WiFi frame type, and the fourth (outer) frame represents the sub-type of WiFi frame.

Looking at the coloration seen in the outer 2 rings, you will see:

  • Shades of purple representing WiFi management frames
  • Shades of orange representing WiFi control frames 
  • Shades of blue representing WiFi data frames
 The inner  two rows of rings, representing SSIDs and associated clients are generally colored green.

Looking at our original capture summary, I hovered over each of the 4 rings in turn to show the information that can be seen at each level:

SSID Level

Client Level
WiFi Frame-Type Level
WiFi Frame WiFi Sub-frame Type
The other key aspect to this representation is the 3 ways that the data is represented. Wireless traffic data is shown by air-time (the largest treepie), together with the number of packets and number of bytes in the two, smaller accompanying treepies.

Notice that as I hovered over each section of data in the air-time treepie, the corresponding data was highlighted in the 'packets' and 'bytes' treepies too. Even in this simple example, you can see that even though the data frames took a relatively tiny amount of air-time, they also represented the bulk of the number of bytes sent over the air. This perfectly demonstrates the point that higher-speed data frames are far more efficient compared to their slower-speed management and control frame counter-parts. Being able to visualize this data provides you with invaluable insights, and would perhaps prompt you to consider disabling slower AP data rates to try to increase the speeds of your non-data frames and increase overall air-time efficiency.

What we've looked at here barely scratches the surface of what you can do with the treepie data, but hopefully you will get a feel for the intuitive and powerful way that the data is presented. As you might expect, you can click in to any treepie segment to drill down in to that data and focus  further on an area of interest. Here is a treepie where I had clicked on the top-level treepie segment for my own laptop:

Drill-down in to Client Treepie
You can now see just the frame-types used by my laptop during the time I captured frames for this article.

The ways you slice & dice and filter this information are endless, allowing you can drill in to precisely the information that you need.

Another great feature  is that once you have drilled down in to your area of interest, you can then take a high-level look at the actual packets that are creating the treepie data. Here is a filtered selection of management frames for my home SSID:

Management Frames for my SSID
The real killer feature (for me) is that you can then directly send the filtered selection you are looking at in to Wireshark, for more detailed analysis:

Send Selection to Wireshark
This might not sound like a 'killer' feature, but I was recently reviewing a wireless network capture. Using Eye PA to filter the traffic in a variety of ways and then sending it directly to Wireshark saved me a huge amount of time. Building the individual Wireshark filters to look at the data would have taken me a LOT of time. With just a few clicks in Eye PA, I was good to go each time.

In addition to the analysis capabilities I've discussed, Eye PA has also recently had a new feature added that provides even more value by providing recommendations for fixing network issues or risks. Here is a screen dump I took of what Eye PA came up with for my network:

Eye PA Analysis Suggestions
This is a new feature which, I have to admit, I haven't played with too much yet, but it looks to be giving some great advice from what I've seen so far.

Summary

Well, hopefully, I've been able to do this great product some justice and have provided you with a flavor of what it might be able to do for you.

For me, there have been a great many 'light bulb' moments whilst using this application. The powerful way that it visually represents what is happening on the network has been an incredible learning experience around how WiFi works. If you are trying to learn more about WiFi, you will gain an awful lot just from running the eval of this product. I'd read plenty about WiFi theory prior to using Eye PA, but seeing  the types, quantities and effects of each type of frame in the graphical manner that Eye PA provides has made many of the pieces I had read about fall in to place. If you are studying for any of the CWNP exams (particularly CWAP), you need to take a look at Eye PA.

In addition to the great educational value that it has provided Eye PA has also become one of the WiFi tools I wouldn't be without it. My must-have list of WiFi tools now consists of: a wireless survey tool, spectrum analysis tool, inSSIDer, Eye PA and Wireshark.

The other aspect to owning a copy of Eye PA is the support that you will get from the guys at Metageek. In addition to the product itself being invaluable (in my opinion), the support I've received from the guys at Metageek has been first class. They're a great bunch of guys providing timely support, great educational material and listening to suggestions for product improvements.

So, I'd strongly recommend you go out and get yourself an evaluation copy of Eye PA and have as much fun as I've had using it :)

Nigel.

Sunday, 10 March 2013

How Fast Is My iPad on WiFi?

I recently had an interesting customer WiFi performance issue to investigate which turned out to be a whole host of issues on the 2.4GHz band that he was using for his WiFi network. His issues were solved by moving his clients (iPads in this case) across to the 5GHz band, which instantly gave much higher throughput and reliability.

However, when he was testing his much-improved network by doing some throughput testing with an iperf server, I noted a sound of disappointment in his voice when he said that he couldn't get a throughput greater than 35Mbps on his iPad.I told him that this was, in  fact, as good as it was ever going to get when using an iPad, even with high performance 802.11n access points.

I thought it might be useful to have a look at what realistic throughput figures might be for an iPad on a WiFi network when using 802.11n access points, and why we hit much lower throughput figures than we might expect from the AP manufacturer data sheets.

I set up my home lab with a Cisco 2602 access point, an iPerf server and 2 iPads as shown below. The 2602 (at the time of writing is one of Cisco's flagship APs, boasting 3x4 MIMO with 3 spatial streams and a whopping 450mbps data rate.


I set the access point up to use both the 2.4Ghz (channel 11) and 5Ghz bands (channel 44). The 5GHz band was completely unused by any neighboring networks (according to inSSIDer). The 2.4Ghz channel had a couple of low-level neighboring SSIDs to compete/co-operate with. All-in-all, the environment what relatively 'clean' from an RF perspective, so there should be little variation due to RF factors during testing that might skew the results that I recorded.

The iPads were in very close proximity to the AP so that I would be able to provide 'best-case' results. The whole thrust of the testing was to provide the best possible results so that people looking at this article can see the maximum throughput they are likely to get on their network. In reality, with client devices at greater distances and with many clients on the wireless LAN, actual real-world throughput will vary enormously, but at least we have an upper-end benchmark to look at.

Background

I thought it might be worth spending a few moments looking at the factors that are going to potentially set us up for a more disappointing throughput than we might have hoped after investing in a top-of-the-range 'bells-and-whistles' access point.

In this article, we are looking at the Cisco 2602 access point which has a top 'speed' of 450mbps (megabits per second) according to its datasheet. If we are relatively new to WiFi, it might seem a reasonable assumption to expect our iPad to be able to shift data across the AP at 450mbps. Unfortunately, this isn't the case...

There are quite a few caveats to consider. 

The most important factor is the capabilities of the wireless client (an iPad in our case) to understand how 'fast' it might be able to go. This isn't just a straight understanding of the 'line speed' that its wireless chip-set can deliver, but more the wireless capabilities that it has. The 802.11n standard has a number of enhancements including support for multiple simultaneous streams of data and bonding WiFi channels together to increase throughput. 

Before 802.11n, APs and wireless clients could only transmit a single stream of data between themselves. With the advent of 802.11n, came the capability to transmit more than one stream of data at a time, through the application of some very fancy signal processing and additional antennas on APs and client. If two streams are supported, data rates double, with three streams they treble etc...I'm sure you get the idea.

Data has also traditionally been transmitted across a 20Mhz wide channel in the WiFi RF spectrum. 802.11n introduced the capability to take two 20Mhz channels and bond them together to form a single, double width 40Mhz channel to potentially double data speeds.

(Note: 40Mhz channels are generally not used on the 2.4Ghz band due to the lack of the availability of sufficient numbers of non-overlapping channels on this band)

The 450mbps throughput quoted in the data sheet assumes that 3 spatial streams are being used between the client and access point, and that a double-width 40MHz channel is being used. This is about as good as it gets currently for access points (until the advent of 802.11ac later this year...but that's another story).

Unfortunately, if the wireless client being used (in our case an iPad) supports only one spatial stream instead of 3, we are immediately down to a top speed of 150mbps (450/3) for our data. Also, if we cannot support the 40Mhz double-width WiFi channel, then we have to half our top-speed yet again. (150/2 = 75mbps).

So, we're now down to a (theoretical) top speed of 75mbps, but wait...there's more! (No, this isn't an infomercial). 

The 802.11 standard is based on a half-duplex communication technique - this means that only the client or the access point can be talking at any point in time. Many of the frames sent between an AP and client need to be explicitly  acknowledged. If a client sends a data frame to an access point, it will expect an acknowledgement from the AP to say that it has received that frame. Obviously, if only the AP or client can be talking, or is waiting for a response, this is going to dent our actual throughout again, as maybe up to half of their time may be spent waiting for responses.

There are various mechanisms within 802.11n to stop a clients throughput being cut in half by the acknowledgment mechanism. But, as a rule of thumb, you can reduce the expected throughput (due to the half duplex nature of WiFi) down to a little over half of the expected transmission speed. We'll be generous and not quite cut our 75mbps calculated speed in half. Let's call it 45mbps.

So, we've gone from a headline speed of 450mbps with our state-of-the-art access point to an far more modest 45mbps throughput speed for our wireless client (iPad). Reality just rained on our parade...

Just to re-cap, this assumption is based on the iPad being a single stream device using a single 20Mhz (standard width) channel.

In reality, things in practice actually get worse as the iPad moves further away from the AP and has to drop to lower speeds. Also, when other iPads are using the same AP, they are all contending for the same RF air-space/bandwidth as only one of them can talk at at time (very much like old-style Ethernet hubs). But, we don't want to get too depressed about how low our actual throughput might be, so lets move on to some testing.

Testing

The tests shown below have been carried out to try to get an indication of the top speeds we might see from our iPad on a WiFi network.

I've carried out the tests using an iPad2 and an iPad 4th generation, just to give some indication of the variation in performance between devices.

As they both support the 2.4Ghz and 5Ghz band, I've also tested them on both bands to see if there is any difference (which is again going to vary in the real world depending on the presence of neighboring networks on the same channels). We will generally expect the throughput to be slightly lower on 2.4Ghz due the higher proliferation of noise and interference (though this will vary from location to location).

As the 4th gen. iPad also supports 40Mhz (channel bonded) channels on 5Ghz, I also threw in a test to see the impact of a 40Mhz channel on the clients.

I ran each test individually on each iPad (i.e. it was the only one using the channel), as well as both iPads running simultaneously to see the effect of the two devices contending for the same air-time.

Individual iPad Test Results

The first set of test results are shown in the table below. In each instance, only one iPad was using the channel, running a 30 second iperf test. The test was run 3 times to ensure consistency and the average result of all 3 tests is shown to even things out.
  
Test #
Band
Channel Width
# iPads on channel
iPad Model
Throughput (mbps)





#1
#2
#3
Avg
1
5Ghz
20Mhz
1
iPad 4th Gen
45.6
44.49
46.25
45.4









2
5Ghz
20Mhz
1
iPad 2
34.8
36.2
36
35.7









3
2.4Ghz
20Mhz
1
iPad 4th Gen
39
39.4
41.4
39.9









4
2.4Ghz
20Mhz
1
iPad 2
33.6
33.6
33.2
33.5









5
5Ghz
40Mhz
1
iPad 4th Gen
74.4
74.9
74
74.4









6
5Ghz
40Mhz
1
iPad 2
35.8
36.1
35.7
35.9

The most striking feature of the results is the variation in performance between the 2 iPads. The 4th gen. iPad consistently had a (considerably) superior performance to the iPad 2. I checked to see if perhaps there were any other mechanisms which might be causing this (i.e. short guard interval) with an analyzer, but was unable to find any reason for this variation. I assume the 4th gen. is using a better chipset or better antennas or has a better RF design generally. Whatever the case, the 4th gen. came out with much better results.

Another interesting point observed in the results can be seen when using a 40Mhz channel. As we have previously discussed, if we use channel bonding to create a 40Mhz width channel, we should (theoretically) double our throughput speed. Looking at the 4th gen. iPad results, although we don't double our throughput speed, we get a massive increase in throughput (from 45mbps to 75mbps).

(Note: there is no improvement using a 40Mhz channel for the iPad 2, as it does not support 40Mhz channels/channel bonding so can never go beyond a 20Mhz channel width)

Simultaneous iPad Test Results

For this serious of tests, we fired up the iperf test on both iPads at the same time. This was purely to see the effect of two clients devices contending for the same channel (i.e. air-space) at the same time.

Test #
Band
Channel Width
# iPads on channel
iPad Model
Throughput (mbps)





#1
#2
#3
Avg
1
5Ghz
20Mhz
2
iPad 4th Gen
26.8
26.1
27
26.6




iPad 2
18.6
18.4
18.1
18.4









2
2.4Ghz
20Mhz
2
iPad 4th Gen
25.1
26.2
25.5
25.6




iPad 2
16.1
16.7
15.3
16.0









3
5Ghz
40Mhz
2
iPad 4th Gen
36.1
36.3
34.6
35.7




iPad 2
24.3
23.7
24
24.0


As expected, as WiFi is a contended medium (i.e. all stations have to wait their turn to talk over the air), then the throughput for each client device (iPad) was considerably reduced.

The difference in performance between the 2 iPads was still self-evident from these results (i.e. the 4th gen iPad performs much better than the iPad 2).

Interestingly, if the throughput of both devices are added together, they are approximately equal to the best throughput results observed in our first set of tests. This shows that the stations are having to share the available 'air-space' between themselves. We're not getting a reduction in the overall throughput over the air, but it is being shared (over time) by the stations.

One very interesting result is the 40Mhz channel width test (test #3). Although the iPad 2 does not support 40Mhz channels widths, it still benefits from the 40Mhz channel width being used - it's throughput improves compared to the 20Mhz tests. What's going on here?

My theory is that this is due to the 4th gen. iPad using the air-space more efficiently due to the higher speeds available to it. The 4th gen. iPad can get on to the wireless medium, send its data and then get off more quickly due to its higher throughput speed. This means that more air-time is available for the slower iPad 2, so that it can occupy the air-space for longer and shift more data. This is an interesting side-effect of using a 40Mhz channel that I had not anticipated.

Summary

Well, (hopefully) this has provided us with some useful figures when considering iPad throughput on WiFi.

It must be stressed that these figures are very much 'best case' and that in a real WiFi deployment where many clients are using the same network and are at varying distances from the AP, results will vary enormously from those shown here.

It's also been interesting to see the effect of multiple stations contending to use the same air-space, the effect of 40Mhz channels and why our actual throughput will never match the figures quoted by an AP manufacturer in the real world.

I hope the information presented is useful to you.