Gary E. Miller
gem at rellim.com
Sun Nov 6 22:52:56 UTC 2016
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.
> >> 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.
> 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
> > 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.
> 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:
90% 98% StdDev Mean Units
0.976 2.515 0.449 -0.000 µs
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
Size: 455 bytes
Desc: OpenPGP digital signature
More information about the devel