Output of sender's statistic damaged on Linux i586

[asy972]

Context

• Version of iperf3:

3.14

• Hardware:

Intel 586

• Operating system (and distribution, if any):

Linux

Bug Report

• Expected Behavior

$ iperf3 --client localhost --udp --time 1

[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-1.00 sec 128 KBytes 1.05 Mbits/sec 0.000 ms 0/6 (0%) sender
[ 5] 0.00-1.00 sec 128 KBytes 1.05 Mbits/sec 0.003 ms 0/6 (0%) receiver

• Actual Behavior

$ iperf3 --client localhost --udp --time 1

[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-1.00 sec 128 KBytes 1.05 Mbits/sec 0.000 ms 17179869184/0 (-2.5e-39%)
[ 5] 0.00-1.00 sec 128 KBytes 1.05 Mbits/sec 0.005 ms 0/4 (0%) receiver

[davidBar-On]

@asy972, can you please add more data:

1. Does the server (the receiver) also report "128 KBytes 1.05 Mbits/sec 0.005 ms 0/4"?
2. Run the client with the additional options -d -V and share its output.
3. If possible, also add the -d -V options to the server and also share it's output.

[asy972]

Hm. I'm about "17179869184/0 (-2.5e-39%)" instead of "0/6 (0%) sender".
Test's results are not important, it's on different computers.

The format is changed and the word "sender" is lost in the second case. Do I really need to do the actions you asked for? The problem is not reproducible on x86_64 Linux.

[davidBar-On]

Hm. I'm about "17179869184/0 (-2.5e-39%)" instead of "0/6 (0%) sender". ...
The format is changed and the word "sender" is lost in the second case. Do I really need to do the actions you asked for?

Oops! Sorry, I looked at the expected behavior of the sender (client) instead of the actual .... No need to take the actions I asked. I was confused with the 6 vs. 4 packets, but now I see that the server did receive the 4 packets (each 32KB = 256Kbits).

However, can you run the client with -v option to get its version and compile environment? The reported "Lost/Total" is very strange: 0 sent packets while the server received 4 and large number of lost packets. The 17179869184 lost is "0x4 0000 0000". If the 4 is the packet packets count shifted, this may be an issue for 32 bit processors.

Also, the "-2.5e-39%" issue, which is practically 0, is already corrected in iperf3 by setting the percentage value to 0.0 when packet count is zero. It is strange that the printer value is not "%0".

[asy972]

$ iperf3 -v
iperf 3.14 (cJSON 1.7.15)
Linux localhost 5.10.179-std-def-alt1 #1 SMP Fri Apr 28 16:59:36 UTC 2023 i686
Optional features available: CPU affinity setting, IPv6 flow label, TCP congestion algorithm setting, sendfile / zerocopy, socket pacing, bind to device, support IPv4 don't fragment

[davidBar-On]

Thanks for running the tests and sharing the information. The JSON output send_results and get_results indicates that the packets counting is o.k., so I suspect that the problem is in passing the arguments on the stack to the print command. One of the changes done in iperf3.14 is changing several packet counting related variables from int to int64_t. Therefore maybe the change was not properly done for 32 bits CPUs or maybe there is an issue with the iperf3 code for the compiler used.

To make sure that the problem is only in printing the results, running the following two tests can help:

1. Run the test using the -J option to produce JSON output (no need for the -d -V). If the problem is in printing the results, then the JSON output should be o.k.
2. Run the test with --time 2. If the problem is related to passing the parameters on the stack to the print command, and the "4" in the hex representation of "17179869184" is the packets count, then the 4 will be changed to 8 (and the lost packets count will be 34359738368).

[davidBar-On]

@asy972, I believe I found the problem - constant "0" packets count had to be cast as int64_t. Submitted PR #1556 with a suggested fix.

If you are building iperf3 yourself, can you build from this PR and re-run the test? (I don't have a 32 bits CPU to try the fix ....). You can also make the changes to your local 3.14 code (adding "(int64_t)" in two places) or clone the version from my repository: https://github.com/davidBar-On/iperf/tree/issue-1554-udp-output-for-32bits-machines).

[asy972]

If you are building iperf3 yourself, can you build from this PR and re-run the test?

Yes. I'll test it today or tomorrow.

[asy972]

it works, thanks!

[davidBar-On]

@asy972, thanks a lot for the help with testing and verifying the solution!