On Tuesday, July 22, 2008 at 20:33:59 +0000, Unruh wrote:
> The drift is the change due to the frequency difference. That is easy
> to correct.
Again: how?
> 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.
Of course it matters. The epoch at which the RTC was last written is the
point of origin of drift. To calculate the drift, you need to know its
rate, and its point of origin. In ntp terms, the drift rate is the
frequency. A frequency that is both wrong and not adjustable. This
produces a constantly growing offset. During readouts you can only
calculate the offset then reached, and compensate it.
The fact that Windows writes the RTC rather poorly is another problem.
Problem also hard to solve. Fortunately the error is rarely greater than
1/3 of a second, and is not constantly growing.
> Windows will simply reset the clock by 9 hours ( where I am), which is
> problematic.
Windows will probably not warp so an RTC on localtime, this being the
recommended setting.
[/dev/rtc 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.
So that's really annoying. I can imagine no other reasonable workaround.
Reading 2 update interrupts and trusting only the second one is not a
good solution, because it will cost one full second to innocent people.
We can be grateful that you reported this bug and got it to be fixed
right in the Linux kernel. Much thanks to you, Bill! :-)
Serge.
--
Serge point Bets arobase laposte point net
_______________________________________________
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
