[ntp:questions] quirky adjtimex behaviour [SOLVED]
serge.bets at NOSPAM.laposte.invalid
Mon Jan 28 13:31:10 UTC 2008
Hello Dean and Hal,
On Tuesday, January 22, 2008 at 1:08:00 +0000, Dean S. Messing wrote:
> hal-usenet wrote:
>> try changing the code that reads the CMOS clock to spin in a loop
>> reading it until it changes. That will give you the time early in
>> the second.
The adjtimex code is already designed to detect the exact beginning of
an RTC second. Either via the /dev/rtc update-ended interrupt, or by
busywaiting for the fall of the update-in-progress (UIP) flag. But
nevertheless your analysis of facts seems good, Hal: This tick
synchronisation probably fails for some unknown reason in Dean's case.
> I just replaced version 1.23 of adjtimex with an old version 1.20 and
> the quirky behaviour disappeared. I first noticed it on my new
> Fedora 7 with version 1.21.
Interesting: adjtimex 1.21 was the first version using by default the
/dev/rtc interrupt to detect the clock beat. The problem might be there.
Adjtimex 1.23 has an option to force the UIP method: does it show the
| # adjtimex --utc --compare=20 --interval=10 --directisa
Anyway the default /dev/rtc method is preferable. The 1.23 debug output
may reveal what's up with your interrupts:
| # adjtimex --utc --compare=1 --verbose
Serge point Bets arobase laposte point net
More information about the questions