Serge Bets <[EMAIL PROTECTED]> writes: > On Sunday, April 6, 2008 at 19:36:40 +0000, Unruh wrote:
>> Serge Bets <[EMAIL PROTECTED]> writes: >>> The eleven-minutes write takes some tens of microseconds; normal >>> hwclock some tens of milliseconds; hwclock --nointerrupt some plain >>> seconds. >> To write the rtc properly takes at least a second. >I was talking about processor time consumed. As for wall clock time >elapsed, indeed a background cron job mostly sleeping or waiting for an >interrupt during one or two seconds is rather harmless. >> In the case the machine comes up again in a few seconds, the rate >> correction is irrelevant anyway. >Drift compensation is important even for a stop and go: maybe the stop >was a crash, and the RTC was last written hours ago. But the point was >more that as long as the downtime stays short, the temperature of the >RTC, and thus its instant drift rate, does not vary too much from the >mean runtime values. Therefore it makes sense to pick the runtime rate >for compensation. Only in this specific 24/7 case. We are discussing the hwclock vs the 11 min rule. Thus the last time the rtc was corrected ( perhaps badly if the rtc correction in the kernel is badly implimented) was a max of 11 min ago. Even at 100PPM drift that is "only" 60ms. Thus, if it is true that the hwclock routine sets/reads the system clock better than does the kernel, and if your drift rate is that high, then it is probably better to do the hwclock route. Note as I pointed out, the temp dependence of the rtc can be huge ( and is typically much larger than the temp dependence of the cpu crystal.) The insides cool off rapidly if the system shuts down. The temp sensitivity of a bunch of computers I run have a 4-20 x more sensitivity for the rtc than for the onboard clock. Thus if the cpu is say .5PPM/deg, the RTC will be up to 10PPM/deg. Since the computer cools of by at least 10 deg very rapidly, that is up to 100PPM difference in the RTC between on and off. If the server goes off for 10-30 min ( not unusual for example with a disk failure, or with response time of the person) that is 100s of msec. difference. It would I admit be interesting to actually do some experiments to see how much worst the rtc is cooled than warm. And also whether or not the Linux kernel actually does a decent job of setting the rtc. >> And if the system reads the clock badly it will be out by about a >> second anyway. >This never happens on a proper setup: hwclock --hctosys syncs on the RTC >down to a few microseconds. >Serge. >-- >Serge point Bets arobase laposte point net _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
