Re: [SLE] NTP Server - US Daylight Savings Time

• Previous message: Carlos E. R.: "Re: [SLE] ne.o failing in SuSE 6.3 machines"
• Maybe in reply to: qrn_Hansen?=: "Re: [SLE] NTP Server - US Daylight Savings Time"
• Next in thread: qrn_Hansen?=: "Re: [SLE] NTP Server - US Daylight Savings Time"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Sun, 31 Oct 2004 23:40:30 +0100 (CET)
To: SLE <suse-linux-e@suse.com>

The Sunday 2004-10-31 at 11:14 -0500, Jeffrey Laramie wrote:

> That's what I would have expected. Here's the ntp log:
>
> 30 Oct 10:29:08 ntpd[3886]: synchronized to LOCAL(0), stratum 10
> 30 Oct 10:29:08 ntpd[3886]: kernel time sync disabled 0041
> 30 Oct 10:30:11 ntpd[3886]: kernel time sync enabled 0001
> 30 Oct 10:31:17 ntpd[3886]: synchronized to 192.168.1.4, stratum 2
> 30 Oct 10:50:52 ntpd[3886]: time reset -0.595142 s
> 30 Oct 10:55:07 ntpd[3886]: synchronized to LOCAL(0), stratum 10
> 30 Oct 10:57:16 ntpd[3886]: synchronized to 192.168.1.4, stratum 2
> 30 Oct 21:10:02 ntpd[3886]: ntpd exiting on signal 15
> 30 Oct 21:13:01 ntpd[3894]: ntpd exiting on signal 15

> 31 Oct 09:42:35 ntpd[3885]: synchronized to LOCAL(0), stratum 10
> 31 Oct 09:42:35 ntpd[3885]: kernel time sync disabled 0041
> 31 Oct 09:43:38 ntpd[3885]: kernel time sync enabled 0001
> 31 Oct 09:44:44 ntpd[3885]: synchronized to 192.168.1.4, stratum 2
> 31 Oct 09:46:58 ntpd[3885]: time correction of -3602 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time.

This is absurd: UTC time doesn't have daylight adjustments, it is fixed, a
standard reference.

> This may have something to do with the fact the system clock is set to local
> time (dual boot don't you know). It's no biggie, just kind of curious.

Yes... could be... :-?

Ok, let me guess. Linux (and Unix) keeps it's internal clock set to UTC
time (regardless of whatever, read on). Then, when you ask for the time,
the system gives you the local time, calculated from the UTC time +
difference - and that difference is not the same at both sides of the
daylight savings change day. But internally, it is running on UTC time.
It is thus possible for each user on the same machine see different times,
depending on their local adjustments: no problem.

Now, dual boot machines.

The CMOS clock, or hardware clock, is read during boot to adjust the
system (or CPU) time. It should also use UTC time, for simplicity. But
Dos/windows expect the CMOS clock to be at local time instead... now, that
is a problem.

Have a look at /etc/init.d/boot.clock:

    echo -n Setting up the CMOS clock
    test -f /etc/adjtime || echo "0.0 0 0.0" > /etc/adjtime
    /sbin/hwclock --adjust $HWCLOCK
    rc_status
    /sbin/hwclock --hctosys $HWCLOCK
    rc_status
    rc_status -v -r

Then, man hwclock:

       --hctosys
              Set the System Time from the Hardware Clock.

              Also set the kernel's timezone value to the local timezone
              as indicated by the TZ environment variable and/or
              /usr/share/zoneinfo, as tzset(3) would interpret them. The
              obsolete tz_dsttime field of the kernel's timezone value is
              set to DST_NONE. (For details on what this field used to
              mean, see settimeofday(2).)

Translating, what it means is that it knows whether the CMOS clock keeps
local or UTC time (by looking at the /etc/adjtime file, I understand), and
if it is local, it takes into account the difference and sets the kernel
time correctly (ie, UTC time).

Now, what happens at the day of the year that the hour changes?

If the CMOS keeps UTC time, nothing, no problem at all.

If it keeps local time... :-? I think nothing as well, if the system is
running. If the system was off...

If you boot windows first, it will notice the day and offer to change the
time that moment, and adjust the CMOS clock by one hour. When later you
boot into Linux, it read that time, that has changed by one hour, takes
that to be the local time and, this is my guess, calculates the UTC time
_incorrectly_, not taking into account the daylight correction having
already taken place, so it sets the time one hour off.

When NTP connects to the server, the time is already off by one hour...
way too much.

If, on the contrary, you did not boot into windows first, the problem
could happen if Linux thinks the CMOS clock was already adjusted by
windows (which was not) and, again, time is set up incorrectly.

Well, I'm a bit dizzy, I have a little headache. I hope I explained it
sufficiently for you to understand my hypothesis :-)

The problem is that, when the CMOS clock is set to local time, hwclock has
a difficult time divining whether the CMOS clock was already shifted or
not, and doing the wrong assumption. In fact, I don't know whether hwclock
knows that day.

        Another problem would be if the BIOS (or the clock chip) did shift
        the CMOS clock on its own. I have no idea if this is possible.

In any case, the problem disappears by setting the CMOS clock to UTC time
- and then it is windows who has problems ;-)

That's is what I do, by the way. But my local time is almost UTC (1 hour
plus). My windows shows UTC time, then (or instead, local time with
daylight adjustment disabled, meaning that half of the year it will be
one hour off).

So... to finalize, the problem is not ntpd, but hwclock doing the wrong
guess at whether the CMOS clock is already adjusted for daylight savings
shift or not. By the time ntpd gets into the act, the time is already
incorrect by one hour. I don't know how to correct this, if possible; it's
something for developers of SuSE and hwclock.

The problem could, perhaps, be solved, by making sure that 'rcxntpd
ntptimeset' is called right before 'rcxntpd start'.

-- 
Cheers,
       Carlos Robinson
-- 
Check the headers for your unsubscription address
For additional commands send e-mail to suse-linux-e-help@suse.com
Also check the archives at http://lists.suse.com
Please read the FAQs: suse-linux-e-faq@suse.com

• Previous message: Carlos E. R.: "Re: [SLE] ne.o failing in SuSE 6.3 machines"
• Maybe in reply to: qrn_Hansen?=: "Re: [SLE] NTP Server - US Daylight Savings Time"
• Next in thread: qrn_Hansen?=: "Re: [SLE] NTP Server - US Daylight Savings Time"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]