[ntp:questions] quirky adjtimex behaviour [SOLVED]

Serge Bets 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
quirky offsets?

| # 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.
-- 
Serge point Bets arobase laposte point net




More information about the questions mailing list