perfSONAR User Q&A and Other Discussion

[Jason Zurawski <>]

Hi Jim;

I am wading into this late, so apologies for backtracking a bit.

The picture you sent originally is measuring latencies between hosts 
that are about 2ms away from each other it appears.  While the peaks and 
valleys do look very troublesome, bear in mind the scale of the graph - 
its a fluctuation of only .5ms in either direction.  Because OWAMP is 
such an exact tool I would write this off as 'noise' for all intents and 
purposes.  As an example of a longer path, look at your test results to 
UNC or BU, there are minor clock corrections still visble in the data, 
but things appear much flatter because the scale is larger.

I agree with Alan's assessment that a hardware clock can give you rock 
solid results, the tradeoff being the need to purchase and maintain it 
(both are not desirable just to get some OWAMP measurements for many 
people).  Having the hardware clocks attached directly on the 
perfSONAR-PS nodes  also doesn't seem like the best way to approach this 
- if you have other machines at UCSC constantly polling the nodes for 
the NTP reference time (something I assume that the existing NTP server 
with the hardware clock is used for now) the measurements will begin to 
show signs of this network activity.

I took a look at your complete NTP situation:

> [zurawski@ndb1
>  ~]$ ntpq -p -c rv ndt.ucsc.edu
>      remote           refid      st t when poll reach   delay   offset  jitter
> ==============================================================================
> +ntp.ucsc.edu    .GPS.            1 u  453 1024  377    0.924    0.146   0.038
> *ntp1.ucsc.edu   .CDMA.           1 u  423 1024  377    0.993    0.095   0.019
> -nms-rlat.hous.n .IRIG.           1 u  970 1024  377   41.454   -0.089   0.054
> -nms-rlat.losa.n 64.57.16.162     2 u  433 1024  377    9.455    1.360   0.242
> +saturn.es.net   .PPS.            1 u  472 1024  377    1.416    0.129   0.018
> assID=0 status=06f4 leap_none, sync_ntp, 15 events, event_peer/strat_chg,
> version="ntpd 
>
>  Sat Dec 19 00:58:16 UTC 2009 (1)",
> processor="i686", system="Linux/2.6.18-194.17.1.el5.web100", leap=00,
> stratum=2, precision=-20, rootdelay=0.993, rootdispersion=37.124,
> peer=44898, refid=128.114.129.77,
> reftime=d1e5586a.2bec4221  Thu, Aug  4 2011 13:42:02.171, poll=10,
> clock=d1e55e12.3ed7c2bd  Thu, Aug  4 2011 14:06:10.245, state=4,
> offset=0.103, frequency=66.577, jitter=0.052, noise=0.061,
> stability=0.000, tai=0

These numbers look very reasonable, and I think your clock and the data 
being collected look ok.  I think there is nothing to really worry about 
in this case.

Thanks;

-jason

On 8/4/11 1:56 PM, thus spake jim warner:
> On 8/3/2011 6:27 PM, Alan Whinery wrote:
> > 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.
> Sigh. Clock jitter. Packet jitter. Clock wander. Thanks for the reply. A
> lot of good information. It is not our plan to buy clocks to attach to
> perfsonar nodes. I think what I was asking is 'how good is network
> time?' The endrun technologies data sheet says 0.5 mS, and that says
> what I'm seeing is all I could expect. It is even 2x better than that.
>
> As you surmised, our NTP servers (endrun; one CDMA, one GPS) are on our
> network and not directly attached to perfsonar nodes. I didn't know
> anyone did that.
>
> I don't know what kind of clock Stanford is using, or whether they
> edited the default list of time servers in the distribution. I don't
> want to have to know that kind of info to use the tools. I would,
> however, pay attention if the admin block at top of the Perfsonar web
> page included that sort of information -- but it doesn't.
>
> -jim