Re: [ntp:questions] quirky adjtimex behaviour [SOLVED]
Hello Dean and Hal, On Tuesday, January 22, 2008 at 1:08:00 +, 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 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] quirky adjtimex behaviour [SOLVED]
hal-usenet wrote: Dean Messing wrote: I am seeing strange behaviour on my _x86_64 Fedora 7 desktop workstation with regard to the system-cmos time that `adjtimex' reports. snip It seems that leaves two other possibilities: a bug in adjtimex or a bug in the kernel. That's where I am right now. My guess is that the system/kernel is working correctly and that the adjtimex utility is printing out misleading stuff. The CMOS/hardware clock only returns the time to the nearest second. I think that would cause quirks like this if the code has a loop that does a bit of work and sleeps for N seconds and the bit of work takes 0.1 second the time when the CMOS clock is read will drift by 0.1 second each time around the loop. If you want to play and you can find the source, 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. Your guess is right, Hal. It's been nearly three weeks since I've had a few minutes to further pursue this. 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. When I looked on the adjtimex site I saw it was up to 1.23 so I thought that surely this problem has been detected and fixed. When it didn't go away in 1.23 I looked elsewhere: 64 bit machine, new kernel, c. I'll write the author and report the bug. I'm really surprised nobody has reported it already. Dean ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
