Saturday, January 30, 2016

Performance Testing A Wireless LAN

I have Ubiquiti wireless network gear on my 2.4GHz home WLAN. Recently, I opted to add one of their new Ubitquiti UAP-AC-LITE access points to provide a faster network path to better support running of Time Machine backups from my Macbooks to a new NAS I built (a story for another post).

This access point provides several nice features, including a wired gigabit connection and power over Ethernet.

This unit also provides a nice RF scan function that runs for about 5 minutes. Upon completion, it depicts the status of your RF environment so you can make informed choices about how you configure it. Below are the results of that scan for the area near my office.



RF Environment scan results for 5GHz spectrum in my office area

Based on those RF results, I've configured this access point to use a quiet 5GHz channel that is 80MHz wide to optimize throughput.

Often when one does an upgrade like this, it can be easy to accept any indicator of improvement as proof that the expected benefit is there. But when I saw some differences in WLAN performance between my Macbook and my Nexus 6P, I wanted to confirm what I was seeing with a solid test that isolated the wireless links. I considered trying to use a typical Internet speed test, but then that is measuring much more than just the speed of the wireless link. Even doing a file transfer of a large file from the NAS does not truly isolate the wireless leg of the network. This led me to do a little research and in the end, iperf3 came to the rescue.

To do this test, just SSH into the access point in question and run the following iperf command:


iperf -f M -i 1 -p 11111 -s -t 60 -N


Then on the client device (in my case, the Nexus 6P) I feed it the following matching client oriented options:

-f M -i 1 -p 11111 -t 60 -N -c 192.168.1.x

   use the ip address of your access point here


For this, I was rewarded with the following output on both the client and the access point:


[  4] local 192.168.1.x port 11111 connected with 192.168.1.y port 46275
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0- 1.0 sec  15.0 MBytes  15.0 MBytes/sec
[  4]  1.0- 2.0 sec  15.9 MBytes  15.9 MBytes/sec
[  4]  2.0- 3.0 sec  15.9 MBytes  15.9 MBytes/sec
[  4]  3.0- 4.0 sec  16.0 MBytes  16.0 MBytes/sec
[  4]  4.0- 5.0 sec  15.8 MBytes  15.8 MBytes/sec
[  4]  5.0- 6.0 sec  16.1 MBytes  16.1 MBytes/sec
[  4]  6.0- 7.0 sec  15.8 MBytes  15.8 MBytes/sec
[  4]  7.0- 8.0 sec  16.0 MBytes  16.0 MBytes/sec
[  4]  8.0- 9.0 sec  15.7 MBytes  15.7 MBytes/sec
[  4]  9.0-10.0 sec  16.1 MBytes  16.1 MBytes/sec
[  4] 10.0-11.0 sec  15.4 MBytes  15.4 MBytes/sec


This is a decent improvement, about 2x. And it makes sense when I confirm the connection speeds on each network. First, here is the 802.11n network on 2.4GHz as seen by Android:



Based on the 117 Mbps rate, I presume this is a 20 MHz channel configuration with 2 streams in use, backed down off the max rate of 130 Mbps by 10% to arrive at 117 Mbps. The 130 Mbps starting number is due to not using a "Short Guard interval" feature, that would otherwise set the maximum speed to 150 Mbps. The explanations given here and here were very useful to help understand how reduced connection rates work. Note: expect to enjoy a little less than half of the shown "air link bit rate" due to things like partially degraded signals, driver inefficiencies and IP protocol overhead. Also, in this specific case, that UAP's wired interface is limited to 100 Mbits, so there's no way a wireless client to take advantage of that extra 17 Mbps in the link speed shown above.

Then here is the what the 802.11ac network connection looks like to Android:



This link speed matches with the expected max speed for a two stream 802.11ac configuration set for 80 MHz width, as depicted by this chart:



But, for reasons I still don't fully understand, even at the 867 Mbps link speed, the transfer rate is far below what I would expect (15 MB/sec instead of a more idealized 45MB/sec or so). This performance is still plenty good enough for me. Its also close to what I'm seeing for transfer rates on my Macbook, which gets around 20MBytes/sec. In the case of the Mac, I do get a little more information about the link speed by doing an option-click on the wifi icon:




The 351 Mbps tx rate shown here is probably lower than 867 because the mac is on a different floor than the AC access point. It does help to explain the lower than expected 20MB/sec transfer rate on that box. However, the Nexus phone peaked at 15MB/sec transfer speeds while being just a few feet away from the access point. Previously, the max speeds between the Nexus 6P and the UAP access points running 802.11n on 2.4GHz topped out around 7MB/sec, so although the gain of roughly 2x isn't as good as I would have hoped for, it is a very welcome improvement.

I suppose I could eek out a little more throughput numerically had I explored the lower overhead, UDP-only options of iperf, but most of what will stream over the WLAN will be TCP anyway, so measuring for that additional overhead in the test is probably best.

Have you speed tested your wireless LAN? If so, how did you do it and what kind of performance are you seeing?


No comments: