[ntp:questions] Linux 11-minute mode (RTC update)
uwe_klein_habertwedt at t-online.de
Tue Jul 22 18:11:01 UTC 2008
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
>>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. :-)
If you fix the RTC time in the ISR for the "second tick" you have a
deterministic relation from edge to (update) action.
IF you take in the same ISR the value of one of the high resolution
counters you can establish over time a relation between RTC and CPU clocks.
( even independent of any external time source )
Some years ago I did something similar with the DCF77 signal and
the cpu clock of a data aquisition system. Both informations were
stored in 10ms Dataframes.
More information about the questions