You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
NOTE: The iperf3 issue tracker is for registering bugs, enhancement
requests, or submissions of code. It is not a means for asking
questions about building or using iperf3. Those are best directed
towards the Discussions section for this project at https://github.com/esnet/iperf/discussions
or to the iperf3 mailing list at [email protected].
A list of frequently-asked questions
regarding iperf3 can be found at http://software.es.net/iperf/faq.html.
Context
Upgraded iperf3 from iperf3-3.6 to iperf3-3.14
Version of iperf3:
iperf3-3.14
Hardware:
Client side Raspberry Pi 4B or AMD Ryzen 5 PRO 5650U
Server side HP server
Operating system (and distribution, if any):
Client side Raspberry Pi OS (64-bit) or LinuxMint 21.2 based on Ubuntu 22.04 Jammy
Server side Ubuntu 16.10
one to collect human readable and one to collect JSON
Please note: iperf3 is supported on Linux, FreeBSD, and macOS.
Support may be provided on a best-effort basis to other UNIX-like
platforms. We cannot provide support for building and/or running
iperf3 on Windows, iOS, or Android.
Other relevant information (for example, non-default compilers,
libraries, cross-compiling, etc.):
Compiles without error on all platforms.
Please fill out one of the "Bug Report" or "Enhancement Request"
sections, as appropriate. Note that submissions of bug fixes, new
features, etc. should be done as a pull request at https://github.com/esnet/iperf/pulls
Bug Report
Client in Reverse mode in iperf3-3.14, verbose -V human readable does not show CPU utilization in the client side report but show it in server side report (--get server output). The opposite, when client upload the CPU utilization string appear after client report and not after server report.
This is unlike the behavior used to be in iperf3-3.6 which shown CPU utilization both after client and server side results.
This it make it impossible to see in iperf3-3.14 CPU utilization of the client in reverse (-R) mode as on client side in iperf3-3.14 there is no such report and the server side reports incorrect values for the client (remote/receiver) from previous test (this issue with incorrect server side report on client CPU utilization from previous test was present also in iperf3-3.6 but could have been ignored as, client side used to report apparently correct values.
Expected Behavior
this is from real 3.6 output:
iperf3 -Z -V -c xxx.xxx.xxx.xxx -t 10 -O 2 -R --get-server-output
Connecting to host xxx.xxx.xxx.xxx, port 5201
Reverse mode, remote host xxx.xxx.xxx.xxx is sending
#................................typical iperf3 output
CPU Utilization: local/receiver 14.2% (0.3%u/13.9%s), remote/sender 0.2% (0.0%u/0.2%s)
#................................typical iperf3 output
Server output:
CPU Utilization: local/sender 0.2% (0.0%u/0.2%s), remote/receiver 2.0% (0.0%u/2.0%s) -> that's wrong, it shall be 14.2% (0.3%u/13.9%s)
#................................typical iperf3 output
Actual Behavior
The line CPU Utilization: local/receiver 14.2% (0.3%u/13.9%s), remote/sender 0.2% (0.0%u/0.2%s) from above in 3.14 is missing and the CPU Utilization: local/sender 0.2% (0.0%u/0.2%s), remote/receiver 2.0% (0.0%u/2.0%s) has a wrong value of remote/receiver 2.0% (0.0%u/2.0%s) .
Repeating the test again (either in 3.6 or 3.14) will show in Server output remote/receiver 14.2% (0.3%u/13.9%s) from previous test.
Restore printing of CPU utilization on client report after the -R mode.
Also, the behavior of wrong, previous test CPU utilization shown on server output, (the same for is JSON) need to be, at, least documented.
Enhancement Request
Current behavior
Desired behavior
Implementation notes
The text was updated successfully, but these errors were encountered:
The issue is caused because printing the CPU Utilization is currently limited to the Sender only (although probably it had to be limited to the Client only). The fix to the issue is related to the changes suggested in PR #1358, so I added to the PR a suggested fix to this issue.
NOTE: The iperf3 issue tracker is for registering bugs, enhancement
requests, or submissions of code. It is not a means for asking
questions about building or using iperf3. Those are best directed
towards the Discussions section for this project at
https://github.com/esnet/iperf/discussions
or to the iperf3 mailing list at [email protected].
A list of frequently-asked questions
regarding iperf3 can be found at http://software.es.net/iperf/faq.html.
Context
Upgraded iperf3 from iperf3-3.6 to iperf3-3.14
iperf3-3.14
Client side Raspberry Pi 4B or AMD Ryzen 5 PRO 5650U
Server side HP server
Client side Raspberry Pi OS (64-bit) or LinuxMint 21.2 based on Ubuntu 22.04 Jammy
Server side Ubuntu 16.10
Servers as daemon launched as
sudo iperf3 -s -V -D -d --logfile iperf3.log -I iperf.pid
sudo iperf3 -s -J -D -i 0 -p 5202 --logfile iperf3_j.log -I iperf_j.pid
one to collect human readable and one to collect JSON
Please note: iperf3 is supported on Linux, FreeBSD, and macOS.
Support may be provided on a best-effort basis to other UNIX-like
platforms. We cannot provide support for building and/or running
iperf3 on Windows, iOS, or Android.
libraries, cross-compiling, etc.):
Compiles without error on all platforms.
Please fill out one of the "Bug Report" or "Enhancement Request"
sections, as appropriate. Note that submissions of bug fixes, new
features, etc. should be done as a pull request at
https://github.com/esnet/iperf/pulls
Bug Report
Client in Reverse mode in iperf3-3.14, verbose -V human readable does not show CPU utilization in the client side report but show it in server side report (--get server output). The opposite, when client upload the CPU utilization string appear after client report and not after server report.
This is unlike the behavior used to be in iperf3-3.6 which shown CPU utilization both after client and server side results.
This it make it impossible to see in iperf3-3.14 CPU utilization of the client in reverse (-R) mode as on client side in iperf3-3.14 there is no such report and the server side reports incorrect values for the client (remote/receiver) from previous test (this issue with incorrect server side report on client CPU utilization from previous test was present also in iperf3-3.6 but could have been ignored as, client side used to report apparently correct values.
this is from real 3.6 output:
iperf3 -Z -V -c xxx.xxx.xxx.xxx -t 10 -O 2 -R --get-server-output
Connecting to host xxx.xxx.xxx.xxx, port 5201
Reverse mode, remote host xxx.xxx.xxx.xxx is sending
#................................typical iperf3 output
CPU Utilization: local/receiver 14.2% (0.3%u/13.9%s), remote/sender 0.2% (0.0%u/0.2%s)
#................................typical iperf3 output
Server output:
CPU Utilization: local/sender 0.2% (0.0%u/0.2%s), remote/receiver 2.0% (0.0%u/2.0%s) -> that's wrong, it shall be 14.2% (0.3%u/13.9%s)
#................................typical iperf3 output
The line CPU Utilization: local/receiver 14.2% (0.3%u/13.9%s), remote/sender 0.2% (0.0%u/0.2%s) from above in 3.14 is missing and the CPU Utilization: local/sender 0.2% (0.0%u/0.2%s), remote/receiver 2.0% (0.0%u/2.0%s) has a wrong value of remote/receiver 2.0% (0.0%u/2.0%s) .
Repeating the test again (either in 3.6 or 3.14) will show in Server output remote/receiver 14.2% (0.3%u/13.9%s) from previous test.
iperf3_3.14_CPU_report_summary.txt
iperf3_3.6_CPU_report_summary.txt
iperf3_3.14_CPU_report_behaviour.txt
iperf3_3.6_CPU_report_behaviour.txt
iperf3 -Z -V -c 193.239.183.36 -t 10 -O 2 --get-server-output >log_3.14.txt
iperf3 -Z -V -c 193.239.183.36 -t 10 -O 2 -R --get-server-output >>log_3.14.txt
iperf3 -Z -V -c 193.239.183.36 -t 10 -O 2 --get-server-output >>log_3.14.txt
iperf3 -Z -V -c 193.239.183.36 -t 10 -O 2 -R --get-server-output >>log_3.14.txt
Restore printing of CPU utilization on client report after the -R mode.
Also, the behavior of wrong, previous test CPU utilization shown on server output, (the same for is JSON) need to be, at, least documented.
Enhancement Request
Current behavior
Desired behavior
Implementation notes
The text was updated successfully, but these errors were encountered: