perfSONAR User Q&A and Other Discussion

["Uhl, George D. (GSFC-423.0)[Arctic Slope Technical Services, Inc.]" <>]

Mark/Ed,

 

I went ahead and tried to add the TCPping client into the suite of pscheduler tools for RTT.  Using subversion, I downloaded the latest trunk branch of the pscheduler package off github and followed the instructions provided here: https://github.com/perfsonar/pscheduler/tree/master/scripts/PDK. I completed steps #1 and #2 but I’m stuck on #3.  I don’t see anything called “cbic” anywhere in the package.    If I don’t need to do that step, how do I get my tool recognized by pscheduler?

 

Thanks,

George

 

From: Mark Feit <>
Date: Friday, January 29, 2021 at 3:56 PM
To: "George.D.Uhl" <>, "" <>
Subject: Re: [EXTERNAL] Re: [perfsonar-user] Adding homegrown tools to perfsonar

 

Uhl, George D. (GSFC-423.0)[Arctic Slope Technical Services, Inc.] writes:

 

I gave twping a try and also  pscheduler task rtt with the protocol set to twamp but neither worked. 

 

There needs to be a TWAMP service running at the far end (same as with OWAMP) and, of course, no network obstructions.  Any perfSONAR node should be twping-able.

 

In our case we were looking to adopt TCPping as a TCP-based RTT, single-ended tool into our perfsonar test mesh under the following conditions:

1.       Single-ended iperf/iperf3 tests are already supported to a remote datasink daemon at that site.

2.       The remote firewall is blocking incoming icmp pings.

 

That simplifies things considerably and puts it in the realm of “we can do that.”  The example you showed looks similar enough to ping that pScheduler’s ping tool plugin could be used as starting point.

 

The only thing missing is a provision in the RTT test to specify a port number, but if you can live with your program’s default, that’s not an impediment.  There’s a sneaky workaround that could be used for experimentation that I won’t mention here.  :-)

 

I don’t know how useful TCPPing/datasink are to other people since these were conceived as a single-ended test system but I don’t see why they couldn’t be used as part of the bidirectional perfsonar test environment.

 

There are a few alternatives:

 

1. Develop the plugin internally and install it on your systems.  pScheduler will treat it the same as anything we ship and, of course, systems without it will look at you funny if you ask for that tool.
2. Develop the plugin, release your tool and perfSONAR adopts it in the next feature release.  If it becomes part of the system, I’d have no problem adding parameter(s) to the RTT test to support the additional capability.
3. If you can’t release the tool, consider some other implementation, write a plugin for that and we’ll adopt it.  Here’s one I found randomly written in Go that could be evaluated for suitability:  https://github.com/cloverstd/tcping.

 

For points 2 and 3, every plugin we add makes perfSONAR even more versatile, and I’m all for that.  Let me know how you want to proceed.

 

--Mark