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

Bill Unruh unruh at physics.ubc.ca
Thu Jul 24 01:48:40 UTC 2008


Uwe Klein <uwe_klein_habertwedt at t-online.de> writes:

>Serge Bets wrote:
>> Hello David,
>> 
>>  On Tuesday, July 22, 2008 at 7:45:06 +0100, David Woolley wrote:
>> 
>> 
>>>Serge Bets wrote:
>>>
>>>>Hwclock 2.33 sets the RTC with typically a maximum error of
>>>>10 microseconds
>>>
>>>That would only be possible if the RTC's counter was updated on both
>>>phases of the 32kHz clock, which I rather doubt.
>> 
>> 
>> Excellent example, Dave! The source 32K crystal period being 30 µs, you
>> point the finger at a real issue. An issue that has been squashed some
>> time ago by hwclock's feedback mechanism. Not a problem anymore.
>> 
>> For simplification, I'll assume everything else is instant and perfect,
>> and will neglect RTC restart delay. When we set the RTC, the last crystal
>> pulse happened between 0 and 30 µs ago. Let's pick 18 µs for the
>> example. This last pulse becomes the start of this RTC second, the next
>> second will start 32768 pulses later, and so on. Result: the RTC is in
>> advance by +18 microseconds. Problem.
>> 
>> However the feedback mechanism measures this +18 µs offset, and corrects
>> future readouts by -18. Final result: nothing less than perfection. :-)
>> 
>> 
>> Serge.

>If you fix the RTC time in the ISR for the "second tick" you have a
>deterministic relation from edge to (update) action.


It seems that things are even worse than I suspected with the Linux kernel
and the machines which have HPET. Apparently the HPET disables the rtc
interrupts and takes them over. But it operates on a 64 Hz clock and only
interrupts on that clock tick. Ie, the interrupt from the rtc is likely to
out by many msec from the true turnover of the rtc clock (This is according
to Dave Burnel the rtc-cmos maintainer). But worse than that the HPET rtc
can get itself into a totally horrible state, where the interrupts are way
out ( 50-500ms) 

No amount of care in the hwclock program can get around this kind of
nonesense. 

See kernel bug 11153.

It seems that if you have any desire to have good time, use the 
nohpet
option to the kernel.




More information about the questions mailing list