Best practices and tools for measuring wifi performance

Installing and Using OpenWrt
#1

What is this thread about?

Having read a lot of forum threads, I came to the conclusion that many users (myself included) lack coherent information about how to conduct proper debugging and how to properly measure wifi performance. Furthermore, they lack information about tools available to do such. I invite everybody to point to proper practices, tools and methods in hopes of giving users and committers to OpenWRT alike a starting point to evaluate and debug their wifi issues. Posting measurements for educational purposes would be great. Comparison of methods and tools sounds nice too, but might be a little exhaustive. Screenshots will be nice. I plan to sporadically update and edit this Initial message to account for responses and debate in this thread. Eventually, some info from here could be used for the docs.

What is this thread not about?

  • Expecting help, because your measurements point to flaws in OpenWRT code.
  • Debugging your very personal setup of OpenWRT

→ If you have issues with your setup or if your measurements point to flaws in the code or hardware, please open a new forum post, instead of raising the issue here.

Best practices:

  • test latency (e.g. round trip time) simultaneously with throughput (show graphics side by side) [1]
  • run tests long enough [2]
  • test same configuration on same hardware with various distances/paths [2]
  • test same configuration on same hardware with various hindrances (e.g. walls inbetween)
  • test same configuration with multiple devices and different hardware
  • Measure latency under load [2]
  • Measure latency/throughput with multiple (client) streams [2]
  • Do not interpret UDP and TCP results with equal weights [2]
  • Do not overvalue throughput rate over range without looking at latency or rate control [2]
  • Do not overvalue summary statistics that don’t look at inter-station behaviors [2]

Sources: [1], [2]; OpenWRT Forum; Common Sense

Tools:

Simple methods for beginners:

1. Iperf3

  • Official Iperf3 user docs

  • How to capture throughput:

    • Run following command at the serverside: ĂŚperf3 -s

    • Run one of the following commands at the client side:

      TCP test, which measures the upload from client to server
      iperf3 -c <IP of Iperf Server> -p <Port of Iperf Server> -t 60 -i 10

      TCP test with 4 Client Streams, which measures the uploads from clients to server
      iperf3 -c <IP of Iperf Server> -p <Port of Iperf Server> -P 4 -t 60 -i 10

      TCP test with 8 Client Streams, which measures the uploads from clients to server
      iperf3 -c <IP of Iperf Server> -p <Port of Iperf Server> -P 8 -t 60 -i 10

      TCP test; Reverse mode: server sends, client receives
      iperf3 -c <IP of Iperf Server> -p <Port of Iperf Server> -t 60 -i 10 -R

      TCP test with 4 Client Streams; Reverse mode: server sends, clients receive
      iperf3 -c <IP of Iperf Server> -p <Port of Iperf Server> -P 4 -t 60 -i 10 -R

      TCP test with 8 Client Streams; Reverse mode: server sends, clients receive
      iperf3 -c <IP of Iperf Server> -p <Port of Iperf Server> -P 8 -t 60 -i 10 -R

      Bidirectional TCP test
      iperf3 -c <IP of Iperf Server> -p <Port of Iperf Server> -t 60 -i 10 --bidir

      Bidirectional TCP test with 4 Client Streams
      iperf3 -c <IP of Iperf Server> -p <Port of Iperf Server> -P 4 -t 60 -i 10 --bidir

      Bidirectional TCP test with 8 Client Streams
      iperf3 -c <IP of Iperf Server> -p <Port of Iperf Server> -P 8 -t 60 -i 10 --bidir

  • Use Iperf in combination with Wireshark: Capture traffic with wireshark while doing throughput tests with iperf, then look at Wireshark's "Statistics → Stream graphs → Round Trip Time"

  • Tips and things to look out for when using Iperf3

How to debug wifi issues:

Additional info in German language:

Miscellaneous:

Key Vocabulary:

Methods that look like, but that actually do NOT measure wifi performance:

Projects that try (or tried) to fix Linux Wifi

History, Videos and Literature about how wifi works, how it used to work in the past and historical attempts to fix it:

Dump of links, which are related to the topic, but that still have to be sifted through and that I am possibly considering to comment upon:

13 Likes
Archer A7 uploads at 2x speed compared to download
#2

[Reserved]

#3

[Reserved 2]

#4

[Reserved 3]

#5

Me to.

But you are seriously the first one to make three reserved posts in your own tread without anyone actually giving some feedback on your first hypothesis.

If you ask me “measuring perfection” is addictive for the human brain, once in that loop there will never be enough measuring and when the measuring to perfection is finally done. Then add another decimal and the carrousel starts all over.

So does the world change if everyone measures the wifi performance with all these tools? Does actually anyone have time to use the wifi if measuring it this exactly all the time?

1 Like
#6

I recently wanted to post the systemlog and kernellog from OpenWRT, because i encountered an issue and i had to post those two in three different posts, because there is a characterlimit, so I wanted to make sure to have enough space :slight_smile: Maybe we will not need the reserved space here, but who knows.

You are free to fix your wifi without measurements. You are also free to not fix your wifi at all. With help of some measurements, my personal world changed though, because in my flat, i found a better location for my wifi-repeater. I am sure, somebody who actually knows how to code may make even better use of precise measurements. #Education. #Free Speech. #People have to start somewhere learning about things.

