perfSONAR User Q&A and Other Discussion

[Louis-Berthier Soullière <>]

Hi Mark,

 

After some debugging, I now get a "Run did not complete: Missed"

 

The schedule task seems to run now and then (30 minutes interval but the graph show a very unconsistent delay between test despite the fact that it is the only test running on those 2 servers).

 

What could be causing this? The latency is pretty stable…

 

I only have a OWAMP and this task between the two host. I tried to disable the OWAMP, wait for the task to disappear and do a troughput test manually but no luck.

 

 

Thanks!

 

Louis-Berthier Soullière

 

De : Mark Feit [mailto:]
Envoyé : 16 juillet 2019 18:01
À : Louis-Berthier Soullière <>;
Objet : Re: [perfsonar-user] Encountered end of file

 

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