UDP loss data not calculated correctly?

[malanmoon]

iperf 3.12 (cJSON 1.7.15)

I created an UDP session for 24h, the server output:

....
[  5] 2060.00-2080.00 sec  2.33 GBytes  1.00 Gbits/sec  0.006 ms  0/1801149 (0%)
[  5] 2080.00-2100.00 sec  2.33 GBytes   999 Mbits/sec  0.006 ms  1290/1801157 (0.072%)
[  5] 2100.00-2120.00 sec  2.33 GBytes  1000 Mbits/sec  0.004 ms  0/1801116 (0%)
....
[  5] 7000.00-7020.00 sec  2.33 GBytes  1.00 Gbits/sec  0.003 ms  0/1801158 (0%)
[  5] 7020.00-7040.00 sec  2.33 GBytes  1000 Mbits/sec  0.004 ms  705/1801138 (0.039%)
[  5] 7040.00-7060.00 sec  2.26 GBytes   969 Mbits/sec  0.002 ms  55673/1801169 (3.1%)
[  5] 7060.00-7080.00 sec  2.33 GBytes  1000 Mbits/sec  0.007 ms  0/1801094 (0%)
....
[  5] 86400.00-86400.04 sec  5.24 MBytes   995 Mbits/sec  0.007 ms  0/0 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[SUM]  0.0-86400.0 sec  1338478610 datagrams received out-of-order
[  5]   0.00-86400.04 sec  9.82 TBytes  1000 Mbits/sec  0.007 ms  0/2147483647 (0%)  receiver

Lost/Total Datagrams showed 0/2147483647 (0%) while there is packet loss, albeit minimal.

[davidBar-On]

@malanmoon, in principle, what you see is possible when UDP packets are received out of order. E.g. if in interval x last two packets received are 90 and 100. The report for this interval will show that 9 packets (91-99) are lost. However, if these packets are received in interval x+1 than in total no packet is lost. These lost packets will be counted in the "received out-of-order" in the server output.

However, since the test includes more than 2^31 packets, the packet counters overflowed (note that the reported total received packets 2147483647 is exactly the maximum value for signed 32 bits: 2^31 - 1). To prevent the packet counter overflow you should use the --udp-counters-64bit option.

It will help, if you can try the following two tests and share the summary lines reported by the server:

1. Run the test, but for only half an hour. If packets are really lost and the zero report was because of the the overflow, this test summary should show lost packets
2. Run the 24 hours test using the --udp-counters-64bit option. Note the --udp-counters-64bit may not solve the overflow problem, since there are internal iperf3 variables that may be related and that are defined as 32 bits only, but this test will help to determine that.

[bmah888]

I second the suggestion for --udp-counters-64bit. I wish we could make that the default, but that would break backward compatibility with older versions of iperf3.

[davidBar-On]

Per tests I run, using --udp-counters-64bit may not be sufficient, as several packets number related variables are defined as int, which may be 32 bits only, and printing the results uses %d. Submitted PR #1536 to fix these issue.

@malanmoon, I believe that it would still be useful to run the tests as suggested above (building and using the iperf3 from the PR would be better).