-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I always tell myself that I need to write down how I solve this problem twice a year, but I either lose what I wrote or I just forget. I run an ntp server for the pc's connected to my home network. When daylight savings times rolls around I get errors about too large a difference to change the time. How would I fix this? The best I can remember was I had to reboot the server and go into CMOS to change the time. Thanks. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBhHqNhs7JGk93PT0RAqY4AJ4m/h2FDIY/9aEp9F6HI663ivyFMwCfWyMu fsg6Yv3PE59U88XUcwomNCs= =0V2a -----END PGP SIGNATURE-----
On Saturday 30 October 2004 23:39, Ann Hopkins wrote:
I always tell myself that I need to write down how I solve this problem twice a year, but I either lose what I wrote or I just forget.
I run an ntp server for the pc's connected to my home network.
When daylight savings times rolls around I get errors about too large a difference to change the time. How would I fix this?
The best I can remember was I had to reboot the server and go into CMOS to change the time.
Should be interesting under SuSE, but both my debian and win98 box do this automagically. (I have not run SuSE since like 5.3, currently 9.1 on a test system) Dana
Dana J. Laude writes:
On Saturday 30 October 2004 23:39, Ann Hopkins wrote:
I always tell myself that I need to write down how I solve this problem twice a year, but I either lose what I wrote or I just forget.
I run an ntp server for the pc's connected to my home network.
When daylight savings times rolls around I get errors about too large a difference to change the time. How would I fix this?
The best I can remember was I had to reboot the server and go into CMOS to change the time.
Should be interesting under SuSE, but both my debian and win98 box do this automagically. (I have not run SuSE since like 5.3, currently 9.1 on a test system)
Quite right. Under SuSE 9.1 anyway, one of the last steps during shutdown is to sync the CMOS hardware clock to the software clock. -Ti -- Ti Kan http://www.amb.org/ti Vorsprung durch Technik
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am also trying to remember whether I needed to delete the drift file because of the time change. I think I had to, otherwise it wrote nasty complaint messages. This is my first time with SuSE 9.1 as well. I used to do Redhat. Ti Kan wrote: | Dana J. Laude writes: | |>On Saturday 30 October 2004 23:39, Ann Hopkins wrote: |> |>>I always tell myself that I need to write down how I solve this |>>problem twice a year, but I either lose what I wrote or I just |>>forget. |>> |>>I run an ntp server for the pc's connected to my home network. |>> |>>When daylight savings times rolls around I get errors about too |>>large a difference to change the time. How would I fix this? |>> |>>The best I can remember was I had to reboot the server and go into |>>CMOS to change the time. |> |>Should be interesting under SuSE, but both my debian and win98 |>box do this automagically. (I have not run SuSE since like 5.3, |>currently 9.1 on a test system) | | | Quite right. Under SuSE 9.1 anyway, one of the last steps during shutdown | is to sync the CMOS hardware clock to the software clock. | | -Ti -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBhImIhs7JGk93PT0RAkJ0AJ0VOqOWwWZNgJdNSDsiCYbhrDygAQCZASq3 zQl7l5jWT67iAY5YMMYYUnw= =/vRh -----END PGP SIGNATURE-----
söndag 31 oktober 2004 07:31 skrev Dana J. Laude:
On Saturday 30 October 2004 23:39, Ann Hopkins wrote:
I always tell myself that I need to write down how I solve this problem twice a year, but I either lose what I wrote or I just forget.
I run an ntp server for the pc's connected to my home network.
When daylight savings times rolls around I get errors about too large a difference to change the time. How would I fix this?
The best I can remember was I had to reboot the server and go into CMOS to change the time.
Should be interesting under SuSE, but both my debian and win98 box do this automagically. (I have not run SuSE since like 5.3, currently 9.1 on a test system)
After viewing some of these messages, I went to look further into this and noticed that the reason for the above problem is that NTP on SuSE is not running the local clock as UTC, but as local time with timezone. That is an absolute BOO BOO. http://www.akadia.com/services/ntp_synchronize.html Time synchronization should be done with UTC, while time presentation should be done in local time. Local time, is merely an offset from UTC. Seems to me, that someone made a mess of things. NTP in SuSE is not working as it should, from where I see it.
Dana
måndag 01 november 2004 00:52 skrev Örn Hansen:
After viewing some of these messages, I went to look further into this and noticed that the reason for the above problem is that NTP on SuSE is not running the local clock as UTC, but as local time with timezone. That is an absolute BOO BOO.
Apparently I was a bit too fast on the trigger, as it appears I'm the one who made the BOO BOO. Haven been totally convinced that I had configured my machine to use UTC, I revisited my YaST setup and found out, it was configured with local time. Of course, using UTC, there is no time change when there is a move in and out of daylight savings, since UTC doesn't change. The difference, is merely in the presentation ... not the clock itself. Sorry for shouting wolf :-)
On Monday 01 November 2004 01:36, Örn Hansen wrote:
måndag 01 november 2004 00:52 skrev Örn Hansen:
After viewing some of these messages, I went to look further into this and noticed that the reason for the above problem is that NTP on SuSE is not running the local clock as UTC, but as local time with timezone. That is an absolute BOO BOO.
Apparently I was a bit too fast on the trigger, as it appears I'm the one who made the BOO BOO. Haven been totally convinced that I had configured my machine to use UTC, I revisited my YaST setup and found out, it was configured with local time. Of course, using UTC, there is no time change when there is a move in and out of daylight savings, since UTC doesn't change. The difference, is merely in the presentation ... not the clock itself.
Sorry for shouting wolf :-)
On top of that, during the installation process one is offered the opportunity to: -- choose the timezone -- choose between local time and UTC ;) Cheers, Leen
The Saturday 2004-10-30 at 22:39 -0700, Ann Hopkins wrote:
I always tell myself that I need to write down how I solve this problem twice a year, but I either lose what I wrote or I just forget.
I run an ntp server for the pc's connected to my home network.
When daylight savings times rolls around I get errors about too large a difference to change the time. How would I fix this?
The best I can remember was I had to reboot the server and go into CMOS to change the time.
This is wrong. The ntp server does not change the hour at all for daylight or what ever. It has to continue giving UTC time, which does not change. It is your local time, given by each computer to its users, that changes, not the the time server's. If not, how do you think we can pick the hour from dozens of servers all over the world, and all of them agreeing? -- Cheers, Carlos Robinson
söndag 31 oktober 2004 11:28 skrev Carlos E. R.:
The Saturday 2004-10-30 at 22:39 -0700, Ann Hopkins wrote:
I always tell myself that I need to write down how I solve this problem twice a year, but I either lose what I wrote or I just forget.
I run an ntp server for the pc's connected to my home network.
When daylight savings times rolls around I get errors about too large a difference to change the time. How would I fix this?
The best I can remember was I had to reboot the server and go into CMOS to change the time.
This is wrong. The ntp server does not change the hour at all for daylight or what ever. It has to continue giving UTC time, which does not change.
It's what it *SHOULD* do, but look at here: citadel:~ # hwclock mån 1 nov 2004 00.53.47 -0.452386 sekunder citadel:~ # hwclock --utc mån 1 nov 2004 01.54.05 -0.105389 sekunder c I'm in CET, and the correct local time above is 0:53:47 ... alas, NTPD stores the time in LOCAL time, not UTC time, which explains why the clock was thought to be scewed above. Someone made a mess of things, with the implementation of NTPD, or SuSE in the configuration. I definately set my system to be UTC, and not local.
It is your local time, given by each computer to its users, that changes, not the the time server's.
If not, how do you think we can pick the hour from dozens of servers all over the world, and all of them agreeing?
-- Cheers, Carlos Robinson
On Monday, 1 November 2004 00.56, Örn Hansen wrote:
citadel:~ # hwclock mån 1 nov 2004 00.53.47 -0.452386 sekunder
citadel:~ # hwclock --utc mån 1 nov 2004 01.54.05 -0.105389 sekunder c I'm in CET, and the correct local time above is 0:53:47 ... alas, NTPD stores the time in LOCAL time, not UTC time, which explains why the clock was thought to be scewed above. Someone made a mess of things, with the implementation of NTPD, or SuSE in the configuration. I definately set my system to be UTC, and not local.
As the man page explains, hwclock *always* show the time in local time, regardless of how it's actually stored in CMOS From the man page: OPTIONS You need exactly one of the following options to tell hwclock what function to perform: --show Read the Hardware Clock and print the time on Standard Output. The time shown is always in local time, even if you keep your Hardware Clock in Coordinated Universal Time. See the --utc option.
måndag 01 november 2004 01:03 skrev Anders Johansson:
As the man page explains, hwclock *always* show the time in local time, regardless of how it's actually stored in CMOS
After re-configuration: citadel:/home/oehansen # hwclock mån 1 nov 2004 00.35.38 -0.174339 sekunder citadel:/home/oehansen # hwclock --utc mån 1 nov 2004 00.37.52 -0.883456 sekunder citadel:/home/oehansen # date mån nov 1 01:37:53 CET 2004 citadel:/home/oehansen # I expected the same result as you pointed out. That when I would write 'hwclock' I'd get the cmos time, but when using 'hwclock --utc' I'd get the local time. But, when I specify the system to use UTC, the above is the result.
On Monday, 1 November 2004 01.39, Örn Hansen wrote:
måndag 01 november 2004 01:03 skrev Anders Johansson:
As the man page explains, hwclock *always* show the time in local time, regardless of how it's actually stored in CMOS
After re-configuration:
citadel:/home/oehansen # hwclock mån 1 nov 2004 00.35.38 -0.174339 sekunder citadel:/home/oehansen # hwclock --utc mån 1 nov 2004 00.37.52 -0.883456 sekunder citadel:/home/oehansen # date mån nov 1 01:37:53 CET 2004 citadel:/home/oehansen #
I expected the same result as you pointed out. That when I would write 'hwclock' I'd get the cmos time, but when using 'hwclock --utc' I'd get the local time. But, when I specify the system to use UTC, the above is the result.
Delete /etc/adjtime, that's what tells hwclock if the hardware clock is local or utc, then do "hwclock --utc --systohc" btw, for some reason - I guess I read your mail too quickly - I missed that it wasn't just the output from "hwclock" you were looking at, but that you were comparing it to "hwclock --utc". That's why my earlier mail was so confused. Sorry
The Monday 2004-11-01 at 00:56 +0100, Örn Hansen wrote:
It's what it *SHOULD* do, but look at here:
citadel:~ # hwclock mån 1 nov 2004 00.53.47 -0.452386 sekunder
citadel:~ # hwclock --utc mån 1 nov 2004 01.54.05 -0.105389 sekunder
hwclock is not ntp. They are diferent things.
I'm in CET, and the correct local time above is 0:53:47 ... alas, NTPD stores the time in LOCAL time, not UTC time, which explains why the clock was thought to be scewed above. Someone made a mess of things, with the implementation of NTPD, or SuSE in the configuration. I definately set my system to be UTC, and not local.
No, you are confusing the meaning of the --utc option. See the man page: --utc --localtime Indicates that the Hardware Clock is kept in Coordinated Universal Time or local time, respectively. It is your choice whether to keep your clock in UTC or local time, but nothing in the clock tells which you've chosen. So this option is how you give that information to hwclock. Those options only tell hwclock how to interpret the hardware - that is, the CMOS - clock. Thus, what the command shows differs. -- Cheers, Carlos Robinson
Ann Hopkins wrote:
I always tell myself that I need to write down how I solve this problem twice a year, but I either lose what I wrote or I just forget.
I run an ntp server for the pc's connected to my home network.
When daylight savings times rolls around I get errors about too large a difference to change the time. How would I fix this?
The best I can remember was I had to reboot the server and go into CMOS to change the time.
Shouldn't the server alway be on standard time (or preferably ITU) with the client figuring out the difference?
On Sunday 31 October 2004 16:01, James Knott wrote:
Ann Hopkins wrote:
I always tell myself that I need to write down how I solve this problem twice a year, but I either lose what I wrote or I just forget.
I run an ntp server for the pc's connected to my home network.
When daylight savings times rolls around I get errors about too large a difference to change the time. How would I fix this?
The best I can remember was I had to reboot the server and go into CMOS to change the time.
Shouldn't the server alway be on standard time (or preferably ITU) with the client figuring out the difference?
Set the hardware clock to UCT using Yast. I use the server at 130.149.17.21 (France). I didn't do anything to change the hour when rebooting today but it got it right. Try that server and see if anything goes right but not permanently.
On Sunday 31 October 2004 01:39, Ann Hopkins wrote:
I always tell myself that I need to write down how I solve this problem twice a year, but I either lose what I wrote or I just forget.
I run an ntp server for the pc's connected to my home network.
When daylight savings times rolls around I get errors about too large a difference to change the time. How would I fix this?
The best I can remember was I had to reboot the server and go into CMOS to change the time.
This is really odd. All my SuSE boxes that were running adjusted to the time change without problems. The only one that didn't is my own workstation which was turned off. When it rebooted it got the "time correction of -3602 seconds exceeds sanity limits" error. Since it was obviously the same time change for all boxes this appears to be related to the fact it was turned off. Is this expected behavior? Can any ntp gurus out there enlighten me (use small words please, I'm on my 1st cup of coffee). Jeff
Jeffrey Laramie wrote:
On Sunday 31 October 2004 01:39, Ann Hopkins wrote:
I always tell myself that I need to write down how I solve this problem twice a year, but I either lose what I wrote or I just forget.
I run an ntp server for the pc's connected to my home network.
When daylight savings times rolls around I get errors about too large a difference to change the time. How would I fix this?
The best I can remember was I had to reboot the server and go into CMOS to change the time.
This is really odd. All my SuSE boxes that were running adjusted to the time change without problems. The only one that didn't is my own workstation which was turned off. When it rebooted it got the "time correction of -3602 seconds exceeds sanity limits" error. Since it was obviously the same time change for all boxes this appears to be related to the fact it was turned off. Is this expected behavior? Can any ntp gurus out there enlighten me (use small words please, I'm on my 1st cup of coffee).
If you're sync'd to a NTP server, the change should occur automagically. This occured on my desktop system. I had to manually tell my notebook to connect to the server, at which point it adjusted itself to standard time.
The best I can remember was I had to reboot the server and go into CMOS to change the time.
This is really odd. All my SuSE boxes that were running adjusted to the time change without problems. The only one that didn't is my own workstation which was turned off. When it rebooted it got the "time correction of -3602 seconds exceeds sanity limits" error. Since it was obviously the same time change for all boxes this appears to be related to the fact it was turned off. Is this expected behavior? Can any ntp gurus out there enlighten me (use small words please, I'm on my 1st cup of coffee).
If you're sync'd to a NTP server, the change should occur automagically. This occured on my desktop system. I had to manually tell my notebook to connect to the server, at which point it adjusted itself to standard time.
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 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. Jeff
On Sunday 31 October 2004 07:14 am, Jeffrey Laramie wrote:
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 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.
Jeff
Sounds like your bios set daylight time off for you. -- _____________________________________ John Andersen
söndag 31 oktober 2004 22:36 skrev John Andersen:
On Sunday 31 October 2004 07:14 am, Jeffrey Laramie wrote:
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 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.
Jeff
Sounds like your bios set daylight time off for you.
The bios doesn't change the time, you can only do that manually there. And NTP, should always set the time according to UTC., unless you specify it recorded in local time.
On Sunday 31 October 2004 16:36, John Andersen wrote:
On Sunday 31 October 2004 07:14 am, Jeffrey Laramie wrote:
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 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.
Jeff
Sounds like your bios set daylight time off for you.
Nah, it was still set to daylight savings time. After reading Carlos's thesis on ntp, hwclock, etc., I've come to the conclusion that these people think setting the system clock to local time is a dumb idea and they don't want any part of it. ;-) e.g. I got what I deserved. I simply spent 15 seconds to change the hw clock manually and karma has been restored to my LAN. Time to move onto more cosmic issues like this one: http://slashdot.org/article.pl?sid=04/10/31/1735257 Later... Jeff
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
participants (11)
-
Anders Johansson -
Ann Hopkins -
Carlos E. R. -
Dana J. Laude -
James Knott -
Jeffrey Laramie -
John Andersen -
Leendert Meyer -
steve-ss -
ti＠amb.org -
Örn Hansen