✘0.250ppm/°C

Sun Nov 6 22:52:56 UTC 2016

Yo Achim!

On Sun, 06 Nov 2016 23:33:34 +0100
Achim Gratz <Stromeko at nexgo.de> wrote:

> Gary E. Miller writes:
> >> The denominator is a temperature difference, which can't be
> >> reported in °C; so that should be ppm/K.  
> >
> > One °C is one °K for ratio purposes.  The offset cancels out when
> > youu compute the delta.  
> 
> There isn't any unit °K, it's just K; and as I said, °C must not be
> used for temperature differences either.  The two scale factors are
> the same.

picky, picky.  Is this not the typesettting list?

> >> Over a period of time
> >> longer than a week you need to take crystal aging into account
> >> also.  
> >
> > I think my poor control of the test room temp vastly outweighs the
> > aging.  So I'm pondering some sort of chamber.  
> 
> The aging is indeed slow enough to get removed by the NTP loop, but it
> shows up when you look at a week or more worth of data.  That will
> then make your fit worse or even prevent it from converging, which is
> why you explicitly need to take it into account there.

I'm not seeing it.  And is so then NTP is failing.

    https://pi4.rellim.com/week/#local_frequency/temp

> >> I'm only using values where the loop has converged to better than
> >> 1µs for the fit.  
> >
> > But that's the thing.  As long as the RasPi has GPS lock, any aging
> > or temp error is correctetd in the loop.  Unless you want to
> > provide good time with long GPS outages the aging is not important
> > to NTP operation.  
> 
> Your mental model of how the NTP loop works seems to be missing
> something important: any change in the XO frequency shows up as an
> error in the measurements that NTP makes.

Well, duh.

>  Since that error is not
> unbiased when the frequency drifts along with temperature, it will
> take quite some time to get corrected and while it is getting
> corrected, there is a time offset that is proportional to the
> derivative of the frequency offset.

Yes, but I only see an obviouus time offsett error when the NTP
frequency servo is too slow.  Like after a sudden temp change.  In
normal practice the effect is too small to see on any of my 5 testt
cells.

> > Ditto here on one of my RasPi.  That clearly buffered the RasPi a
> > bit from room temp, but magnified the load factor effect.  So on
> > balance not a win.  
> 
> That's why you will want to run it near the zero-TC point and with as
> uniform as possible power dissipation.

Hard to control the power dissipation on a PC serving the internet.
I do agree that any environment is best at the zero-TC point.  But
I do not agree that I can see that actually effect my NTP offsets, which
is the real goal.

> >> I'll have to see how to
> >> get some finer control over that load (and maybe use a second core
> >> for "heating") so that I can operate exactly on the zero-TC
> >> point.  
> >
> > I'm pondering a more direct thermal control.  Fans, heaters, etc.
> > But to me that is very much a low priority.  
> 
> That doesn't work the way you seem to imagine it, you just pile on
> another problem of keeping the temperature stable on a system with
> substantial and varying power dissipation.

I've done it before, I'll do it again, just not high on my list.

> If
> you want to throw hardware at it, just remove the XO and feed the
> rasPi 19.2MHz synthesized by a GPSDO (the navSpark timing module can
> do that for about $80) and run ntpd in external discipline mode (if
> that still works).

WAY more expensive than what I am thinking of.  Feel free to try it and
send in the results.

> > My concerns are different than yours.  I could care less if the OSC
> > frequency drifts, as long as NTP applies a good loop correction.  
> 
> Again, if your yardstick changes between measurements, that correction
> is also off by definition.

And again, is the change due to short term tetmpp shift is small, NTP
handles it.  That is what I observce.

> > What I find worthy of fixing in the graphs is the frequency spikes,
> > the temp related and especially the temp unrelated.  What other
> > forces are changing the frequency.  Ts there some way to change the
> > loop control to improve time and frequency accuracy?  
> 
> You need to first and foremost ensure that the the XO frequency is
> stable.  The accuracy at timescales below 100s is limited by the
> short-term stability of the XO.  You can shift that error between time
> and frequency within some reason, but it doesn't go away.

I look forward to your experimental evidence that this effect is
significantt on the RasPi.

> If the frequency isn't stable,[...]

Facts not in evidence.

> 99% of all
> PPS timestamps over the last day stay within ±10µs, 75% within ±1µs
> and slightly less than half within ±500ns.

Odd that I get much better numbers without all that work:

Ranges...... 		
90%	98% 	StdDev 	 Mean	Units
0.976	2.515	0.449	 -0.000	µs

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: 455 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20161106/ef7d9aa6/attachment.bin>