With the release of Ekahau Site Survey (ESS) 8.0 came the option of active throughput surveys along with active ping surveys. Ekahau wrote their own version of iPerf3 called iperf3-ekahau for this purpose. While they say you can use iPerf2 or iPerf3 as the server, they recommend their version. You can download it here, and find Ekahau’s official documentation here.
I thought it would be handy to have a portable throughput test server, and the Raspberry Pi is certainly portable. In this post I’ll explain how to install iperf3-ekahau in Raspbian, and how to set up ESS for active throughput surveys. The commands involved are very basic, and anyone with limited Linux experience should be able to get this working. You can also see my previous post “Setting Up Your Raspberry Pi” if you are just getting started with Raspberry Pi and/or Linux. I should have noted in that post that I’m using the B+ model. I’ve included links to documentation on any Linux commands that weren’t used in the previous post. Always remember, command-line completion with the Tab key is your friend!
***Spoiler alert: after drafting this post, I was doing a bit more testing and hit a bit of a snag. I won’t end up using the Raspberry Pi as a throughput test server, but it was fun to set this up and use it as such while I am sorting out a better option. I’ll explain at the end of the post. If you have a more powerful machine running Debian, this process should work for it.***
With your Raspberry Pi configured and connected to the network, installing iperf3-ekahau is very simple. First, download the package from Ekahau. The wget command will grab it for you. Type sudo wget www.ekahau.com/userData/ekahau/wifi-design/documents/iperf3-ekahau.zip.
Note that this is case-sensitive. The command ls will list the contents of the current directory. The output should look like the image below.
Next you’ll have to unzip the file. Use the command sudo unzip iperf3-ekahau.zip -d /opt. The -d sets the destination directory. Use ls /opt to see the folder in it’s destination. You should see something like this.
The last thing to do is change the permissions on the iperf3-ekahau folder. If you want, you can read about permissions here. Anyways, first you’ll want to change the current directory to “/opt”. Type cd /opt. Type ls -l to view the current permissions. You’ll see that the “iperf3-ekahau” directory is owned by root, and write permissions aren’t set for others. It seemingly won’t run without them; I guess it writes something, somewhere. Use the command sudo chmod -R 777 iperf3-ekahau. Do an ls -l again. You should see that the permissions have changed.
Now you are ready to run the iperf3-ekahau server. Change the current directory to “iperf3-ekahau” with the command cd iperf3-ekahau. If you are at the home directory, you can use cd /opt/iperf3-ekahau as well. Remember command line completion – you should be able to type cd /opt/ip, hit tab, and voila! If you’re curious, use ls to see the contents of that directory. You need to run the “run_eperf_server.sh” file. Type ./run_eperf_server.sh. Your iperf3-ekahau server is now up and running. When you’re all done surveying, you can stop the server with Ctrl-c.
With the server up and running, the next step is to set up ESS for the active throughput survey.
Setting Up ESS for Active Throughput Survey
Open up ESS. The first thing to do is configure the active survey for throughput testing. Click on the “Active” button in the top left, make sure “Throughput” is selected in the dropdown, and then click the Settings button (the bumpy wheel thingy). The Active Survey Configuration window will pop up. You’ll need to set Mode to Iperf3 if you’re using iperf3-ekahau on the server. The host will be the IP address of your server, in this case your RPI. The Cycle setting will change the length of your test. If you’re doing a stop-and-go survey, it runs a test for this length of time at each click. Ten seconds can make a long survey VERY long. I did one floor at 10, and have since switched to 5 seconds. I found that a Buffer Length setting of 512k gave me the best results.
Click “Ok” and you’ll be at the “Active Survey” tab. This is where you can do tests with no project open, or if you have a project open and want to run a throughput test without plotting a survey point. I like to do this quickly before surveying to avoid any surprises. Click the play button and you’ll see your test begin. It’ll continue running ten-second tests, or whatever duration your Cycle is set to, until you tell it to stop. If you’re seeing results, you’re ready to start surveying.
During a survey, the throughput tests basically run the same as whichever survey method you choose. If you are doing a stop-and-go survey, it runs a test for the same time as your Cycle setting. To see throughput results in your survey, just hover over any survey point.
For a continuous survey, the throughput test runs continuously from your first left-click until you right-click to end the survey path. You can view the results by hovering over any survey path. The portion of the path that the results are associated with will be highlighted. This isn’t a real survey below, but you can see how the results are presented.
I’ve already found throughput surveys to be extremely useful. Another great addition from the team at Ekahau!
The portability of the Pi is what attracted me to it. I forgot that it only has a 100Mb ethernet port, so (assuming that 802.11n maximum real throughput is 60%-70% of the connected data rate) it’s probably only useful for testing on WLANs with data rates up to 150 Mbps, right? That would be anything less than or equal to:
- 20 MHz channel, 2 spatial stream, short guard interval, HT.
- 40 MHz channel, 1 spatial stream, short guard interval, HT.
This fits my current work networks for the most part. We have some 3 SS access points, but nothing more than 2×2:2 clients. In testing I’ve only seen 45-50 Mbps at work. Here you can see some results from my home network (2 SS client, 80 MHz channel, 40 ns GI, VHT, MCS9, connected rate 866.7 Mbps).
What gives? Only 58 Mbps? I changed the direction to Send and tested again.
Still nothing to write home about, eh? Well, the 10/100 Ethernet port runs through the USB 2.0 bus, so I thought maybe I should unplug the USB keyboard… No difference. Even with the Pi connected directly to my laptop and using iPerf, I got about the same results as above. So, chalk it up to CPU? I really don’t know, but it won’t serve my purpose. There are conflicting results all over the internet – some people get 94 Mbps, some get 64 Mbps, some get somewhere in between. I found this article from HTPC Guides comparing Raspberry Pi, Raspberry Pi 2, Banana Pi and Banana Pi Pro. A Banana Pi might do the trick for me with its built-in gigabit port.
What about a USB to GbE adapter? The USB 2.0 spec maximum speed is 480 Mbps, which would put the maximum connected rate at around 650 Mbps. That would mean network configurations less than or equal to:
- 40 MHz channel, 3 spatial streams, short guard interval, HT (any 802.11n network).
- 20 MHz channel, 4 spatial streams, short guard interval, VHT, MCS8 (up to 347 Mbps).
- 40 MHz channel, 3 spatial streams, short guard interval, VHT, MCS9 (up to 600 Mbps).
- 80 MHz channel, 2 spatial streams, short guard interval, VHT, MCS7 (up to 433 Mbps).
- 160 MHz channel, 1 spatial stream, short guard interval, VHT, MCS7 (up to 650 Mbps).
I realize some of those configurations aren’t workable in real networks. More googling suggests that a USB-GbE adapter would still be limited to somewhere just over 200 Mbps. I think I’ll avoid that and look for something with a built-in GbE port. If I end up with a Banana Pi, I’ll post my findings here. In the mean time, I’m going to throw iperf3-ekahau onto a stationary server.
Thanks for reading! I’d love to see any comments or suggestions you might have.