Final interval report always delayed until result exchange

[illarionov]

Current behavior

The final interval report is currently emitted only after the EXCHANGE_RESULTS phase. On high-latency links, this causes the last report to arrive much later than previous reports, breaking the uniform interval spacing. Most of this data is already included in the final summary, reducing its usefulness.

Steps to reproduce

1. Use a server with high network latency. On Linux, this can be emulated by adding artificial delay (e.g. via tc netem):

$ sudo tc qdisc add dev lo root handle 1: prio
$ sudo tc qdisc add dev lo parent 1:3 handle 30: netem delay 250ms

$ sudo tc filter add dev lo protocol ip parent 1:0 prio 3 u32 match ip dport 5201 0xffff flowid 1:3
$ sudo tc filter add dev lo protocol ip parent 1:0 prio 3 u32 match ip sport 5201 0xffff flowid 1:3

$ ./iperf3 -s -p 5201

2. Run iperf with a low reporting interval, JSON output, and timestamps:

./iperf3 -c 127.0.0.1 -p 5201 -t 2 -i 0.5 --json-stream | ts -s -m '%.s'

3. Observe the interval reports in the output. Example snippet:

2.490441 {"event":"start","data":{"connected":[{"socket":5,"local_host":"127.0.0.1"…
2.990999 {"event":"interval","data":{"streams":[{"socket":5,"start":0,"end":0.500543,"seconds":0.50054299831390381,…
3.490966 {"event":"interval","data":{"streams":[{"socket":5,"start":0.500543,"end":1.000544,"seconds":0.50000101327896118,…
3.990976 {"event":"interval","data":{"streams":[{"socket":5,"start":1.000544,"end":1.500556,"seconds":0.5000119805336,…
5.491367 {"event":"interval","data":{"streams":[{"socket":5,"start":1.500556,"end":2.00072,"seconds":0.500163972377777,…
5.991516 {"event":"end","data":{"streams":[{"sender":{"socket":5,"start":0,"end":2.00072,"seconds":2.00072,…

Note that the first interval reports are output every 0.5 seconds, but the final interval report is delayed by 1.5 seconds from the previous one, as it is emitted only after the results exchange phase.

Desired behavior

Emit the final interval report immediately after the test ends, before result exchange, to maintain uniform reporting intervals.

Version

iperf 3.20+ (cJSON 1.7.15)
Linux alexey 6.8.0-106-generic #106-Ubuntu SMP PREEMPT_DYNAMIC Fri Mar  6 07:58:08 UTC 2026 x86_64
Optional features available: CPU affinity setting, IPv6 flow label, TCP congestion algorithm setting, sendfile / zerocopy, socket pacing, authentication, bind to device, support IPv4 don't fragment, POSIX threads, GSO/GRO support

[davidBar-On]

Why is the delay in the last report an issue? Is it causing problems?
It may be the the delay in the report was done to allow late arriving messages to be included.

[WatcherOfTheSkies]

I am another user where low latency networks (GSM over wwan) is effected by this issue. If there is a 10 second test, intervals 1 to 9 are seemingly processed differently to second 10 and the results.

I think that iperf3 suffers with high latency because the default parameters are too ambitious for the system. Iperf appears to confirm you can achieve your target throughput, not measure the maximum throughput you can get like ookla for example.

[illarionov]

@davidBar-On, I use iperf3 output to render a progressively revealed animated graph as new interval values arrive. When the last interval is delayed, either the animation becomes less smooth or I need to add more pre-buffering to hide the gaps.
I also considered that the delay might be intended to include late-arriving messages. However, I could not find anything that would actually affect the already completed final interval. From what I can see, its values are not updated after the interval ends.
I might be missing something, but I wasn’t able to identify a reason why postponing the last interval report is necessary.

[davidBar-On]

@illarionov, @WatcherOfTheSkies Thanks for the explanations. I have created a branch with a proposed solution in my private repository. Are you able to build from this branch and test it in your systems with the delays?

Preferably the tests should also include -R, --bidir, something like -t5 -i2 for test end during an interval. In addition of testing whether the issue is fixed, the purpose of the tests should be to make sure that nothing was broken compared to the official iperf3 version.

[illarionov]

@davidBar-On Thanks for the work on this!
I tested the version from your branch, and the issue appears to be fixed: the final interval is now emitted without delay.
I also tried it against several iperf servers, including runs with -R, --bidir, and -i2, and I did not notice any regressions or behavioral differences compared to the official iperf3 version.

[WatcherOfTheSkies]

I can now see the final interval being reported without delay.

[davidBar-On]

@illarionov, @WatcherOfTheSkies, thanks for testing. I have submitted PR #2025 with the change.