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 _______________________________________________ devel mailing list [email protected] http://lists.ntpsec.org/mailman/listinfo/devel
