perfSONAR User Q&A and Other Discussion

[Alan Whinery <>]

Hi Jim,

It took me a bit to digest your meaning. I apologize in advance, you
just happened to ask a question about something I've been staring at. A
lot. We should have talked about this in Alaska...

The j-word is one of those things that induces confusion, especially
around NTP, where there are at least two meanings of "jitter", and one
is often cited as being the other.

And you seem to be referring to neither one.

Such symmetrical wandering* in path delay between two owamp end-points,
which indicates changing clock offset on one, or the other or both tends
to show at least one side is using either a network peer, or no
discipline. Clock errors tend to mirror across the X axis, whereas path
delay trends tend to both go up or down, graph wise.

Does the Stanford side have a hardware reference clock?

ndt.ucsc.edu looks like this from here:

>      remote           refid      st t when poll reach   delay   offset  
> jitter
> ==============================================================================
> *ntp1.ucsc.edu   .CDMA.           1 u  403 1024  377    0.996   -0.032   
> 0.053

Which suggests that ndt.ucsc.edu has no hardware clock(?).

If ndt has only network peer discipline, owamp host will not have an
appropriately steady NTP loop to evaluate at such low-delay paths. There
will be several orders of magnitude between clock errors in a machine
with a local hardware clock versus one using only network peers, no
matter how quiescent any of the network peers are.

I just stumbled onto a particularly illustrative owamp graph here --
which I attach. Looks like about noon-ish, one or the other of the
clocks re-gained its reference, so you can see that when one's unlocked,
it looks like yours, when both are locked, it is considerably steadier.
Both ends have directly attached CDMA clocks. So yes, if you want to
stop all that wandering*, you will probably have to attach a hardware
clock to the owamp server. For almost all NTP applications, I point out,
a few milliseconds of accuracy is great. For owamp it is not. You might
consider moving the hardware clock to ndt.ucsc.edu, and let
ntp1.ucsc.edu peer with ndt.

Many, many notes:

http://net.its.hawaii.edu/network-performance/using-praecis/

(ignore PPS, it's not worth it)

* I don't mean "wander" in the NTP sense.

-Alan

On 8/3/2011 2:27 PM, jim warner wrote:
> http://people.ucsc.edu/~warner/clock-jitter.PNG
> 
> Is this "Hey, great! You've only got 200 uSec of jitter.  Good news"
> 
> --or--
> 
> "Wow, you've got 200 uSec of jitter!  You should go fix something"
> 
> I don't have any feel for whether this is as good as NTP gets, or this
> is really terrible and I should get a new CDMA clock or something.
> How much of this kind of jitter are others seeing?
> 
> Advice?
> 
> thanks
>

Attachment: Re-lock.png
Description: PNG image