#7

Did you post those logs as “preformated text”?

#8

I used

```

```

as you can see here: OpenWrt Support for D-Link DAP-X1860 - #88 by ThiloteE

#9

Maybe add crusader (https://github.com/Zoxc/crusader) as a nifty tool to generate load between two endpoints and also concurrent latency measurements. Not as powerful as i.e. iperf2 but it will generate simple graphs to allow assessing the measurement immediately after each run.

2 Likes
#10

Another thought: Instead of attempting to use your router to source/sink data (which will affect its routing performance), you could use a small single-board computer with Ubuntu to run Flent, Crusader, iperf, etc.

I have a RPi 4 (purchased before the pandemic - so not too expensive) and an Odroid (don't remember what model) attached to Ethernet ports on my router...

Does anyone have recommendations/links for other (modest price) devices that could run those tests?

1 Like
#11

Yeah, and even if you have a (spare) desktop computer (Linux/Mac/Windows) connected with gigabit Ethernet to the same network as the wifi access point, run iperf there as the other end. Ensure the Ethernet speed is faster than the highest possible speed of the wifi network.

Anti-pattern: measuring wifi by connecting to an upstream server. You'll be hard-pressed to segregate the wifi link peformance and the upstream link/general Internet's performance.

1 Like
#13

Thank you for starting this great thread. A lot of good advice in here.

I also have a few tips to contribute.

iperf3 tips

One important thing to note here is that by default iperf3 UPLOADS data from the client to the server.

The reason this is important to consider on WiFi is that WiFi clients oftentimes have much weaker antennas than WiFi routers.

For example, on my M1 Macbook Air I can get up to 700-800 mbit when downloading from the server, but only 400-500 when uploading.

This can be solved by using this option:

-R, --reverse             run in reverse mode (server sends, client receives)

I would suggest to add that to all the commands in your post, because download is probably what most people are interested in testing.

Where you run the testing tool server and client is important

A lot of the performance is affected by the processing speed of the components between the client and the server.

For example, if you have a router with a weak CPU and run the iperf3 server on the router, then it's possible the speeds will be limited, because iperf3 itself uses up a large portion of the router's available CPU and starves the router of the CPU to achieve full wifi transmission rates.

The solution would be to connect a wired computer to the router that runs the iperf3 server. And then run the test from a wifi client to the wired computer.

But this stil doesn't give you the FULL picture. Because routing from lan to wan also requires CPU power and this is not being done when testing on lan only. This is especially important if you want to test the maximum bandwidth your router can handle with SQM.

If you want to determine the routing capabilities, then the iperf3 server should be "behind the WAN port" of the router.

Realistically you would need two routers for that setup.

For example, maybe you have the ISP router that's connected to the internet and has a LAN of 192.168.1.0/24.

Then you connect the new router you want to test to it that has its own lan of 192.168.2.0/24. Plug the new router's WAN port into the ISP router's LAN port so that it is in both networks and routes between them.

Then you connect a the iperf3 server to the ISP router. And you connect the wifi client to the new router.

Then you run the test from a client connected to the new router. This fully tests the performance of your router and all components involved.

Again, this is most likely not necessary if you just want to test your current network connection as you can run speedtests directly to the internet to test the routing performance.

But if you want to determine the maximum performance your router is capable off, then that's one way to do it.

Test bufferbloat on both wired and wifi

A similar issue si when you are measuring bufferbloat (latency under load). You should always first test it on ethernet to determine the bufferbloat performance of the routing component and SQM system.

This tests the bufferbloat between router and ISP.

After that you can test it on WiFi to determine if there is any additional bufferbloat between WiFi -> Router.

Avoid WiFi scanning tools while testing

Another important thing that could trip you up if you are testing a lot of things is WiFi scanning.

If you run a software that analyses channels, then the software is going to make periodic scans of available WiFi access points.

When it does that, it oftentimes interrupts the entire WiFi connection. This causes all WiFi transmissions to stop for a few miliseconds or even seconds.

This can cause you to have huge ping spikes and reduced transmission that will give you the wrong impression of your WiFi performance.

2 Likes
Archer A7 uploads at 2x speed compared to download
Variance in throughput
#14

@ThiloteE You are only interested in English-language texts, I suppose?

I wrote something in German a while ago, because I was active in an action group who helped to bring fiber-optical internet to our small place, and in the aftermath I got countless questions re. WiFi problems, so I created a blog post about how to debug WiFi issues... I also created a similar blog post about internet issues in general (again in German).

In case you are interested anyway, please let me know, and I'll share the links here.

#15

Sure, i would be delighted :slight_smile: although I think most people here speak English, as it seems to be the current lingua franca. I am from Germany too :wink:

1 Like
#16

Yeah, right. But maybe for German people less fluent in English the posts could be helpful?

Anyway, here's the blog posts, feel free to include them in your collection (or to omit them):

(I suspected already you are German because of your username -- the leading part is a well-known German given name... :wink: )

1 Like
#17

Thanks for the time you spent and the info shared. I'm a user and seldom need to get down to the packet level. My Fave tool is android app "WiFiAnalyzer", the VREM version. You can watch your radio in almost real time. Handy for initial config of wrt3200acm which has too many radios.

1 Like