NTPsec leap second experience

[Achim Gratz]

Hal Murray writes:
> What do you mean by "feedforward"?

Project the changes from the expected drift and temperature onto the NTP
loop variables before the actual loop code tries to remove the residual
error.  While the loop is closed, this should make the error variables
more white and hence improve the loop stability.  It should also enable
a more judicious use of holdover in certain situations that NTP
currently doesn't handle well.

> ntpd works out the "drift" of the clock it is using.  The system time usually 
> traces back to a crystal.  Sometimes there is smearing in there to reduce 
> EMI.  (or dance under the regulations)

Only that in my case this is always output as 0.0… :-)  I'm not sure to
what precision NTP calculates this term internally.

> The actual frequency of a low cost crystal tracks temperature.  Details 
> depend on all sorts of things.

As I said, I'm operating the rasPi at the cusp of the downward parabolic
temperature dependence of its XO.  At the moment I keep it there
manually, maybe I'll find some time to program a regulation loop to keep
it there.  I'd really want to run that loop on the VC4 and not the ARM
part of the SoC however.

> Until you have a stable clock, perhaps by keeping the temperature constant, 
> everything else is lost in the noise.

I've demonstrated that the clock was a lot more stable than I've had
expected it to be.  That incident of course also had favorable
environmental conditions so I'm not claiming that this is something that
can always be expected.

> How much does your drift change over the day when your system is operating 
> normally?

If I remove the linear aging, I'll end up with about ±2ppb which
probably are split about half due to temperature effects and the other
half due to noise.  That is not counting the times where NTP is chasing
ghosts due to GPS burps.  My a-posteriory estimate of the frequency
offset based _only_ on temperature and aging typically deviates less
than about ±1ppb from the NTP loop offset in steady-state operation.

> There is a wonderful paper on this area:
>
> NTP temperature compensation
> Mark Martinec, 2001-01-08 
>   https://www.ijs.si/time/temp-compensation/

Yes, that's the sort of thing I'm thinking of (I posted that link before
I think).  Only that due to my system setup I don't really need to
compensate for temperature to get the same benefits.  What I really want
to do is getting to the point where NTP just switches into holdover if
it gets data from PPS that can't possibly be right and wait until
whatever produced that error has gone.  From the moment you switch into
holdover there's an (at least) quadratic corridor of where the true time
should be and you keep in holdover as long as that projection doesn't
overlap with the PPS data.  If you consider these as statistical
variables (i.e. having at least a location and dispersion) you'll end up
with a Kalman filter or a Bayesian projection.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada