[ntp:questions] Linux 11-minute mode (RTC update)
Ulrich.Windl at RZ.Uni-Regensburg.DE
Wed Jul 9 13:53:57 UTC 2008
Serge Bets <serge.bets at NOSPAM.laposte.invalid> writes:
> Hello Ulrich,
> On Friday, May 9, 2008 at 10:21:44 +0200, Ulrich Windl wrote:
>> How does hwclock know when the RTC was updated last? [...] how does
>> hwclock know the drift? Asuming it has exclusive ownership of the RTC?
> Yes. More exactly assuming exclusive write access to both the RTC and
> a small adjtime file, where hwclock records the last setting epoch and
> its estimate of the drift rate.
I was talking about ownership: "exclusive write access" for how long? For the
time of the update? If not, how do you ensure nobody else does update the RTC?
>> Did you consider that on Multi-Boot systems a different OS might have
>> run that also updates the RTC?
> That's indeed a problem, but not unsolvable. Sometimes it's possible to
> share the adjfile between the different OSes, and then hwclock can work
> nearly as well as on single-boot. Sometimes adjfile sharing poses some
> difficulties, or hwclock just can't run (MS Windows comes to mind). Then
> it's a real problem: drift can't be well corrected.
In my experience adjtime de-adjusted the clock in more cases severely than id
did adjust it in a useful way.
> But the pure kernel method still doesn't do any better. Halt a Linux-box
> in the evening, multiboot it on Windows next morning: The time at
> startup will also be wrong.
Why? The RTC will be the time Windows has set last. Trying to improve the RTC
without knowing what time it is seems a stupid idea to me.
>> IMHO exchanging systemtime with the RTC by a user-program is broken.
> This user-program is 1000 times more accurate in most practical usage
> cases. And not worse even in the most uncomfortable corner cases.
Can you explain why a user process has more accurate timing then a kernel task
in general? It sounds like a strange concept...
>> hwclock is unnecessary if NTP is used and the kernel handles the RTC
>> properly (IMHO).
> The problem is that the kernel handles the RTC quite poorly. The day
> when kernels will be able to read and write the hardware clock down to
> some microseconds, and manage its drift, you might become right. That's
> not today.
OK, I agree that the update may be wrong up to one timer tick. The easy and
obvious solution involving busy waiting is a no-no in the kernel. Maybe this
answers the question above as well.
More information about the questions