On 2015-02-12, Rob <nom...@example.com> wrote: > Charles Swiger <cswi...@mac.com> wrote: >> On Feb 11, 2015, at 7:23 AM, Rob <nom...@example.com> wrote: > Yes I would prefer that, but chrony does not support local references > so it is useless to me.
Yes, it does and has for about 3 or 4 years now. > >>> In practice a changing drift is often caused by changing temperature, >>> and it would be better to take the first derivative into account as well. >> >> Certainly it is true that changing temperature will cause a change in crystal >> frequency, on the order of ppm's to tens of ppm's per 10 C temperature >> change. >> >> But if you're willing to tolerate over 500ppm systemic error, why worry about >> a second-order effect in the 10s of ppm's? > > Those two things are not related. I have some systems that I need to > keep within a few microseconds (with PPS) and those do not have that > 500ppm error (none of my systems do), they usually within about 30ppm. > > However, what I observe is that the plots of the offset show the derivative > of the environment temperature, which unfortunately cannot be controlled > any better. I am considering to locate the crystal that is responsible > for the timing and see if it could be ovenized or replaced by a more > temperature-stable oscillator. However, one can argue that it could be > fixed in software as well. ntpd could sense a changing drift and extrapolate > it, if necessary helped by input from a temperature sensor. ntp is a very simple feedback loop. It does not have a memory except for current drift. It never extrapolates. Note that versions of ntpd with temperature input have been created and posted over the years, and they do result in a much tighter control of the time. I do not have a reference to them but googling or waiting for others on the list will supply the references quickly. _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions