perfSONAR User Q&A and Other Discussion

[Mark Feit <>]

Xiao Wang writes:
    
    I don't have these packages you mentioned and i do not see any of those 
in /etc/pscheduler/tool. I was doing a fresh install after all. Are there 
other reasons might cause this?

Sorry, I misspoke.  The production code does still have some of the backward 
compatibility features that can't be removed until all support for BWCTL has 
been discontinued.  This includes the part of throughput test plugin that 
determines what perfSONAR nodes are participants in the test.  That 
determination is supposed to be made based just on the test specification 
data (and should therefore go very quickly), but one of the compromises we 
made for the sake of backward compatibility was having a few of the test 
plugins actively test whether or not pScheduler and/or BWCTL are present on 
the destination side.

The sequence for this first probing for pScheduler on the destination side at 
the address and port supplied and then probing for BWCTL on port 4823.  Most 
times, goes quickly enough because connection failures don't usually take 
long.  However, if something in the network (often ACLs or firewalls) causes 
the process to drag on, the code in the plugin will run longer than the 
five-second timeout built into pScheduler and you'll get the "took too long" 
error.

One thing you could do to see if that's the cause is to get on your source 
host (xxx) and run the following:

    $ curl -skL https://yyy:9443/pscheduler
    "This is the pScheduler API server on yyy (yyy)."

    $ nc yyy 4823
    Ncat: Connection refused.

If either (my money would be on the second one) takes a long time to 
complete, something between the hosts is dropping packets and causing the TCP 
handshake process to run long.

--Mark