perfSONAR User Q&A and Other Discussion

["Uhl, George D. (GSFC-423.0)[SGT INC]" <>]

Hi Mark,

 

Adding the reverse option into the test specification is reversing the test but it’s doing it in both directions.  What I’m getting between managed hosts (a-addresses) and non-agent host (b-addresses) with the reverse option is something like this:

 

pscheduler task throughput  --source <a-address> --dest <b-address> --reverse

pscheduler task throughput  --source <b-address> --dest <a-address> --reverse

 

What I’m trying to achieve is the to set up throughput tests based on something like this:

 

pscheduler task throughput  --source <a-address> --dest <b-address>

pscheduler task throughput  --source <a-address> --dest <b-address> --reverse

 

This allows me to run tests in both directions when “pscheduler task throughput  --source <b-address> --dest <a-address>” fails due to an error.  Given the default behavior for tests run against disjoint groups, I’m thinking I need to create a group that is defined as unidirectional and create two separate tasks – one that runs throughput tests with the reverse option set and the other without it.

 

It’s kinda ugly but it should work. Am I missing a “cleaner” approach?

 

Thanks,

George

 

 

From: Mark Feit <>
Date: Wednesday, May 8, 2019 at 3:16 PM
To: "George.D.Uhl" <>, "" <>
Subject: Re: [perfsonar-user] Specifying reverse iperf3 throughput tests in a psconfig template

 

"Uhl, George D. (GSFC-423.0)[SGT INC]" writes:

 

I’ve not been able to find a psconfig template variable in the throughput test type specification that allows me to request that iperf3 tests run with the “—reverse” option between a managed host and a non-agent host.  I know the flip variable is available for latencybg tests.  Can it be used in throughput tests with the same behavior?

 

The JSON that goes into a pSConfig test template is the same JSON that the test spec that “pscheduler task --export throughput …” would produce.  Any parameter available for that test (or any other) is available for pSConfig, too.  The throughput test has a “reverse” option (see “pscheduler task throughput --help”) that can be put into a template:

 

{

    "dest": "{% address[1] %}",

    "reverse": true

}

 

(Unlike MeshConfig, which had to be reprogrammed for new things, pSConfig doesn’t actually understand anything about tests.  Anything test-related is punted to pScheduler.)

 

 

I’m running into occasional cases where iperf3 tests sourced from the non-agent host are failing…

 

They should fail.  A lot, actually.  pScheduler only runs the iperf3 server during times when there’s a test to run.  Any success you’re seeing with that may be at the expense of other tests arranged by pScheduler.  The iperf3 plugin doesn’t currently enforce any kind of authentication to prevent it, but I just wrote a ticket to fix that in a future version.  :-)

 

 

…but they succeed if they’re run from the managed host when the reverse option is set.  Controlling bi-directional tests from a managed host to a non-agent host would work for me in these cases.

 

That’s the correct behavior.  When a single-ended throughput test is run in reverse, the iperf3 plugin still starts the client locally but passes a switch to iperf3 that tells it to request data transfer in the reverse direction instead of the usual forward.

 

We have no way to convince a non-pScheduler host to run the iperf3 client.

 

--Mark