perfSONAR User Q&A and Other Discussion

[Mark Feit <>]

Chris Konger - NOAA Affiliate writes:

I'm curious  whether anyone has successively created a pscheduler single-ended task using nuttcp? What I find odd is it claims to be attempting iperf3 and iperf2 despite my explicitly telling it to use tool nuttcp and which command port to use.

  > pscheduler task --tool nuttcp throughput --single-ended --single-ended-port=65000 -t 300 -s x.x.x.1 -d x.x.x.101 -l 7900 -u -w16m -b 5G
  Submitting task...
  Failed to post task: Unable to complete request: No tool in common among the participants:  x.x.x.1 offered iperf3, iperf2.  [note: I asked for nuttcp!]

 

The nuttcp plugin doesn’t have support in it for single-ended testing.  I don’t think it was me that added support for single-ended throughput testing, but whoever did gave Nuttcp the short end of the stick.  That’s easy to correct, and I have a ticket open on it:  https://github.com/perfsonar/pscheduler/issues/1008.

 

About why you were shown iperf[23]:

 

Tests and tools are separate things in pScheduler.  Tests are abstract descriptions of what’s going to be measured (e.g., “single-ended throughput between these two points with a maximum bandwidth of 5 Gbps run for 30 seconds”).  All tests understand is themselves; they have no concept that tools or any other part of pScheduler exists.  Tools are what carry out the tests.  Each tool plugin tells pScheduler what tests it’s capable of running and has a mechanism where pScheduler can run a test by it to determine whether or not it can run a test with a specific set of parameters.  That’s what lets us have tools of varying capability without having to constrain everything to the lowest common denominator.

 

When a task is submitted, pScheduler figures out who’s involved (the participants) and sends the test to the participants, who return a list of the tools they have installed that can run it.  (The word “installed” is important.  If someone decides that iperf3 is a hazard and removes the plugin, pScheduler on that host will become blissfully unaware that it exists.)    The returned list(s) are used to figure out what tools all of the participants have in common that can run the test as-specified.

 

In your case, the throughput task had one participant (x.x.x.1) and used a feature that the nuttcp plugin doesn’t support.  When x.x.x.1 was asked about running that task, iperf2 and iperf3 stepped up to the plate and nuttcp took a hard pass.  Because nuttcp was specifically requested, pScheduler had no choice but to punt and say it couldn’t do it.    The “offered x, y, z” diagnostic is there to let you know what the options are.

 

--Mark