--reverse option not working properly in combination with --blockcount #982

PatrikMosko · 2020-04-19T19:08:52Z

Context

Version of iperf3:
iperf3-3.7-3.fc32.x86_64
Hardware:
Lenovo ThinkPad T470S
Operating system (and distribution, if any):
Fedora >= 31 (I think f30 build doesn"t have this issue)
Other relevant information (for example, non-default compilers,
libraries, cross-compiling, etc.):
uname: Linux gdpr 5.5.13-200.fc31.x86_64 setting of window size should be explicit #1 SMP Wed Mar 25 21:55:30 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Bug Report

Server is stuck in a loop when in --reverse mode along with option --blockcount|-k.

Steps to Reproduce

iperf3 -sD --port 5201
iperf3 -c 127.0.0.1 -p 5201 -T"client" -R -k 50

Expected Behavior
client: Connecting to host 127.0.0.1, port 5201
client: Reverse mode, remote host 127.0.0.1 is sending
client: [ 5] local 127.0.0.1 port 51568 connected to 127.0.0.1 port 5201
client: [ ID] Interval Transfer Bitrate
client: [ 5] 0.00-0.00 sec 6.25 MBytes 19.1 Gbits/sec
client: - - - - - - - - - - - - - - - - - - - - - - - - -
client: [ ID] Interval Transfer Bitrate Retr
client: [ 5] 0.00-0.04 sec 7.50 MBytes 1.51 Gbits/sec 2 sender
client: [ 5] 0.00-0.00 sec 6.25 MBytes 19.1 Gbits/sec receiver
client:
client: iperf Done.
Actual Behavior
client: Connecting to host 127.0.0.1, port 5201
client: Reverse mode, remote host 127.0.0.1 is sending
client: [ 5] local 127.0.0.1 port 53008 connected to 127.0.0.1 port 5201
client: [ ID] Interval Transfer Bitrate
client: [ 5] 0.00-1.00 sec 3.26 GBytes 28.0 Gbits/sec
client: [ 5] 1.00-2.00 sec 3.65 GBytes 31.4 Gbits/sec
client: [ 5] 2.00-3.00 sec 3.44 GBytes 29.5 Gbits/sec
client: [ 5] 3.00-4.00 sec 3.61 GBytes 31.0 Gbits/sec
client: [ 5] 4.00-5.00 sec 3.54 GBytes 30.4 Gbits/sec
^Cclient: [ 5] 5.00-5.96 sec 3.44 GBytes 30.7 Gbits/sec
client: - - - - - - - - - - - - - - - - - - - - - - - - -
client: [ ID] Interval Transfer Bitrate
client: [ 5] 0.00-5.96 sec 0.00 Bytes 0.00 bits/sec sender
client: [ 5] 0.00-5.96 sec 20.9 GBytes 30.2 Gbits/sec receiver
iperf3: interrupt - the client has terminated
Actual Behavior (--verbose & --debug)
client: iperf 3.7
client: client: Linux hostname ...some irrelevant text here...
Control connection MSS 32768
send_parameters:
{
"tcp": true,
"omit": 0,
"time": 0,
"blockcount": 50,
"parallel": 1,
"reverse": true,
"len": 131072,
"pacing_timer": 1000,
"title": "client",
"client_version": "3.7"
}
client: Time: Tue, 10 Mar 2020 22:40:46 GMT
client: Connecting to host 127.0.0.1, port 5201
client: Reverse mode, remote host 127.0.0.1 is sending
client: Cookie: uwzmemndwggiu74qhjqsazwnyesfrnrv2lfv
client: TCP MSS: 32768 (default)
SNDBUF is 16384, expecting 0
RCVBUF is 131072, expecting 0
Congestion algorithm is cubic
client: [ 5] local 127.0.0.1 port 41970 connected to 127.0.0.1 port 5201
client: Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 0 seconds, 50 blocks to send, tos 0
tcpi_snd_cwnd 10 tcpi_snd_mss 32768 tcpi_rtt 7
interval_len 1.000037 bytes_transferred 3332339799
interval forces keep
client: [ ID] Interval Transfer Bitrate
client: [ 5] 0.00-1.00 sec 3.10 GBytes 26.7 Gbits/sec
tcpi_snd_cwnd 10 tcpi_snd_mss 32768 tcpi_rtt 7
interval_len 0.999996 bytes_transferred 3296731944
interval forces keep
client: [ 5] 1.00-2.00 sec 3.07 GBytes 26.4 Gbits/sec
tcpi_snd_cwnd 10 tcpi_snd_mss 32768 tcpi_rtt 7
interval_len 1.000163 bytes_transferred 3492806656
interval forces keep
client: [ 5] 2.00-3.00 sec 3.25 GBytes 27.9 Gbits/sec
tcpi_snd_cwnd 10 tcpi_snd_mss 32768 tcpi_rtt 7
interval_len 0.999966 bytes_transferred 3524657152
interval forces keep
client: [ 5] 3.00-4.00 sec 3.28 GBytes 28.2 Gbits/sec
...
client: [ 5] 400.00-400.55 sec 1.79 GBytes 27.8 Gbits/sec
client: - - - - - - - - - - - - - - - - - - - - - - - - -
client: Test Complete. Summary Results:
client: [ ID] Interval Transfer Bitrate
client: [ 5] 0.00-400.55 sec 0.00 Bytes 0.00 bits/sec sender
client: [ 5] 0.00-400.55 sec 1.38 TBytes 30.3 Gbits/sec receiver
client: rcv_tcp_congestion cubic
iperf3: interrupt - the client has terminated

PatrikMosko · 2020-04-20T03:51:52Z

Another observation:
when used with --bitrate, ie. 1000[b], it sends first batch of packet/s and then it just hangs, not sending/receiving anything, even though it expects something.

*command used:
iperf3 -c 127.0.0.1 -p 5201 -T"client" --bitrate 2000 -k 1 -R

*output
client: Connecting to host 127.0.0.1, port 5201
client: Reverse mode, remote host 127.0.0.1 is sending
client: [ 5] local 127.0.0.1 port 45276 connected to 127.0.0.1 port 5201
client: [ ID] Interval Transfer Bitrate
client: [ 5] 0.00-1.00 sec 128 KBytes 1.05 Mbits/sec
client: [ 5] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec
client: [ 5] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec
client: [ 5] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec
client: [ 5] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec
client: [ 5] 5.00-6.00 sec 0.00 Bytes 0.00 bits/sec
^Cclient: - - - - - - - - - - - - - - - - - - - - - - - - -
client: [ ID] Interval Transfer Bitrate
client: [ 5] 0.00-6.10 sec 0.00 Bytes 0.00 bits/sec sender
client: [ 5] 0.00-6.10 sec 128 KBytes 172 Kbits/sec receiver
iperf3: interrupt - the client has terminated

bmah888 · 2020-04-21T15:17:21Z

In the past there has been some brokenness associated with --reverse/-R. I wonder if this is more of the same.

bmah888 · 2020-04-27T23:54:11Z

See #761, which might or might not be related.

davidBar-On · 2020-05-10T09:35:58Z

I also have the problem that -n and -k don"t work in reverse mode, using a version I built on Ubuntu VM under Windows 10 from a clone of version 3.7+. The -t option does work in reverse mode. It may be that the problem is with the master git branch.

I checked that the server properly receives the values for either -t, -n, -k parameters. For the -t, create_server_timers() properly sets tmr_create(... test->duration + test->omit + grace_period ...).

However, I don"t see handling of the -n and -k limitations in the server"s side. The client does check these limitations in iperf_run_client():

	    /* Is the test done yet? */
if ((!test->omitting) &&
    ((test->duration != 0 && test->done) ||
    (test->settings->bytes != 0 && test->bytes_sent >= test->settings->bytes) ||
    (test->settings->blocks != 0 && test->blocks_sent >= test->settings->blocks))) {

On the other hand, iperf_run_server() does not include such check of the bytes and blockscount limitations for the reverse mode. Also, as the above iperf_run_client() code is checking for the sent bytes/blocks, it does not apply to the reverse mode (it may have worked if in reverse mode the check was for the received bytes/blocks).

Can it be that the right code of either iperf_run_server() or iperf_run_client() are not in the master branch?

bmah888 · 2020-09-17T17:03:53Z

OK I just ran into this problem while testing something else. The problem is that the ending conditions in iperf_run_client() don"t take reverse mode into account for -n or -k. (Note that the client side is the one that determines when the test is done, regardless of whether it"s sending or receiving data.)

So I think that in the snippet of code posted by @davidBar-On in the comment immediately above, we need to check for whether the client is sending or receiving and then check, for example, test->bytes_sent vs. test->bytes_received appropriately. Same for blocks. This makes the check kind of ugly and convoluted, but so is this mess of various options.

Reverse mode works for time-based tests because time->duration and test->done are updated in the same way on the client if its sending or receiving.

…nate. Note that these options still don"t really give intuitive results, because the ending conditions are evaluated on the client, which then needs to convey to the server via the control channel to stop sending. This will almost never result in the desired outcome of "a test of exactly N sends (or bytes) sent from the server to the client". Towards #982.

* fix: Make --reverse tests with --blockcount or --bytes actually terminate. Note that these options still don"t really give intuitive results, because the ending conditions are evaluated on the client, which then needs to convey to the server via the control channel to stop sending. This will almost never result in the desired outcome of "a test of exactly N sends (or bytes) sent from the server to the client". Also add test cases for --blockcount / --bytes with --reverse. Towards #982.

bmah888 added the bug label Apr 20, 2020

PatrikMosko changed the title ~~--reverse option not working properly in combination with --blocksize~~ --reverse option not working properly in combination with --blockcount Apr 28, 2020

bmah888 added the bug:test-data Bugs related to the amount of data sent during a test label Jul 13, 2020

bmah888 added the bug:reverse Bugs related to the use of --reverse label Sep 17, 2020

bmah888 mentioned this issue Sep 17, 2020

CLI backward compatible fix for issue #768 #797

Open

bmah888 mentioned this issue Sep 18, 2020

Issue 982 #1054

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

--reverse option not working properly in combination with --blockcount #982

--reverse option not working properly in combination with --blockcount #982

PatrikMosko commented Apr 19, 2020

PatrikMosko commented Apr 20, 2020

bmah888 commented Apr 21, 2020

bmah888 commented Apr 27, 2020

davidBar-On commented May 10, 2020

bmah888 commented Sep 17, 2020

--reverse option not working properly in combination with --blockcount #982

--reverse option not working properly in combination with --blockcount #982

Comments

PatrikMosko commented Apr 19, 2020

Context

Bug Report

PatrikMosko commented Apr 20, 2020

bmah888 commented Apr 21, 2020

bmah888 commented Apr 27, 2020

davidBar-On commented May 10, 2020

bmah888 commented Sep 17, 2020