Hello Ulrich,
On Wednesday, July 9, 2008 at 15:53:57 +0200, Ulrich Windl wrote:
[when hwclock updates the RTC]
> 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?
In order to work perfectly, hwclock has to be the only one to ever set
the RTC, for all of the times long. Nothing enforces that: One can well
choose to use another utility, activate the kernel eleven-minutes mode,
or boot Windows. Then hwclock can still work, but in a degraded mode
where drift correction, beeing impossible, is just disabled. This
degraded mode is either enabled automatically when possible (rarely),
or has to be forced via the hwclock --nodrift option.
[multiboot MS Windows]
> In my experience adjtime de-adjusted the clock in more cases severely
> than id did adjust it in a useful way.
Maybe you didn't use the --nodrift option for the hwclock --hctosys
invoked during the Linux bootup following Windows. This can indeed
lead to inappropriately apply a big drift "correction" to a clock that
was good and had not yet drifted much.
The interesting question is whether it could be possible to
automatically boot with --nodrift after a Windows run, but without after
a Linux run. I suppose that sophisticated boot managers may have
features helping this, but I never looked closely.
> 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.
Windows has set the RTC. The RTC then drifts. Hwclock cannot possibly
correct this drift. There is indeed no point in trying. In this case
hwclock provides you only its better instant accuracy. The result is not
perfect, but is optimal in those conditions, and is better than the
result of the kernel alone.
> Can you explain why a user process has more accurate timing then a
> kernel task in general? It sounds like a strange concept...
I cannot explain in general. But for RTC steering, the difference is
gigantic, and is rather easy to explain: hwclock does absolutely
everything for accuracy, at all costs. The kernel doesn't. Hwclock 2.33
goes quite far for top accuracy:
- Sets the clock at the exact good moment, intending down to the
microsecond. At the expense of wallclock time and processor cycles.
- Evaluates and corrects various machine-dependant constant delays.
- Does feedback: measures its own write error in order to compensate it
on-the-fly when reading.
- Measures its own execution time, and counts it where necessary.
- And of course there are many cases where the RTC drift can be
calculated. And then hwclock compensates it.
>> the kernel handles the RTC quite poorly.
> OK, I agree that the update may be wrong up to one timer tick.
Yes: the eleven-minutes mode sets the RTC with an error typically
anywhere in the range from -7 to +3 milliseconds, at HZ=100.
Hwclock 2.33 sets the RTC with typically a maximum error of
10 microseconds, and is able to read it with the same accuracy.
> The easy and obvious solution involving busy waiting is a no-no in the
> kernel.
We agree on that. Note that hwclock doesn't purely busywait until the
target time: hwclock begins sleeping the biggest part of the delay, then
busywaits only during the very last milliseconds. Maximum accuracy, but
not too much processor cycles wasted.
Serge.
--
Serge point Bets arobase laposte point net
_______________________________________________
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
