7

Sorry for asking this topic, but after reading the tool's documentation and the similar ticket to my question (https://github.com/esnet/iperf/issues/343), I still don't really understand/know the meaning of the Retr column in a TCP measurement, and I do not get how to "use" it :-(

Let's say there is a result, like below, where are 5 retries. I got, these are the number of TCP segments retransmitted, but were these retransmitted successfully, or they were just retried to send and not know about the result of that?

If I would like to see some kind of summa at the end in percentage (%), can the tool print it, similar to the UDP measurement? If not, how can I get the summa sent/received segments for compute the failure ratio?

Version of the tool:

>batman@bat-image:~$ iperf3 -v
iperf 3.8.1 (cJSON 1.7.13)
Linux bat-image 4.15.0-106-generic #107-Ubuntu SMP Thu Jun 4 11:27:52 UTC 2020 x86_64
Optional features available: CPU affinity setting, IPv6 flow label, TCP congestion algorithm setting, sendfile / zerocopy, socket pacing
batman@bat-image:~$

OS:

Ubuntu-18.04
batman@bat-image:~$ uname -aLinux bat-image 4.15.0-106-generic #107-Ubuntu SMP Thu Jun 4 11:27:52 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
batman@bat-image:~$

The log:

batman@bat-image:~$iperf3 -c 192.168.122.1 -f K -B 192.168.122.141 -b 10m -t 10
Connecting to host 192.168.122.1, port 5201
[  5] local 192.168.122.141 port 34665 connected to 192.168.122.1 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  1.25 MBytes  10.5 Mbits/sec    0    297 KBytes      
[  5]   1.00-2.00   sec  1.25 MBytes  10.5 Mbits/sec    0    297 KBytes      
[  5]   2.00-3.00   sec  1.12 MBytes  9.43 Mbits/sec    0    297 KBytes      
[  5]   3.00-4.00   sec  1.25 MBytes  10.5 Mbits/sec    0    297 KBytes      
[  5]   4.00-5.00   sec  1.12 MBytes  9.43 Mbits/sec    0    297 KBytes      
[  5]   5.00-6.00   sec  1.25 MBytes  10.5 Mbits/sec    0    297 KBytes      
[  5]   6.00-7.00   sec  1.12 MBytes  9.44 Mbits/sec    2   1.41 KBytes      
[  5]   7.00-8.00   sec   512 KBytes  4.19 Mbits/sec    1   1.41 KBytes      
[  5]   8.00-9.00   sec  0.00 Bytes  0.00 Mbits/sec    1   1.41 KBytes      
[  5]   9.00-10.00  sec  0.00 Bytes  0.00 Mbits/sec    1   1.41 KBytes      
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr

[  5]   0.00-10.00  sec  8.87 MBytes  7.44 Mbits/sec    5             sender

[  5]   0.00-16.91  sec  7.62 MBytes  3.78 Mbits/sec                  receiver

iperf Done.

thanks for your help,

/Robi

Robert Balogh
  • 71
  • 1
  • 1
  • 2

1 Answers1

21

In iperf3 the column Retr stands for Retransmitted TCP packets and indicates the number of TCP packets that had to be sent again (=retransmitted).

The lower the value in Retr the better. An optimal value would be 0, meaning that no matter how many TCP packets have been sent, not a single one had to be resent. A value greater than zero indicates packet losses which might arise from network congestion (too much traffic) or corruption due to faulty hardware.

Your original issue on Github has also been answered (source): https://github.com/esnet/iperf/issues/343

You are asking about the different outputs of iperf3 based on whether you test UDP or TCP.

  • When using UDP it's acceptable for packets to not arrive at the destination. To indicate the quality of the connection/ data transfer you get a percentage of how many packets did not arrive at the destination.

  • When using TCP all packets are supposed to reach the destination and are checked for missing or corrupted ones (hence Transmission Control Protocol). If a packet is missing it get's retransmitted. To indicate the quality of the connection you get a number of how many packets had to be retransmitted.

So both the percentage with UDP and the Retr count with TCP are quality indicators that are adjusted to the specifics of each protocol.

If you are wondering what the Cwnd column means, it stands for Congestion Window. The Congestion Window is a TCP state variable that limits the amount of data the TCP can send into the network before receiving an ACK. Source: https://blog.stackpath.com/glossary-cwnd-and-rwnd/

luke359
  • 311
  • 2
  • 6