On Feb 12, 2015, at 1:56 AM, Rob <nom...@example.com> wrote: > Charles Swiger <cswi...@mac.com> wrote: >> On Feb 11, 2015, at 7:23 AM, Rob <nom...@example.com> wrote: >>> But I see it has also been explained elsewhere in the thread: ntpd has >>> a maximum on the momentary drift of 500ppm, no matter if it is static >>> or dynamic or the sum of two. I think that is not warranted. >> >> Do you believe that a clock which loses or gains over a minute per day >> should be assumed to be trustworthy? >> >> Even a ~$10 wall clock which keeps time only by counting 50 or 60 Hz >> waves from the AC line will do better than that. While the power grid >> frequency fluctuates in the short term due to load with similar magnitude of >> error, the utilities make an effort to correct the time during non-peak >> hours with slew rates of 200 - 333 ppm so that AC synchronous clocks >> see 86400 seconds per day. > > That cannot be compared at all! The grid is locked to atomic clocks, a > clock running on AC will on the average keep very good time.
The grid isn't-- can't be-- locked to atomic clocks during periods of high load. That's aside from the key point, however. At what point should you decide that a potential timesource is not trustworthy? > A computer clock is driven by a crystal and is not locked to anything > until you use something like ntpd to lock it. Yes. However, before you can lock the local computer clock to a remote timesource, you need to perform some level of sanity checking. If you wait 1024 local seconds, and the remote timesource agrees that ~1024 seconds plus or minus a fraction of a second have passed, that's fine. If the remote timesource thinks 1022 or 1026 seconds have passed, however, one side or the other is exhibiting a ~5 minute per day error. [ ... ] >>> 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. Yes. A drift of 30 ppm is reasonable and common for commodity hardware. If you examined a hundred physical machines, I'd be surprised if you found more than one or two which was worse than 100 ppm. > 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. You're describing a TCXO; using a temperature sensor to compensate for thermal drift would gain perhaps a factor of 5 accuracy. Regards, -- -Chuck _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions