Uwe Klein <[EMAIL PROTECTED]> 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.
_______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
