perfSONAR User Q&A and Other Discussion

[Mark Feit <>]

Louis-Berthier Soullière writes:

 

I restarted the httpd service and it is now working.

 

But I got another error when doing the troubleshoot (btw, i changed the MTU on the interfaces of both server to 1460)

 

localhost: 

  Checking clock... OK.

 

10.x.x.1 : 

  Checking clock... OK.

 

This is fine; it means both ends think their clocks are in synchronized.  And they probably are.

 

Good call on the MTU fix.  Mismatches can cause all kinds of hard-to-run-down problems and is actually the reason why the troubleshooter tests for that.

 

localhost and 10.x.x.2 : 

  Simple stream test.... 9 seconds.... Failed.

 …

This run likely failed because the clocks on participants differed by 0:00:01.941681.

 

When a run involving two hosts fails, pScheduler surveys all of the clocks involved and checks to see how close they are.  Unfortunately, it does so sequentially instead of in parallel, so the difference is magnified a bit and more so when latency is high.  (There’s a note to make it parallel buried in the code.)

 

I even tried to switch to chrony because it is suppose to handle the network latency better (satellite), no luck.

 

We don’t support chrony (yet) because it doesn’t have a nice programmatic way to get its status like NTPD has.

 

At any rate, I suspect a lot of this has to do with the latency.  Most of the system’s assumptions are based on worst-case terrestrial time.  If there’s sufficient demand for it, we can consider adjusting some of the assumptions, but it will come at the cost of some tests occupying more schedule time, even in low-latency environments.  There may be some other ways to work with it, which will take some thought.

 

--Mark