On Tuesday, February 19, 2008 at 17:45:59 +0100, Thierry MARTIN wrote: > The system I have is a (trans)portable machine. I wonder wether these > parameters will be ok, wherever I place it (what is the influnce of > temperature differences or things like that)?
Of course the temperature influences the drift of the clocks. When you run ntpd continuously and graph the kernel frequency, you clearly see night and day cycles, seasonal cycles, "accidents" like the heater stopped during 2 hours, periods where the computer is iddle or does heavy work, and days where the sun shines. Ntpd compensates those variations continuously, correcting the frequency to stay in phase with The Real UTC Thing. The frequency difference between a winter night and a summer day depends on the machine and various conditions, but I seem to typically see around 2 PPMs. When ntpd is not there to compensate in real time, your goal is to calculate a mean frequency, that will suit your own usage of the machine. On a 24/7 server, pick the mean over 24 hours. On a workstation, pick mean of work hours. And so on. The temperature influences also the RTC drift rate. And there is there a major additional source of temperature variation: is the machine on, or off? One also has to calculate a mean drift, but more to suit the *non-usage* of the machine. Let me explain: An accurate RTC is important at one occasion: The boot sequence, when hwclock --hctosys reads the RTC, applies the drift correction, and initialises the system clock. The RTC has then drifted since the last time hwclock --systohc had set it. Typically, this happend during the previous shutdown. In those conditions, to have a good correction factor to apply at boot, one should evaluate the drift during power-off time. This could be schematically: | at the end of the day: | # ntpdate -b ntp.cines.fr | # hwclock --systohc --nodrift | # shutdown -h now | wait next morning, then restart the machine, and soon after: | # ntpdate -b ntp.cines.fr | # hwclock --systohc This is important, as bad procedures evaluating the RTC drift wrongly during runtime are a major source of error, maybe a dozen PPMs, one entire second/day, resulting in several hundreds of milliseconds offset on the next morning. Note that the default setup of many Linux distributions doesn't do that well. They evaluate the RTC drift from shutdown to shutdown, over mixed periods of half runtime and half poweroff. I fear the difference to be so big that such a compromise can suit nearly noone. I wonder how Chrony behaves with the RTC? Cordialement, Serge. -- Serge point Bets arobase laposte point net _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
