perfSONAR User Q&A and Other Discussion

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

My host is not publicly accessible (iptables restricted) but I’m sure bwctld is running because I’m testing to/from a whole lot of places with it.  The pscheduler client is in another lab so there might be an intervening FW in the path that I’m not aware of.

From: Brian Tierney <>
Reply-To: "" <>
Date: Wednesday, February 8, 2017 at 2:24 PM
To: George Uhl <>
Cc: "" <>
Subject: Re: [perfsonar-user] perfSONAR 4.0 RC3 update

The pscheduler server will first try port 443 on the remote host, and then try the bwctl port next.

Are you sure the bwctl is running and the port is open on host 169.154.197.28?
I'm getting this error connecting to you:

>bwctl -c 169.154.197.28

bwctl: Unable to connect to 169.154.197.28

On Wed, Feb 8, 2017 at 10:50 AM, Uhl, George D. (GSFC-423.0)[SGT INC] <> wrote:

What about psScheduler testing to instances of bwctld on hosts that aren’t listening on 443?  Am I missing something about backward compatibility?

From: <> on behalf of Brian Tierney <>
Reply-To: "" <>
Date: Wednesday, February 8, 2017 at 1:42 PM

To: George Uhl <>
Cc: "" <>
Subject: Re: [perfsonar-user] perfSONAR 4.0 RC3 update

pscheduler needs to connect on port 443, and then will launch bwctl as needed.

On Wed, Feb 8, 2017 at 10:27 AM, Uhl, George D. (GSFC-423.0)[SGT INC] <> wrote:

I tried that command but it didn’t work.  

$ pscheduler task throughput --dest 169.154.197.28

Submitting task...

Unable to determine the lead participant: Can't find pScheduler or BWCTL on 169.154.197.28

Tcpdump on the bwctld host reveals:

# tcpdump -i p2p1 -nn host x.107.195.203

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on p2p1, link-type EN10MB (Ethernet), capture size 65535 bytes

13:19:56.513686 IP x.107.195.203.38816 > x.154.197.28.443: Flags [S], seq 432656405, win 42340, options [mss 1460,sackOK,TS val 2602361819 ecr 0,nop,wscale 14], length 0

13:19:56.513738 IP x.154.197.28.443 > x.107.195.203.38816: Flags [R.], seq 0, ack 432656406, win 0, length 0 

13:19:57.573654 IP x.107.195.203.38816 > x.154.197.28.443: Flags [S], seq 432656405, win 42340, options [mss 1460,sackOK,TS val 2602362880 ecr 0,nop,wscale 14], length 0 

13:19:57.573704 IP x.154.197.28.443 > x.107.195.203.38816: Flags [R.], seq 0, ack 1, win 0, length 0 

13:19:59.621673 IP x.107.195.203.38816 > x.154.197.28.443: Flags [S], seq 432656405, win 42340, options [mss 1460,sackOK,TS val 2602364928 ecr 0,nop,wscale 14], length 0 

13:19:59.621724 IP x.154.197.28.443 > x.107.195.203.38816: Flags [R.], seq 0, ack 1, win 0, length 0 

^C

So if pScheduler fails to connect on 443 is it supposed to try 4823?

From: Brian Tierney <>
Reply-To: "" <>
Date: Wednesday, February 8, 2017 at 11:36 AM
To: George Uhl <>
Cc: "" <>
Subject: Re: [perfsonar-user] perfSONAR 4.0 RC3 update

It should work fine. What command are you using?

For example, this works from a 4.0 host to a 3.5 host:

pscheduler task throughput --dest receive_host

On Wed, Feb 8, 2017 at 7:19 AM, Uhl, George D. (GSFC-423.0)[SGT INC] <> wrote:

Hi,

I installed the perfsonar-tools package for pS 4.0 but I’m unable to get pScheduler to test with BWCTL.  I thought there were tool plugins for pScheduler to support this.  Are they available in the perfsonar-tools package?

Thanks,

George

--

Brian Tierney, http://www.es.net/tierney
Energy Sciences Network (ESnet), Berkeley National Lab
http://fasterdata.es.net

--

Brian Tierney, http://www.es.net/tierney
Energy Sciences Network (ESnet), Berkeley National Lab
http://fasterdata.es.net

--

Brian Tierney, http://www.es.net/tierney
Energy Sciences Network (ESnet), Berkeley National Lab
http://fasterdata.es.net