option to run a test to an iperf3 server directly

[bltierney]

possible enhancement for 4.1: The ability for a 'perfsonar-testpoint' host to be able to run a throughput test to/from a host just running an iperf3 server, and no pscheduler.

The iperf3 server will only accept 1 test at a time, so if the test fails, there should be an error message that says "server busy, try again later" and/or an option to automatically retry later.

[mfeit-internet2]

See https://lists.internet2.edu/sympa/arc/perfsonar-user/2017-05/msg00098.html for commentary on how to do this with the current system.

I suppose we could alter the throughput test to allow single-ended testing in one direction.

[laeti-tia]

I think it would be nice to be able to schedule recurring throughput measurements to a standalone iperf3 server, and be able to archive and plot these measurements with the toolkit. This way we could do measurements to hosts not running perfSONAR nor pscheduler but only iperf3, possibly under powered hosts or hosts running other OS that the ones supported by pscheduler/perfSONAR.

[laeti-tia]

@mfeit-internet2, @arlake228 can we revisit this for 4.1 by having the iperf3 tool plugin able to support a single participant test like owping does (IIRC from our discussion in the F2F)? If yes and this is a relatively easy task, you can assign it to me.

[mfeit-internet2]

Discussed this during yesterday's call. It can probably be done without too much heartburn.

We'd need to add a --single-ended switch to the test and modify the participants method to produce a list of one or two depending on whether or not it's present.

The tool(s) would need to decline single-ended tests if they're not equipped to handle it. For the iperf2/3 case, the tool would have to check and see if it's a one- or two-participant test and assume the default ports. (The iperf tool's second participant puts a server_port item in the participant data that's consumed by the first.) I do not want to get into the business of doing tool-specific parameter pass-throughs in tests, because I think it's the wrong way to go about it.

We also need to make it clear in the docs that tests in this mode are done subject to the submitter understanding what the tool's defaults are and having the non-pScheduler end set up correctly.

[laeti-tia]

All merged. We also probably need some options in the toolkit GUI to be able to add such a test from there too.