[ntp:questions] Linux 11-minute mode (RTC update)

Unruh unruh-spam at physics.ubc.ca
Mon Jul 21 23:30:12 UTC 2008

Serge Bets <serge.bets at NOSPAM.laposte.invalid> writes:

>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

The drift is easy to correct. What is hard to correct is the random jump to
the time Windows applied to get what it thought was the right time (
espcially a problem if your linux clock is on utc)

>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.

Well, not really. The problem is that most versions of linux these days
have a badly damaged rtc. The whole hpet thing has thrown the rtc
timekeeping back to the stone age ( hpet steals all of the rtc interrupts).
Added to that is the problem that until yesterday, there was a bug in the
rtc code so that an attept to use the UIE interrupt ( interrupt when the
rtc turns over the seconds counter) would return immediately rather than on
the seconds turnover on the first read. Ie, the system would think that it
was exactly on the second, when it was really at some random time. 

> - 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.

One timer tick of the rtc is one second. 

>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 point Bets arobase laposte point net

More information about the questions mailing list