Serge Bets <[EMAIL PROTECTED]> 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. Regards, Ulrich _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
