Hello Alessandro, On Monday, June 16, 2008 at 20:35:21 +0200, Alessandro Zummo wrote: > a typical x86 PC RTC could easily go off more than a half-a-sec/day > so this shouldn't be a real issue. What you say is partly true in the context of busybox, which makes no attempt to compensate the drift of the RTC. Indeed a given RTC may well drift by 10 seconds per day; This half second can safely hide in such noise. But in the context of hwclock, the drift accumulated in the RTC since the last time it was set is compensated during RTC reads. A carefully calibrated hwclock can amortize the RTC drift rate to below some tens of milliseconds per day. Then of course a constant 500 ms error becomes quite noticable. Example (--billboard is a local feature patch): | # hwclock --billboard | RTC last written at: 1213657748 | RTC read now: 1213693927 | at time: 1213693922.016890 | RTC time elapsed: 36179 s (0.418738 days) | Really elapsed: 36174.016958 s (0.418681 days) | Fully raw phase offset: +4.983110 s | Last residual error: +0.000068 s | Residual corrected phase offset: +4.983042 s | Drift rate compensated: +11.870000 s/day (+137.384 PPM) | Drift corrected phase offset: +0.012617 s | Actual drift rate observed: +11.900131 s/day (+137.733 PPM) The last --systohc was yesterday night at shutdown. Now 10 hours later, the RTC has accumulated nearly 5 seconds of drift. But hwclock --hctosys compensates its biggest part, and is in error by only 12 milliseconds. There half a second of error would be an issue. Half a second of error is also an issue in the context of reboots: A reboot takes a minute, the accumulated drift is negligeable (sp?). Most or all of the post-reboot error budget is this half second. Alain. -- To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
