perfSONAR User Q&A and Other Discussion

[Mark Feit <>]

Phil Reese writes:

     The pscheduler-runner.service does seem to 
    have a long list of CGroup lines.  A simple 'systemctl restart 
    pscheduler-*' has solved the problem in three out of three cases. 
    Probably not normal behavior, is it?

You should have one cgroup with one process underneath for each run underway 
plus any additional processes those processes start.  If you're seeing 
something different, please send it to me and I'll have a look.

If you're having whole rows go orange, I'd recommend looking at past runs on 
one of the hosts where you're losing measurements with the 'pscheduler 
schedule' command to see if the lost measurements are actually happening.  If 
they are, pick a run URL from one of them and do a 'pscheduler result --diags 
--archivings <URL>' to see if the archiving(s) to Esmond succeeded.  If it 
did, the problem isn't with pScheduler.

NB:  The limit configuration released in 4.2.0 gives tasks requested by 
friendly requesters (interfaces on the local system) a priority bump.  This 
causes the receiving end of some throughput measurements not to run because 
of scheduling conflicts that arise when another throughput measurement that 
was requested by the receiving-end system preempts it.  It didn't occur to me 
that this would be a side effect in systems with larger meshes, so it's being 
turned off in the soon-to-be-released 4.2.1 and will stay that way until we 
figure out a way to make it play nicely.  There are some trust issues that 
have to be handled in limits files and getting everyone in the mesh in sync 
with that may be difficult.

If you're running a custom limit configuration that integrated that change, 
you can undo it by removing the lines in red shown here:  
https://github.com/perfsonar/toolkit/commit/a1769663b809b75e6d3e0da9fef28ac4a5482bb3#diff-e45026494425c50f20d09d1ff570b9e7.


    
    What and where is the place to add options to the throughput tool command 
line?

Szymon gave you a good practical answer, let me add one that's philosophical: 
 there isn't one.  pScheduler abstracts tests so they don't become a proxy 
for each tool and all of their idiosyncrasies.  That's why you run a 
throughput test and not an iperf3 test, although you can ask that a specific 
tool be used if you have a preference.

When we develop a new test plugin, we do a survey of the tools that will be 
used with it and try to include test parameters to match as many of the tool 
options as we can.  There should be parameters in the throughput test to 
cover just about everything in iperf3, which is currently the most-capable 
throughput tool we support.  If you ask for a parameter a tool can't support, 
it won't list itself as being able to run that test.

You can find out what the parameters for a test are by running "pscheduler 
task <TEST-TYPE> --help" and looking at the long-form option names.  They 
match the names of the pairs in the JSON version.  (Or, if you're as lazy as 
I am, "pscheduler task --export throughput --dest foo.bar.org --omit PT5S 
..." will get you a blob of JSON with the test spec in it.)

HTH.

--Mark