[time-nuts] Allan Deviation recipe?

Gary E. Miller gem at rellim.com
Tue Jul 19 18:25:01 EDT 2016


Yo Tom!

On Tue, 19 Jul 2016 12:47:12 -0700
"Tom Van Baak" <tvb at LeapSecond.com> wrote:

> > Check it out:
> >     https://rellim.com/graphs/adev.png
> >
> > That is for a SiRF III (MR-350P) with a bad sky view.
> > How does that look?  Totally wrong?  Somewhat wrong?
> > Once I get this packaged up I'll have lots more similar graphs.  
> 
> Hi Gary,
> 
> Looking good. Not sure how artistically picky you are, but:

I'm picky enough to annoy others.  :-)

For the moment, I'm happy if the data is technically correct.
 
> - consider changing 'PPS' to '1PPS'

In NTP land they are synonymous.  I appreciate the vendors now talk
of 5PPS, but my audience is NTP.

> - consider changing 'GPS' to 'NMEA' (at least I think that's what you
> mean)

Well, in this case, it is actually SiRF Binary.  So maybe 'Serial', 
or 'GPS Serial'.

> - the y-axis title is partially cropped off the chart; center the
> plot to get the same amount of border as top, bottom, and right sides

I'm gonna make them the same sie as the other chrony-graphs.

> - for mobile or printed usage, the axis titles (powers of ten) font
> size is too small by maybe 2 or 3 points

Ditto, they'll be chrony-graph style.  Once they look that way I'll
see about getting the project style changed.

> - consider using a greater depth of adev5 points (e.g., 10 or 20 or
> 50 per decade) and skip the solid line; or just try both ways to see
> if one looks better

The lines are so straight, is there any data hiding in there?  Well,
surprise, there is!  

> Also try plotting TDEV instead.

That was next on my list.  Just done.  Those curves are more interesting,
just not sure what that means...

I gotta figure it out to explain it to the NTP folks.

> In a case like this an ADEV plot is
> somewhat boring or even misleading -- it's just a -1 slope going down
> forever. It's not quite what ADEV was meant for. The slope suggests
> you have a bounded amount of white phase noise and that's that.

Which pretty much what I expected.

> So,
> for example, the entire PPS red trace can thought of as 6e-4/tau. In
> other words, you can represent the performance of the receiver with a
> single rms number, instead of a featureless ADEV plot. Similarly the
> blue trace is essentially 0.6/tau.

That is what I love about plots, now it seems to obvious.  Execpt the new
bumps...

> The weird jump in the NMEA blue trace between tau 1000 and 2000
> should be investigated. Increasing the point density (using adev5) or
> eliminating the false line interpolation or using TDEV may help you
> look into this.

More points added.  Yeah, weird...

> The other thing, that Bob just alluded to, is that while your NMEA
> measurements are probably legit, your PPS measurements may be totally
> skewed by the fact that you're using a plain PC and its operating
> system (and NTP, and drivers, interrupts, BIOS, caches, etc.) as a
> measuring instrument. The actual 1PPS out of a typical GPS receiver
> is orders of magnitude more precise than the "tool" you're using to
> measure it.

Yeah, sorta backwards, but that is the data I got.  How to plot it
to show interesting things is what I'm working on.

> Therefore it's possible that the red trace is more a measurement of
> how bad your PC/NTP measurement setup is rather than a measurement of
> how good the 1PPS is. In other words, you have accidentally used 1PPS
> to measure the limits of your measurement system, rather than use
> your measurement system to measure the 1PPS. Does that make sense?

Yup, exactly, and sorta what I am trying to get to.  Given a good PPS,
how well is the ntpd working?  The point of PPS is to discipline the
NTP, and that is sorta what this shows.

It gets more interesting when using the PPS to be sure the system clock
is good, then using the system clock to measure other refclocks.  Like a
USB GPS compared to the PPS.  That will come in time.

The USB GPS results have surprised a lot of people, and solid proof
required to overcome disbelief.

NTP has some long standing questions on how to really model NTP time
served over real networks.  So using the system clock, disciplined by PPS,
will be a good place to measure that.

If I could get a real good PCI clock (that I could afford) then that
could be the reference for the PPS, ntpd, and/or system clock.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://www.febo.com/pipermail/time-nuts/attachments/20160719/dd5a84a4/attachment.sig>


More information about the time-nuts mailing list