Hello,
I'm observing a regression in iperf3 behavior when running multiple concurrent streams over a bandwidth-limited (shaped) link. The issue appears in versions ≥3.10 (confirmed in v3.20 and master) but was not present in v3.6.
Scenario
Server side: 3 (or more) iperf3 -s instances listening on different ports (e.g., 40010, 40011, 40012).
Client side: 3 (or more) iperf3 -c instances connecting to those ports manually and sequentially (with natural human-induced delays of ~100–500 ms between launches or use python script with us delays).
The link between client and server is strictly rate-limited (e.g., via tc or hardware shaper) to a total capacity lower than the aggregate requested bitrate (e.g., 300 Mbps shaped).
Expected behavior (as in v3.6)
All TCP sessions establish successfully, despite the eventual saturation.
Each stream starts sending traffic immediately after connection.
Final reports show actual achieved bandwidth per stream (for example, according to the configured configurations for WRED).
Even with 8–10 streams, all sessions complete and report results.
Actual behavior (v3.20)
The first 1–2 client sessions consume available bandwidth during test setup (including control messages and initial data).
Subsequent sessions hang indefinitely during connection setup — they are liberating the channel.
user@host1:mgmt:~$ sudo iperf3 -s -p 40008 -D
user@host1:mgmt:~$ sudo iperf3 -s -p 40016 -D
user@host1:mgmt:~$ sudo iperf3 -s -p 40024 -D
user@host2:mgmt:~$ sudo iperf3 -c 5.0.0.1 -p 40008 -t 5 --tos 32 -i 0.1
user@host2:mgmt:~$ sudo iperf3 -c 5.0.0.1 -p 40016 -t 5 --tos 64 -i 0.1
user@host2:mgmt:~$ sudo iperf3 -c 5.0.0.1 -p 40024 -t 5 --tos 96 -i 0.1
I’m primarily interested in testing bandwidth allocation across multiple streams with different --tos values (e.g., to validate QoS or traffic prioritization under a shaper). In v3.6, I could reliably launch many independent client–server pairs (each with its own TOS), and all sessions would start and report their achieved throughput, even when the total demand exceeded the link capacity.
Are there any tools, flags, or recommended patterns in recent versions of iperf3 that would allow me to restore this capability?
Hello,
I'm observing a regression in iperf3 behavior when running multiple concurrent streams over a bandwidth-limited (shaped) link. The issue appears in versions ≥3.10 (confirmed in v3.20 and master) but was not present in v3.6.
Scenario
Server side: 3 (or more) iperf3 -s instances listening on different ports (e.g., 40010, 40011, 40012).
Client side: 3 (or more) iperf3 -c instances connecting to those ports manually and sequentially (with natural human-induced delays of ~100–500 ms between launches or use python script with us delays).
The link between client and server is strictly rate-limited (e.g., via tc or hardware shaper) to a total capacity lower than the aggregate requested bitrate (e.g., 300 Mbps shaped).
Expected behavior (as in v3.6)
All TCP sessions establish successfully, despite the eventual saturation.
Each stream starts sending traffic immediately after connection.
Final reports show actual achieved bandwidth per stream (for example, according to the configured configurations for WRED).
Even with 8–10 streams, all sessions complete and report results.
Actual behavior (v3.20)
The first 1–2 client sessions consume available bandwidth during test setup (including control messages and initial data).
Subsequent sessions hang indefinitely during connection setup — they are liberating the channel.
I’m primarily interested in testing bandwidth allocation across multiple streams with different --tos values (e.g., to validate QoS or traffic prioritization under a shaper). In v3.6, I could reliably launch many independent client–server pairs (each with its own TOS), and all sessions would start and report their achieved throughput, even when the total demand exceeded the link capacity.
Are there any tools, flags, or recommended patterns in recent versions of iperf3 that would allow me to restore this capability?