perfSONAR User Q&A and Other Discussion

[Mark Feit <>]

Michael C Tiernan writes:

Thanks for the reply Mark. I'm trying to field answers from folks who are asking a lot of "Why" and "How come" questions that I simply don't have the answers for.

This is the right place to bring those.  :-)

1.      The most common one so far...
I attempt to go to the other end of a test, in this case "psonar3.fnal.gov' and it returns an error message (attached as "perfSONAR Toolkit psonar3.fnal.gov.png") that says:
Error loading test listing; measurement archive unreachable:
http://psonar3.fnal.gov/esmond/perfsonar/archive/

N.B. We can even get that message from our system at times.

I pulled that URL and got a 500 with “The server encountered an internal error and was unable to complete your request. Either the server is overloaded or there is an error in the application.”  You’d have to get in touch with Fermi and have them look at the Apache logs to see what’s going on there or have a look at your own system if you’re seeing that error.

For now, anyway, perfsonar02.cmsaf.mit.edu appears to be working and has measurements in it.

2.      The reason I went to that system to look at traffic back to our site is because when I pull up the graph of the traffic BW measurement, it shows a throughput line
(attached as "pS_results_between_18.12.1.172_and_131.225.189.73-A.png")
and it has the IPv4 throughput graph but if you click the display of the "Forward" data off
(see "pS_results_between_18.12.1.172_and_131.225.189.73-B.png")
you get NO reverse data. This is not the way it has been working in the past and it seems to "break" (for lack of a better term) the ability to look at the traffic "overlaid" so that abnormalities can be correlated easily and accurately. (And if the data is zero then it should show as a flat line at "0" IMNSHO)

What ends up in the local system’s archive depends on what’s being measured there and whether or not those measurements are succeeding.

I pulled the last 12 hours of measurements out of  perfsonar9.fnal and found that throughput measurements from there to perfsonar02.cmsaf were succeeding and being successfully sent to two archives.  (I can’t tell what archives  because pScheduler treats that information as confidential and won’t let me pull it out through the API.)  The opposite measurements  are successful and are being archived to two HTTP destinations and one Esmond destination.  The HTTPs on that system are succeeding but the Esmond one, which is pointed at the local machine, isn’t.  That may have to do with the fact that, after 5.0, we removed Esmond and replaced it with LogStash and OpenSearch.  There’s a compatibility layer called Elmond, but it’s read-only.

I can look at it in more depth tomorrow if that doesn’t get you pointed in the right direction.

Both machines are running the docker version of the pS toolkit.

The only Docker container we’ve ever released and supported is the testpoint bundle, so I have no idea what would be running on those systems.

--Mark