Iperf: 1-hour run limitation and stats interval in JSON output
Hi,
I am trying to run an iperf3 test between several (up to 70 once properly working) hosts in a full-meshed fashion. I want it to run for a day, but at this stage the max running time is 1 hour. Unfortunately due to the server limitation of max one simultaneous iperf3 instance/run per port I am not able to get the result I need for a complete daily test. Is there a way to change this limit? I'm afraid I'm not into programming.
Another question is about the stats output (jitter for example) in a JSON file: it is printed only at the end of the run and not as frequent as the interval. Is there a way to change this behaviour? As above I don't have any programming skills.
Thanks so much.
Regards
Federico
fefone
All 5 comments
The maximum running time limit is set by the constant MAX_TIME in src/iperf.h. Changing that would change the maximum value that can be specified on the command-line. @bltierney and I discussed this, and we think the maximum should definitely be higher, because there are some good use cases for running tests longer than an hour, although we're not sure exactly how much higher. Maybe we might go to 1 day (86400).
The JSON can only be displayed at the end of the run because, as the JSON results are currently structured, it's not possible to display a partial result.
Marking this for 3.0.x for increasing the MAX_TIME parameter.
bmah888
on 9 May 2014
Hi Bruce,
Thanks. About the JSON output: I understand it is written all at the end, but my question was about another subject, but I solved this. In fact one of my colleagues noticed that server and client outputs are different: the one from server has jitter printed according to the interval, while the one from client has it only at the end and calculated over the whole run. So we solved using the server's output, but perhaps you want to check the reason of this difference.
Regards
Federico
fefone
on 11 May 2014
Jitter statistics are currently only available on the server because that's where they're generated. There's an outstanding issue (#160) for the client and server to exchange more data at the end of the test so each has a more complete set of results.
bmah888
on 12 May 2014
Can I politely ask why set an upper limit on test duration at all?
Yakkity
on 2 Nov 2016
@Yakkity: We wanted to avoid the danger of having high-bitrate streams run essentially forever. Someone who has a real need for this should be able to modify the code (it's trivial).
bmah888
on 17 Nov 2016
Related issues
travis1230
·
4Comments
Febbe
·
4Comments
fl4w
·
5Comments
bbordereau
·
10Comments
Surendraknatarajan
·
9Comments
Most helpful comment
@Yakkity: We wanted to avoid the danger of having high-bitrate streams run essentially forever. Someone who has a real need for this should be able to modify the code (it's trivial).