> That sounds like a configuration error to me, and here's why.
>
> 1. One of the available reference clocks for xntpd is the local
> RTC, type 1 in the list of reference clock types, and that
> should ALWAYS be listed as one of the reference clocks to use,
> but with a higher stratum than any other reference clock used.
Well, perhaps that's a difference between xntpd and ntpd - I am
using the latter, version 4.1.0, from Debian testing. Manpage
doesn't mention RTC, ntpdc doesn't seem to find it. I may
well be out of sync with ntpd (pun fully intended) as I haven't
looked at it for a while, but...
> 2. My experience with the xntpd driver suggests that if no better
> reference is available and the RTC is one of the listed clocks,
> then it ALWAYS adjusts the time to match the RTC, irrespective
> of the time difference between them.
... you are assuming that the RTC doesn't get adjusted first (to
match the system clock)!
> 3. AFAICT, if xntpd writes to the RTC, then it has achieved true
> synchronisation to a reference clock other than the RTC.
I thought the original poster was claiming that the /kernel/
wrote to the RTC, which would explain the behaviour I'm seeing.
An alternative explanation I suppose is simply that nothing
is writing to the RTC (not ntpd, not anything) except for
the final clock command as the machine shuts down. Very simply
the symptom is that both clocks are correct, I suspend the
machine (without APM in the kernel), I resume it, reboot
it, and now both clocks are wrong.
> If you have the RTC as one of your reference clocks, then this heuristic
> is not required as xntpd (at least) does the right thing for you.
OK I will go read the manpage even harder.
-- Alex Bligh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/