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

Unruh unruh-spam at physics.ubc.ca
Tue Jul 22 20:33:59 UTC 2008

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

>Hello Bill,

> On Monday, July 21, 2008 at 23:30:12 +0000, Unruh wrote:

>	[multiboot MS Windows]
>> Serge Bets <serge.bets at NOSPAM.laposte.invalid> writes:
>>> Windows has set the RTC. The RTC then drifts. Hwclock cannot possibly
>>> correct this drift.
>> The drift is easy to correct.

>How?? Hwclock has no way to determine when Windows has set the RTC.

That is not a drift. That is a step function change. It is a change to the
phase, not the frequency to use ntp language. The drift is the change due
to the frequency difference. That is easy to correct. The discrete phase
changes due to Windows are not so easy to correct. 

>This could be 30 seconds or 4 days ago. The drift rate is known, but not
>the amount of drift accumulated during such unknown period.

When Windows reset the clock ( assuming that the reset was some reasonably
small fraction of the total time difference) does not matter in correcting
the drift. 

>> What is hard to correct is the random jump to the time Windows applied

>Indeed! :-(

>> espcially a problem if your linux clock is on utc

>But I'm not sure there is any sane way to make an RTC on UTC cooperate

That was what I meant.  Windows will simply reset the clock by 9 hours (
where I am), which is problematic. 

>well with Windows. I tried the registry trick about
>but got inconsistent results. Worse results than with an RTC on
>localtime, where at least the problems happen *only* twice a year.

>> until yesterday, there was a bug in the [Linux kernel] 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.

>Wait a minute: I'm aware of several flavours of such early returning
>read(/dev/rtc) driver bug. Hwclock implements a pair of workarounds
>against this. One is a minimal waiting threshold. The other involves
>analysis of the data read(): if the UIE flag 0x80 is lit then it's
>assumed to be a real interrupt. Are those workarounds effective against
>the bug you're talking about?

I do not think so since the UIE flag IS set on that early return. 
The early return results from not clearing old info in the interrupt return
functions, and perhaps some weird behaviour of the system under hpet

On old systems without hpet the returns seems to be fine. On hpet systems,
they are not. 

Note that sometimes hpet also returns millisec off the right time ( often
early) for a UIE interrupt return. 

See the code I put into the bugzilla.kernel.org bug report 11112 corrected
by David Brownell (I did not correct for negative usec in the time
difference) which you can use to test the read return, and see if it
misbehaving. It also returns the read() result so you can check the flags.

>I fear not: Usual early returns give data=0, while your report shows
>data=0x190, which is a normal value for one UIE interrupt.

>>> On Wednesday, July 9, 2008 at 15:53:57 +0200, Ulrich Windl wrote:
>>>> OK, I agree that the update may be wrong up to one timer tick.
>> One timer tick of the rtc is one second.

>Well to the contrary: Ulrich was talking about the jiffies of a
>non-tickless kernel (10 ms at HZ=100). His reasoning was right, and
>confirmed by measures.

>Serge point Bets arobase laposte point net

More information about the questions mailing list