When you are experiencing network-related issues, such as stuttering and glitching, while screen mirroring, it can be helpful to analyze network traffic to find out if the network conditions are to blame. To get detailed metrics, it is possible to enable iPerf on the AirServer Connect.

iPerf is a tool that sends packets from a sending device, which are then received by iperf on AirServer Connect. As a result, it provides you with a list of what the sending device was able to send and what AirServer received with useful information such as the interval, the data, used bandwidth, and dropped packets.

Doing tests with iperf allows you to test the network throughput in more detail. When testing the throughput, it's important to mimic how you will be using AirServer under normal circumstances (eg. if you are having issues from a Mac to AirServer, run the test between those two devices). Leave both the sender and AirServer Connect within your network.

How can I use iPerf with AirServer Connect?

  • Please use a FAT32 formatted USB stick and place the AirServer-iperf.adu file, which is linked at the bottom of this article, on that stick.
  • Plug the USB stick into any USB port on the device. Once the yellow light is on, iPerf is running.
  • When iPerf is enabled, you can download iPerf (Windows, macOS, Android & iOS). On Windows & macOS, iPerf is only available as a command-line tool.
  • Run the following command from the sender. This will test for packet loss by sending data at 25mbps during a 10-second test. This will show you a sender- and server-side report divided into 100ms intervals. This simulates a single mirroring session.
iperf3 -c AirServer_ip_here -u -i 0.1 -b 25M --get-server-output

To test multiple connections, you can increase 25M to 75M in the command.

  • To disable iPerf again, please reboot AirServer Connect.


How can I interpret the results?


Before interpreting the results, it's essential to understand what you are expecting to see in normal circumstances. When there is no issue with your network, there should be a very clean sender and receiver report. This means you should be seeing stable results without interruptions or many dropped packets. 


It's important to note that screen mirroring is very dependent on a stable connection as even the smallest interruption can cause stuttering. This is why we are running a test with 100ms intervals. Often users do not notice they are experiencing any network issues until they use a technology that requires a very stable and constant connection for instance screen mirroring or video conferencing.


Below is an example of a great server-side report with very good intervals:


Server output:
Accepted connection from 10.0.2.55, port 54544
[  7] local 10.0.2.149 port 5201 connected to 10.0.2.55 port 59612
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  7]   0.00-0.10   sec  8.00 KBytes   654 Kbits/sec  0.000 ms  0/1 (0%)  
[  7]   0.10-0.20   sec   264 KBytes  21.6 Mbits/sec  0.043 ms  2/35 (5.7%)  
[  7]   0.20-0.30   sec   304 KBytes  24.9 Mbits/sec  0.045 ms  4/42 (9.5%)  
[  7]   0.30-0.40   sec   280 KBytes  22.9 Mbits/sec  0.052 ms  1/36 (2.8%)  
[  7]   0.40-0.50   sec   280 KBytes  22.9 Mbits/sec  0.051 ms  5/40 (12%)  
[  7]   0.50-0.60   sec   264 KBytes  21.6 Mbits/sec  0.054 ms  5/38 (13%)  
[  7]   0.60-0.70   sec   280 KBytes  22.9 Mbits/sec  0.051 ms  1/36 (2.8%)  
[  7]   0.70-0.80   sec   296 KBytes  24.2 Mbits/sec  0.047 ms  4/41 (9.8%)  
[  7]   0.80-0.90   sec   304 KBytes  24.9 Mbits/sec  0.046 ms  0/38 (0%)  
[  7]   0.90-1.00   sec   272 KBytes  22.3 Mbits/sec  0.054 ms  1/35 (2.9%)  
[  7]   1.00-1.10   sec   288 KBytes  23.6 Mbits/sec  0.052 ms  5/41 (12%)  
[  7]   1.10-1.20   sec   280 KBytes  22.9 Mbits/sec  0.053 ms  1/36 (2.8%)  
[  7]   1.20-1.30   sec   296 KBytes  24.2 Mbits/sec  0.046 ms  4/41 (9.8%)  
[  7]   1.30-1.40   sec   304 KBytes  24.9 Mbits/sec  0.046 ms  0/38 (0%)  



If you are seeing a lot of stuttering and jitters, you are likely getting a server-side report that looks like the one below:


