perfSONAR User Q&A and Other Discussion

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

Hi Mark,

 

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

 

The test I’m trying to implement is single-ended where I have a client tool called TCPping (derived from TCPWatch and developed in house years ago) that “rides” on the same port as an iperfX test.  This was developed as a quick way to get around firewalls that would allow iperfX traffic but block icmp pings.  Getting firewall rule changes at other institutions to support our tests has not always been successful or timely.

 

Running TCPping requires a sever application called datasink to run on the remote end.  What’s handy about datasink is that it supports incoming tests from clients using  iperfX and TCPping which is a nice one-size-fits-all alternative to running independent iperfX daemons.  The datasink developer claims that his tool is more stable than iperf3 which, if true, would make it an effective alternative to running iperfX daemons. 

 

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.

 

We have a significant number of single-ended throughput tests in our perfsonar mesh that we’ve migrated over from our old Ensight network performance test environment  incorporating TCPping as another pscheduler RTT client tool would be very useful.

 

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.

 

Here is an sample of TCP ping output which is similar to icmp ping:

 

# TCPping -p 5001 -c 2 tlscf.jpl.nasa.gov

TCPping tlscf.jpl.nasa.gov (137.78.248.93): 2 pings 21 bytes

21 bytes from tlscf.jpl.nasa.gov (137.78.248.93): seq=0 time=91.261 ms

21 bytes from tlscf.jpl.nasa.gov (137.78.248.93): seq=1 time=91.874 ms

 

--- tlscf.jpl.nasa.gov (137.78.248.93) TCPping statistics ---

rtt min/avg/max = 91.261/91.568/91.874 ms

 

Thanks for your support,

George

 

From: <> on behalf of Mark Feit <>
Reply-To: Mark Feit <>
Date: Friday, January 29, 2021 at 10:49 AM
To: "George.D.Uhl" <>, "" <>
Subject: [EXTERNAL] Re: [perfsonar-user] Adding homegrown tools to perfsonar

 

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

 

I’m looking to add a homegrown tcp based RTT tool to perfsonar as a plugin.  I’m really having a hard time finding documentation on how to do this.  Is there a good reference on how to add new tools to perfsonar?

 

Most of the process is institutional knowledge, and we’re not to the point where we have a document suitable for anyone to pick up and use.  The pScheduler sources include a plugin development kit (PDK) that provides a skeleton that can be used for developing new plugins.   Implementing a new tool for an existing test isn’t difficult, and I’d be happy to walk you (and anyone else who wants to sit in) through the process using the PDK.

 

If your tool is TCP-based and requires a server running at the far end as the throughput tools do, that’s going to be a non-starter.  RTT is currently a single-participant test and there’s no way to shoehorn a two-participant test into it without create a separate-but-similar test.  (That said, making the selection of participants tool-based rather than test-based is an architectural change that would be some work, but not a back-breaker.)

 

Also note that the twping tool can do RTT and might be a good middle ground between ping and your tool.

 

--Mark