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