perfSONAR User Q&A and Other Discussion

[Mark Feit <>]

Zhi-Wei Lu writes:

 

I just wonder if perfsonar's iperf3 throughput test just uses the default iperf3 settings or it has some set of perfsonar default flags.

 

Most of the tool plugins provide diagnostic information that can be retrieved using the “pscheduler result” command:

 

$ pscheduler result --diags https://...RUN URL...

...

Diagnostics from localhost:

  /usr/bin/iperf3 -p 5201 -c ps.example.edu -t 10 --json

  ...

Diagnostics from ps.example.edu:

  Unable to use NUMA for eth1.  Disabling it.

  /usr/bin/iperf3 -s -1 --json -p 5201

  ...

 

This will allow you to see what was invoked for a given test.

 

If I want to use psheduler task throughput test, how can I pass additional iperf3 flags?

 

You can’t.  One facet of pScheduler’s architecture is the abstraction of how the measurement is described (the test) from the inner workings of the program that carries it out (the tool).  Generally, when a new test is designed, we identify the tool(s) that will be used to carry them out and cover as many of their options as possible.  If there are new tools with new options or options we overlooked during development, they can be added.  (For example, we’re adding support for nuttcp’s strict bandwidth and burst size features in 4.3 with new test parameters called strict-bandwidth and burst-size.)  If we missed something, please write a bug and we’ll get it included.

 

Additionally, there are security hazards in allowing remote users to provide arbitrary arguments that could override restrictions imposed by the limit system.

 

If you’re using PWA, it doesn’t cover 100% of the test options.  For a future release, we’re looking at ways to close that gap so PWA doesn’t have to be rewired each time something changes.

 

--Mark