Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue of argument '-i' when omitting the value #1482

Closed
sheercoding opened this issue Mar 14, 2023 · 2 comments
Closed

Issue of argument '-i' when omitting the value #1482

sheercoding opened this issue Mar 14, 2023 · 2 comments

Comments

@sheercoding
Copy link

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

Massive performance deviation when attaching or omitting the value 0 after the argument of '-i'.

  • Version of iperf3:
    iperf 3.9 (cJSON 1.7.13)

  • Hardware:
    Intel(R) Xeon(R) Platinum 8180 CPU @ 2.50GHz

  • Operating system (and distribution, if any):

DISTRIB_DESCRIPTION="Ubuntu 22.04.1 LTS"

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.):

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

  • Expected Behavior

$iperf3 -c 10.20.0.3 -i 0 -u -b 0
Connecting to host 10.20.0.3, port 5201
[ 4] local 10.20.0.1 port 58558 connected to 10.20.0.3 port 5201
[ ID] Interval Transfer Bandwidth Total Datagrams
[ 4] 0.00-10.00 sec 4.73 GBytes 4.06 Gbits/sec 619440


[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.00 sec 4.73 GBytes 4.06 Gbits/sec 0.000 ms 0/0 (0%)
[ 4] Sent 0 datagrams

iperf Done.

  • Actual Behavior

$iperf3 -c 10.20.0.3 -i -u -b 0
Connecting to host 10.20.0.3, port 5201
[ 4] local 10.20.0.1 port 49606 connected to 10.20.0.3 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-10.00 sec 26.4 GBytes 22.7 Gbits/sec 1188 1.39 MBytes


[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 26.4 GBytes 22.7 Gbits/sec 1188 sender
[ 4] 0.00-10.00 sec 26.4 GBytes 22.7 Gbits/sec receiver

-i, --interval n Sets the interval time in seconds between periodic bandwidth, jitter, and loss reports. If non-zero, a report is made every interval seconds of the bandwidth since the last report. If zero, no periodic reports are printed. Default is zero.

"$iperf3 -c 10.20.0.3 -i 0 -u -b 0" and "$iperf3 -c 10.20.0.3 -i -u -b 0" are supposed same results.
hence, is it a bug of iperf3?

Enhancement Request

  • Current behavior

  • Desired behavior

  • Implementation notes

@bmah888
Copy link
Contributor

bmah888 commented Mar 16, 2023

The behavior you observed was caused because the argument to the -i command-line option is required, it's not optional. So in this case, the option parser tried to use the following flag -u as an argument to -i, which evaluated as a value of zero. All (or maybe almost all) of the command-line flags that take arguments behave this way...they will use the next word following them as an argument even if it was intended to be a command-line flag.

I assume that the documentation on iperf.fr is out-of-date, like much of the content on that site. We (iperf3 maintainers) have no control over this Web site and our efforts to contact those responsible (over the past few years) have not been successful.

@davidBar-On
Copy link
Contributor

... the option parser tried to use the following flag -u as an argument to -i ...

I tested, and a major issue with this behavior is that since the -u is consumed as the -i argument, the default TCP test is running instead of UDP test. Submitted PR #1485 with a proposed fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants