Hi, all-- On Dec 6, 2013, at 4:13 AM, Martin Burnicki <martin.burni...@meinberg.de> wrote: > Agreed. If ntpd would do initial corrections faster we wouldn't even need a > drift file, and it didn't matter if an OS kernel computed slightly different > clock frequencies each time the system reboots.
Unless your computer's quartz crystal is completely broken (admittedly, that happens) or unless there is a major bug in the operating system time calibration (ditto) it should provide timekeeping which is stable to within a few PPM over a 10 C temperature range. An OCXO should be stable to better than +/- 1 ppm over a 50 C range. [1] The point of retaining a drift file is to provide a reliable first-order correction to the intrinsic drift of the system so that it can retain decent timekeeping even if it loses connectivity with higher-stratum time sources. It shouldn't need to care about the minor fluctations in frequency due to daily temperature changes both because those average out and because the effect upon decent hardware running in temperature-controlled environments (ie, a data center) from temp-related frequency changes ought to be very small. If the OS mis-calibrates the clock by a factor of 200 ppm upon system boot as some Linux 2.x kernels with buggy calibration routines evidently have, that vastly outweighs the effect of a ~1ppm frequency drift from temp. Having to monitor, delete, and/or manually swap around your ntp.drift files is a pretty sure sign that you've got unstable timekeeping due to a problem somewhere and not because ntpd is doing the wrong thing. There clearly are other opinions about this-- see Unruh for an example-- but to my mind, if daily temperature changes are affecting your timekeeping significantly, then something is wrong. Perhaps you need to check for and de-dust CPU/PSU fans and validate that your environment cooling is working properly, or perhaps you need to swap out buggy hardware or software. Or perhaps you choose to run chrony instead, which seems designed to chase short-term changes more rapidly than ntpd was designed to do. Regards, -- -Chuck [1] Data per fig 5 of http://tf.nist.gov/general/pdf/581.pdf _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