Server output:
Accepted connection from 10.0.2.55, port 54544
[  7] local 10.0.2.149 port 5201 connected to 10.0.2.55 port 59612
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
...
[  8]   2.50-2.60   sec  0.00 Bytes  0.00 bits/sec  0.122 ms  0/0 (0%)  
[  8]   2.60-2.70   sec  4.05 MBytes   34 Mbits/sec  0.225 ms  444/963 (46%)  
[  8]   2.70-2.80   sec  3.05 MBytes   25 Mbits/sec  0.085 ms  0/391 (0%)  
[  8]   2.80-2.90   sec  3.04 MBytes   25 Mbits/sec  0.075 ms  0/389 (0%)  
[  8]   2.90-3.00   sec  0.00 Bytes  0.00 bits/sec  0.075 ms  0/0 (0%)  
[  8]   3.00-3.10   sec  0.00 Bytes  0.00 bits/sec  0.075 ms  0/0 (0%)  
[  8]   3.10-3.20   sec  3.62 MBytes   30 Mbits/sec  0.285 ms  665/1128 (59%)  
[  8]   3.20-3.30   sec  3.01 MBytes   25 Mbits/sec  0.164 ms  0/385 (0%)  
[  8]   3.30-3.40   sec  3.13 MBytes   26 Mbits/sec  0.121 ms  0/401 (0%)  
[  8]   3.40-3.50   sec  2.89 MBytes   24 Mbits/sec  0.198 ms  0/370 (0%)  
[  8]   3.50-3.60   sec  0.00 Bytes  0.00 bits/sec  0.198 ms  0/0 (0%)  
[  8]   3.60-3.70   sec  2.81 MBytes   23 Mbits/sec  0.152 ms  404/764 (53%)  


This server-side report shows that during several intervals, iPerf did not receive any packets at all. When screen mirroring, such inconsistent behavior would be visible as stutters or jitters. If the issue lies with the sender, you might see similar behavior in the sender's report.


In this particular example, it's also possible to see that, in some intervals, about half of the sent packets are dropped.

 

Server output:
Accepted connection from 10.0.2.55, port 54544
[  7] local 10.0.2.149 port 5201 connected to 10.0.2.55 port 59612
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
...
[  8]   2.50-2.60   sec  0.00 Bytes  0.00 bits/sec  0.122 ms  0/0 (0%)  
[  8]   2.60-2.70   sec  4.05 MBytes   34 Mbits/sec  0.225 ms  444/963 (46%)
[  8]   2.70-2.80   sec  3.05 MBytes   25 Mbits/sec  0.085 ms  0/391 (0%)  
[  8]   2.80-2.90   sec  3.04 MBytes   25 Mbits/sec  0.075 ms  0/389 (0%)  
[  8]   2.90-3.00   sec  0.00 Bytes  0.00 bits/sec  0.075 ms  0/0 (0%)  
[  8]   3.00-3.10   sec  0.00 Bytes  0.00 bits/sec  0.075 ms  0/0 (0%)  
[  8]   3.10-3.20   sec  3.62 MBytes   30 Mbits/sec  0.285 ms  665/1128 (59%) 
[  8]   3.20-3.30   sec  3.01 MBytes   25 Mbits/sec  0.164 ms  0/385 (0%)  
[  8]   3.30-3.40   sec  3.13 MBytes   26 Mbits/sec  0.121 ms  0/401 (0%)  
[  8]   3.40-3.50   sec  2.89 MBytes   24 Mbits/sec  0.198 ms  0/370 (0%)  
[  8]   3.50-3.60   sec  0.00 Bytes  0.00 bits/sec  0.198 ms  0/0 (0%)  
[  8]   3.60-3.70   sec  2.81 MBytes   23 Mbits/sec  0.152 ms  404/764 (53%)  

In the last column on the highlighted lines, it is possible to see the percentage of dropped packets. While the receiving speed is sufficient, there are too many packets dropped for a stable mirroring session. This can result in choppy behavior and/or artifacts.



Possible causes of poor results


There is not always a clear single reason why performance is intermittent. There can be several causes, or a combination of causes, for poor screen mirroring performance and corresponding poor iPerf results. Below we have listed a few of the most common reasons we have seen with our customers:

  • Poor Wi-Fi reception for the sending device and/or AirServer Connect (if Wi-Fi connected).
  • Overcrowded network environments without proper segmentation.
  • Interference from other Wi-Fi networks using similar Wi-Fi channels in the vicinity of your network.
  • The usage of DFS 5GHz Wi-Fi channels.
  • On large networks, we have seen that Bonjour advertisements from various devices can cause substantial stress on the network.