Re: PROBLEM: Linux updates RTC secretly when clock synchronizes

From: Riley Williams (rhw@MemAlpha.cx)
Date: Sat Nov 03 2001 - 13:35:44 EST


Hi Alex.

>> 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.

I'm currently on RedHat 6.2 on the system in question, and I have the
xntp3-5.93-14.i386.rpm package installed. I can only comment on that as
a result.

> 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...

The following is the start of my /etc/ntp.conf file, so perhaps you can
compare it to yours and advise if it looks anywhere near similar...

===8<=== CUT ===>8===
# Remote systems I am authorised to synchronise to.
#
server ntp4.cs.strath.ac.uk

#
# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available. The
# default stratum is usually 3, but in this case we elect to use stratum
# 10. Since the server line does not have the prefer keyword, this
# driver is never used for synchronization, unless no other other
# synchronization source is available. In case the local host is
# controlled by some external source, such as an external oscillator or
# another protocol, the prefer keyword would cause the local host to
# disregard all other synchronization sources, unless the kernel
# modifications are in use and declare an unsynchronized condition.
#
server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10

===8<=== CUT ===>8===

The lines starting with '#' are comments describing the reasons for the
choices in question, and this is the only interesting part of the
configuration file as far as this discussion is concerned.

The first server line specifies the clock source to be used when I'm
online, this one being at the University of Strathclyde in Scotland, and
is one that I have obtained permission to use. As nothing else is given,
it stands at stratum 2 (as obtained on request from the timeserver
itself).

The second server line specifies 127.127.1.0 which is the address that
ntp associates with the local RTC clock. The fudge line that follows
specifies that this is to stand at stratum 10, and thus that it is
considerably less reliable than the first server line. It therefore gets
ignored when the first listed server is available, and is only used if
nothing better can be contacted.

>> 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)!

If it does, what adjusts it?

>> 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.

The kernel itself never writes to the RTC, and that is one of Linus's
decisions with which I am in 100% agreeance (and one thing I hate about
Windows). In fact, the kernel itself also doesn't read from the RTC
either, but leaves that to userspace.

> 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.

That's possible. However, I'd start by grep'ing your bootup and shutdown
scripts for lines containing the word 'clock' either on its own or as
part of a longer word, where those lines are not comments. If you have a
RedHat distribution, then...

 Q> find /etc -type f | xargs fgrep clock /dev/null | fgrep -v ':#'

...will give you a list of possibilities. Go through these and check
what each one is doing, and if any are SETTING the RTC, then comment
them out. Let me know whether that cures your problem. The reason for
this is that the standard RTC setting programmes are `clock` and
`hwclock` and either can be told to copy the current system time into
the RTC.

>> 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.

If it's not the above, please advise what you find.

Best wishes from Riley.

-
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/



This archive was generated by hypermail 2b29 : Wed Nov 07 2001 - 21:00:21 EST