Re: [ntp:questions] Linux 11-minute mode (RTC update)
Noob [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] [...] What do you think about the following script? while true do sleep 660 # or some other value? hwclock --utc --systohc done That, apart from the sleep, it would make a nice cron job. Groetjes, Maarten Wiltink ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Linux 11-minute mode (RTC update)
Maarten Wiltink [EMAIL PROTECTED] writes: Noob [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] [...] What do you think about the following script? while true do sleep 660 # or some other value? hwclock --utc --systohc done That, apart from the sleep, it would make a nice cron job. Well, also without the while loop. Ie, just the hwclock line. As many have said, every 11 min seems a bit often. Groetjes, Maarten Wiltink ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Linux 11-minute mode (RTC update)
Hello Bill,
On Friday, April 4, 2008 at 16:16:22 +, Bill Unruh wrote:
what you really want is the drift rate of the crystal when the
computer is shut off ( ie cooling or cold)
That's very true for workstations halted each evening; much less for
Spoon's 24/7 servers.
all you can measure is the drift rate when it is on (warm and
constant)
One can easely measure the power-off RTC drift rate at room temperature:
Just shutdown the machine during some hours between two well synced
invocations of hwclock --systohc, and then:
| $ awk '{printf %+.3f ppm, -$1 / 0.0864; exit}' /etc/adjtime
| +12.345 ppm
Serge.
--
Serge point Bets arobase laposte point net
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Linux 11-minute mode (RTC update)
On Friday, April 4, 2008 at 14:25:12 +0200, Noob wrote: If I don't want the kernel to update the RTC, I can always undef CONFIG_GENERIC_CMOS_UPDATE. Ah thanks! I wasn't aware of this new switch. I hope Dean is reading, he was after an easy solution. Do you believe that running hwclock --systohc periodically is better than using the kernel's 11-minute mode? There is a cost: eleven-minutes mode is extra-light on processor cycles. Depending on the mode of operation, hwclock consumes either much more, or enormously more cycles. OTOH its drift compensation allows sparser usage. And the accuracy is way better, and well worth the cost IMHO. I use http://giraffe-data.com/software/about_hwclock.html Good: that's the best version. If I use hwclock to update the RTC, how often should I do it? It depends on your expectations. As Hal said, once per hour or once per day seem quite sufficient. I used to use a daily cron job, with excellent results. Stopped it only because I don't manage any 24/7 machine anymore. Let's compare: The eleven-minutes mode needs to write the RTC every 11 minutes because its drift is not compensated, and will very quickly degrade future reads. Example an RTC with a 100 PPM drift rate. After 10 minutes there is already a 60 ms offset. Just then happen 20 minutes of power outage. When power comes back, the RTC has accumulated 180 ms of drift. During bootup the kernel clock initialises with this offset, that ntpd will have to step. During bootup, hwclock --hctosys compensates the drift since the last write by hwclock --systohc. This last write happened either during a clean shutdown, or in a cron job some hours before a power failure. Example: same 100 PPM rate, same 20 minutes of outage, but happening 23 hours after the daily cron job. At restart, the RTC has accumulated 8.4 seconds of drift. But during bootup hwclock compensates this entirely, and the kernel clock is hopefully initialised perfect, or rather at some low milliseconds of the One True Time. Conclusion: an hwclock once per day is already better that an eleven-minutes mode 130 times per day. What do you think about the following script? - Sleep 55 minutes minimum (otherwise drift rate is not reevaluated). - Call hwclock only when the kernel clock is synced. - Better resist to system load with --cpupriority=99 | while true | do | sleep 86398 | if adjtimex --print | grep -q return value = 5 | then | honk --db=130 --cucaracha | else | hwclock --utc --systohc --cpupriority=99 | fi | done Is the crystal of the RTC supposed to be more stable than the crystal of the CPU? No. And the RTC has to run in a much wider temperature range. Typical kernel clock can vary by one or two PPM. Typical RTC by 12 PPM. Unless in an always-on machine, where the RTC variation may stay similar, one or two PPM. In the 24/7 situation, with power outage of maximum 20 minutes, the bootup hwclock needs to compensate the RTC drift accumulated during a mixed period of 0 to 24 hours of power-on plus 0 to 20 minutes of power-off. Those 20 minutes are barely sufficient for a complete cooling. So let's pretend it's all power-on drift, and let hwclock evaluate it. Just what happens every day with the above script. If the expected power outages can reach 2 hours, or 2 days, then it's another story. Serge. -- Serge point Bets arobase laposte point net ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Linux 11-minute mode (RTC update)
Serge Bets [EMAIL PROTECTED] writes:
Hello Bill,
On Friday, April 4, 2008 at 16:16:22 +, Bill Unruh wrote:
what you really want is the drift rate of the crystal when the
computer is shut off ( ie cooling or cold)
That's very true for workstations halted each evening; much less for
Spoon's 24/7 servers.
all you can measure is the drift rate when it is on (warm and
constant)
One can easely measure the power-off RTC drift rate at room temperature:
Just shutdown the machine during some hours between two well synced
invocations of hwclock --systohc, and then:
| $ awk '{printf %+.3f ppm, -$1 / 0.0864; exit}' /etc/adjtime
| +12.345 ppm
Sure, and you can also do it with a lab full of equipment and a good time
source. That is not the question under discussion. The question is whether
or not the drift compensation in hwclock is worthwhile. I would say a bit,
but much less than you might think.
Serge.
--
Serge point Bets arobase laposte point net
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Time reset
Hal Murray wrote: The ntp log file shows when NTP steps the time. But then the potential harm is already done. Especially if the time moves backward, our server might have serious trouble. Is there a log event which indicates that the time is going to be reset in order to enable us to take appropriate action before the actual reset? I don't know of any way to get advanced warning when ntpd is about to step the time. You cannot have advanced warning before stepping. It doesn't know until it decides it needs to do it. There are command line switches to prevent stepping and to allow one step at startup time. Yes. You can use -x to slew always. Danny ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Time reset
Danny Mayer wrote: Hal Murray wrote: The ntp log file shows when NTP steps the time. But then the potential harm is already done. Especially if the time moves backward, our server might have serious trouble. Is there a log event which indicates that the time is going to be reset in order to enable us to take appropriate action before the actual reset? I don't know of any way to get advanced warning when ntpd is about to step the time. You cannot have advanced warning before stepping. It doesn't know until it decides it needs to do it. There are command line switches to prevent stepping and to allow one step at startup time. Yes. You can use -x to slew always. Danny And if the clock is off by many hours, it could take days or weeks to synchronize. Use the -g option when you start ntpd. This will set the clock once only. IF your system is working properly, ntpd should be able to synchronize the clock fairly quickly and to keep it synchronized as long as it has a good source of time. If ntpd steps the time AFTER startup, you have a serious problem somewhere. IMHO the best way to deal with such stepping is to find out what's broken that makes stepping necessary and fix it! ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
