Skip to Content.
Sympa Menu

perfsonar-user - Re: [perfsonar-user] [EXTERNAL] Re: Adding homegrown tools to perfsonar

Subject: perfSONAR User Q&A and Other Discussion

List archive

Re: [perfsonar-user] [EXTERNAL] Re: Adding homegrown tools to perfsonar


Chronological Thread 
  • From: Mark Feit <>
  • To: "Uhl, George D. (GSFC-423.0)[Arctic Slope Technical Services, Inc.]" <>, "" <>
  • Subject: Re: [perfsonar-user] [EXTERNAL] Re: Adding homegrown tools to perfsonar
  • Date: Fri, 29 Jan 2021 20:56:26 +0000

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

 




Archive powered by MHonArc 2.6.24.

Top of Page