-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Tuesday 2007-12-04 at 17:41 -0800, Joseph Loo wrote:

On Tue, 2007-12-04 at 20:24 -0500, James Knott wrote:

...

...

grep "time reset " /var/log/ntp | less

I get 24 Oct 19:41:38 ntpd[3347]: time reset -0.130426 s 29 Oct 18:20:20 ntpd[3433]: time reset -0.145680 s 8 Nov 03:11:41 ntpd[32375]: time reset +0.131260 s 13 Nov 18:56:36 ntpd[3396]: time reset -0.128489 s 28 Nov 14:59:49 ntpd[3396]: time reset -0.132907 s

I'm running 64 bit.

10 Nov 17:34:12 ntpd[3935]: time reset -0.232395 s 11 Nov 16:12:00 ntpd[4261]: time reset -0.348050 s 11 Nov 17:02:18 ntpd[4261]: time reset +0.363352 s 18 Nov 18:44:47 ntpd[4280]: time reset -0.202669 s Open Suse 10.3 64 bit

So you two don't have a problem. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHVgemtTMYHG2NR9URAieEAJ9a5wKlk8lDrp+z8cjUCkft+roolgCdHdLy m0hM20jG5ky0lDIhVp9I1g0= =vC3l -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Tue, 04 Dec 2007, by bill@bill-anderson.com:

Carlos E. R. wrote:

...

The Tuesday 2007-12-04 at 17:41 -0800, Joseph Loo wrote:

...

On Tue, 2007-12-04 at 20:24 -0500, James Knott wrote:

...

...

grep "time reset " /var/log/ntp | less

I get 24 Oct 19:41:38 ntpd[3347]: time reset -0.130426 s 29 Oct 18:20:20 ntpd[3433]: time reset -0.145680 s 8 Nov 03:11:41 ntpd[32375]: time reset +0.131260 s 13 Nov 18:56:36 ntpd[3396]: time reset -0.128489 s 28 Nov 14:59:49 ntpd[3396]: time reset -0.132907 s

I'm running 64 bit.

10 Nov 17:34:12 ntpd[3935]: time reset -0.232395 s 11 Nov 16:12:00 ntpd[4261]: time reset -0.348050 s 11 Nov 17:02:18 ntpd[4261]: time reset +0.363352 s 18 Nov 18:44:47 ntpd[4280]: time reset -0.202669 s Open Suse 10.3 64 bit

So you two don't have a problem.

-- Cheers, Carlos E. R.

I just checked my messages file, and I have not time reset messages

Same here. Log starts on 16 October. $ uname -srv Linux 2.6.22.12-0.1-default #1 SMP 2007/11/06 23:05:18 UTC $ ntptrace localhost: stratum 4, offset 0.000234, synch distance 0.079478 auth1.xs4all.nl: stratum 2, offset 0.006767, synch distance 0.037760 swisstime.ee.ethz.ch: stratum 2, offset -0.000021, synch distance 0.013900 Mainboard is an old(ish) Asus A7V600 Theo -- Theo v. Werkhoven Registered Linux user# 99872 http://counter.li.org ICBM 52 13 26N , 4 29 47E. + ICQ: 277217131 SUSE 10.3 + Jabber: muadib@jabber.xs4all.nl Kernel 2.6.22 + See headers for PGP/GPG info. Claimer: any email I receive will become my property. Disclaimers do not apply. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Tue, 04 Dec 2007, by bilwalsh@swbell.net:

Somewhere in the past I read that computers are wonderful machines. Capable of great things. BUT, they are horrible clocks.

The way it was explained was that when system use was high and resources were strained the clock was the last thing to get updated. Thus, it looses time. I'm sure it isn't near the problem it was many years ago but if your a power user it still could be a problem.

don't know where you got that from, but ever since the IBM AT, PC's have had a hardware clock on the mainboard, independent of the OS or user programs. The only thing that can make those thing fail is an empty battery or broken crystal. The crystals that make these hardware clocks tick aren't the best in terms of stability or accuracy of course, but with ntp for a daily dosage of 'realtime', there's nothing wrong with the basic concept. Theo -- Theo v. Werkhoven Registered Linux user# 99872 http://counter.li.org ICBM 52 13 26N , 4 29 47E. + ICQ: 277217131 SUSE 10.3 + Jabber: muadib@jabber.xs4all.nl Kernel 2.6.22 + See headers for PGP/GPG info. Claimer: any email I receive will become my property. Disclaimers do not apply. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2007-12-05 at 22:48 +0100, Theo v. Werkhoven wrote:

don't know where you got that from, but ever since the IBM AT, PC's have had a hardware clock on the mainboard, independent of the OS or user programs. The only thing that can make those thing fail is an empty battery or broken crystal.

The crystals that make these hardware clocks tick aren't the best in terms of stability or accuracy of course, but with ntp for a daily dosage of 'realtime', there's nothing wrong with the basic concept.

Er... However, that's not the clock the operating system uses when you ask for the time: not in Linux, not in msdos. Not in a X86 type PC, regardless of the operating system. There are two clocks on a PC. One is the CMOS clock, that runs out of battery, independent of system load, on an external chip somewhere in the mainboard (it is actually the same chip that holds the bios configuration data). However, the resolution of this clock is small, a second I think, and is slow to read. It can not be used as the system clock. This clock is only read once, when the system boots up, in order to set up the system clock. The system clock run originally as a timer or oscillator chip that interrupted the CPU about 19.2 times a second, and the CPU simply counted those interrupts, updating the "system clock". Today there are variations of this method, but the basis is the same. Suse programs this clock (in the kernel) to interrupt 250 times per second. Other possible settings are 100, 300 and 1000Hz. The kernel has been known to loose clock interrupts at the fast settings, specially the 1000 Hz one if a reiserfs is also used (because it dissable interrupts in some critical sections that last too long). This is known and documented; you can find references to this problem in the ntp bugzilla. Therefore, yes, a busy cpu can make the clock go slow. This is a fact. The kernel should compensate, though. However, my problem is often worse when the cpu is not busy at all. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHVzxqtTMYHG2NR9URAl5aAJ9ndfZV0YUledhTZRdGPcO3fF6OowCeMUxB rcdvN0ZE7v/vTaIeEzl4rtM= =0sFg -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Rajko M. wrote:

On Wednesday 05 December 2007 06:03:54 pm Carlos E. R. wrote:

...

The Wednesday 2007-12-05 at 22:48 +0100, Theo v. Werkhoven wrote:

...

don't know where you got that from, but ever since the IBM AT, PC's have had a hardware clock on the mainboard, independent of the OS or user programs. The only thing that can make those thing fail is an empty battery or broken crystal.

The crystals that make these hardware clocks tick aren't the best in terms of stability or accuracy of course, but with ntp for a daily dosage of 'realtime', there's nothing wrong with the basic concept.

Er...

However, that's not the clock the operating system uses when you ask for the time: not in Linux, not in msdos. Not in a X86 type PC, regardless of the operating system.

There are two clocks on a PC. One is the CMOS clock, that runs out of battery, independent of system load, on an external chip somewhere in the mainboard (it is actually the same chip that holds the bios configuration data). However, the resolution of this clock is small, a second I think, and is slow to read. It can not be used as the system clock.

This clock is only read once, when the system boots up, in order to set up the system clock.

The system clock run originally as a timer or oscillator chip that interrupted the CPU about 19.2 times a second, and the CPU simply counted those interrupts, updating the "system clock". Today there are variations of this method, but the basis is the same.

Suse programs this clock (in the kernel) to interrupt 250 times per second. Other possible settings are 100, 300 and 1000Hz. The kernel has been known to loose clock interrupts at the fast settings, specially the 1000 Hz one if a reiserfs is also used (because it dissable interrupts in some critical sections that last too long). This is known and documented; you can find references to this problem in the ntp bugzilla.

Therefore, yes, a busy cpu can make the clock go slow. This is a fact. The kernel should compensate, though.

However, my problem is often worse when the cpu is not busy at all.

It seems that you can try to compile kernel with HZ enabled and set for instance to 250 Hz and see if that helps.

This is current status with all 10.3 kernels:

~> grep HZ /boot/config-2.6.22.13-0.3-default CONFIG_NO_HZ=y # CONFIG_HZ_100 is not set CONFIG_HZ_250=y # CONFIG_HZ_300 is not set # CONFIG_HZ_1000 is not set CONFIG_HZ=250

BTW, with current computer clocks in GHz range, 1000 Hz system clock rate shouldn't be a problem (one tick on every few millions cycles), and so far I know it is even recommended for desktop systems, although I'm not sure is there any recent evaluation of gain.

FWIW I always recompile the suse kernel source with HZ=1000 on my gaming machine. Seriously, I get more frags, and get fragged less, that way... Joe -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Wednesday 05 December 2007 09:52:43 pm Carlos E. R. wrote:

The thing is, I don't know how these settings were in 10.2 or earlier.

It was not

[*] Tickless System (Dynamic Ticks)

That means disabling this, and enabling some of fixed will bring in the same state as 10.2. That doesn't take much time and can remove one possible reason for the problem. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2007-12-06 at 00:18 -0500, Aaron Kulkis wrote:

This is precisely why NTP was invented -- it solves this problem by obtaining time from calibrated time servers, and also takes into account network latency. Level 0

Don't you understand that NTP can not adjust my system clock and quits? 27 Nov 15:31:56 ntpd[12905]: synchronized to 91.121...., stratum 2 27 Nov 15:38:31 ntpd[12905]: synchronized to 192.33...., stratum 2 27 Nov 15:39:25 ntpd[12905]: synchronized to 195.55...., stratum 2 27 Nov 15:39:40 ntpd[12905]: synchronized to LOCAL(0), stratum 10 27 Nov 16:22:22 ntpd[12905]: synchronized to 84.88...., stratum 2 27 Nov 16:22:22 ntpd[12905]: time correction of 1678 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time. Or the smaller "time reset" events below: 5 Dec 11:28:31 ntpd[28229]: peer 147.83.123.136 event 'event_reach' (0x84) status 'unreach, conf, 1 event, event_reach' (0x8014) 5 Dec 11:32:50 ntpd[28229]: system event 'event_peer/strat_chg' (0x04) status 'sync_alarm, sync_ntp, 2 events, event_restart' (0xc621) 5 Dec 11:32:50 ntpd[28229]: synchronized to 194.238.48.2, stratum 2 5 Dec 11:32:50 ntpd[28229]: kernel time sync status change 0001 5 Dec 11:32:50 ntpd[28229]: system event 'event_sync_chg' (0x03) status 'leap_none, sync_ntp, 3 events, event_peer/strat_chg' (0x634) 5 Dec 11:32:50 ntpd[28229]: system event 'event_peer/strat_chg' (0x04) status 'leap_none, sync_ntp, 4 events, event_sync_chg' (0x643) 5 Dec 12:28:27 ntpd[28229]: offset -0.004594 sec freq 81.557 ppm error 0.004265 poll 7 5 Dec 12:49:02 ntpd[28229]: no servers reachable 5 Dec 12:58:24 ntpd[28229]: synchronized to 147.83.123.136, stratum 2 5 Dec 12:59:42 ntpd[28229]: time reset +4.674598 s 5 Dec 12:59:42 ntpd[28229]: system event 'event_clock_reset' (0x05) status 'sync_alarm, sync_unspec, 7 events, event_peer/strat_chg' (0xc074) 5 Dec 12:59:42 ntpd[28229]: system event 'event_peer/strat_chg' (0x04) status 'sync_alarm, sync_unspec, 8 events, event_clock_reset' (0xc085) 5 Dec 13:00:02 ntpd[28229]: peer 147.83.123.136 event 'event_reach' (0x84) status 'unreach, conf, 2 events, event_reach' (0x8024) 5 Dec 13:00:31 ntpd[28229]: peer 194.238.48.2 event 'event_reach' (0x84) status 'unreach, conf, 2 events, event_reach' (0x8024) 5 Dec 13:00:44 ntpd[28229]: peer 193.138.215.60 event 'event_reach' (0x84) status 'unreach, conf, 2 events, event_reach' (0x8024) 5 Dec 13:01:52 ntpd[28229]: peer 213.251.176.72 event 'event_reach' (0x84) status 'unreach, conf, 2 events, event_reach' (0x8024) 5 Dec 13:06:26 ntpd[28229]: synchronized to 213.251.176.72, stratum 3 5 Dec 13:11:30 ntpd[28229]: synchronized to 194.238.48.2, stratum 2 5 Dec 13:24:13 ntpd[28229]: time reset +581.195037 s 5 Dec 13:24:13 ntpd[28229]: system event 'event_clock_reset' (0x05) status 'sync_alarm, sync_unspec, 11 events, event_peer/strat_chg' (0xc0b4) 5 Dec 13:24:29 ntpd[28229]: peer 193.138.215.60 event 'event_reach' (0x84) status 'unreach, conf, 3 events, event_reach' (0x8034) - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHV9qhtTMYHG2NR9URApWMAJ0VQNsBG9M9D86TBrRYcW5actfujwCfVLrX 7RfQFgNLI7s1tHEwrpBxbK4= =a4RI -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2007-12-07 at 00:05 +1100, Basil Chupin wrote:

Carlos,

I haven't been paying too much attention to what you have written re the problem, what result do you get when you try setting the time manually, as root, from the command line? You know, the old

ntpdate -u <IP-address-of-time-server>

It works, of course. That's what I'm doing every time NTP quits. The problem is that NTP can't keep the system clock disciplined, it strays off as soon as NTP looses the network peers, and not a second or two, but several minutes. It seems a kernel problem, not an NTP problem. Look again the logs: 5 Dec 11:32:50 ntpd[28229]: synchronized to 194.238.48.2, stratum 2 5 Dec 11:32:50 ntpd[28229]: kernel time sync status change 0001 5 Dec 11:32:50 ntpd[28229]: system event 'event_sync_chg' (0x03) status 'leap_none, sync_ntp, 3 events, event_peer/strat_chg' (0x634) 5 Dec 11:32:50 ntpd[28229]: system event 'event_peer/strat_chg' (0x04) status 'leap_none, sync_ntp, 4 events, event_sync_chg' (0x643) 5 Dec 12:28:27 ntpd[28229]: offset -0.004594 sec freq 81.557 ppm error 0.004265 poll 7 5 Dec 12:49:02 ntpd[28229]: no servers reachable 5 Dec 12:58:24 ntpd[28229]: synchronized to 147.83.123.136, stratum 2 5 Dec 12:59:42 ntpd[28229]: time reset +4.674598 s At 12:49:02 it looses the network peer, and 10 minutes later it gets another, and finds it has to reset the clock by 4.6 seconds. A bit later: 5 Dec 12:59:42 ntpd[28229]: system event 'event_clock_reset' (0x05) status 'sync_alarm, sync_unspec, 7 events, event_peer/strat_chg' (0xc074) 5 Dec 12:59:42 ntpd[28229]: system event 'event_peer/strat_chg' (0x04) status 'sync_alarm, sync_unspec, 8 events, event_clock_reset' (0xc085) 5 Dec 13:00:02 ntpd[28229]: peer 147.83.123.136 event 'event_reach' (0x84) status 'unreach, conf, 2 events, event_reach' (0x8024) 5 Dec 13:00:31 ntpd[28229]: peer 194.238.48.2 event 'event_reach' (0x84) status 'unreach, conf, 2 events, event_reach' (0x8024) 5 Dec 13:00:44 ntpd[28229]: peer 193.138.215.60 event 'event_reach' (0x84) status 'unreach, conf, 2 events, event_reach' (0x8024) 5 Dec 13:01:52 ntpd[28229]: peer 213.251.176.72 event 'event_reach' (0x84) status 'unreach, conf, 2 events, event_reach' (0x8024) 5 Dec 13:06:26 ntpd[28229]: synchronized to 213.251.176.72, stratum 3 5 Dec 13:11:30 ntpd[28229]: synchronized to 194.238.48.2, stratum 2 5 Dec 13:24:13 ntpd[28229]: time reset +581.195037 s There, without loosing network fully, it has to reset the clock by 581 seconds, ie, 10 minutes error since less that an hour and a half after last reset! Ten minutes error! WTF is happening? :-/ - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHV/8gtTMYHG2NR9URArGmAJ9l1a0+/wW8vOIxo8AksQUn2W+kVgCdGUt9 7VFcK3QgyZzCvK8iWrTw8DA= =c7ys -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Neil Dawkins wrote:

Carlos E. R. wrote:

...

The Friday 2007-12-07 at 00:05 +1100, Basil Chupin wrote:

...

Carlos,

I haven't been paying too much attention to what you have written re the problem, what result do you get when you try setting the time manually, as root, from the command line? You know, the old

ntpdate -u <IP-address-of-time-server>

It works, of course. That's what I'm doing every time NTP quits.

The problem is that NTP can't keep the system clock disciplined, it strays off as soon as NTP looses the network peers, and not a second or two, but several minutes.

It seems a kernel problem, not an NTP problem.

Carlos,

I had a similar problem on one of my 10.3 servers.

I had to reset /sys/devices/system/clocksource/clocksource0/current_clocksource (in this case to jiffies).

To list available sources:

cat /sys/devices/system/clocksource/clocksource0/available_clocksource

Before 10.3 I have not experienced this issue.

Regards Neil

________________________________________________________________________ This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ________________________________________________________________________

I corrected the systemclock in the BIOS and the troubles were over André den Oudsten -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2007-12-06 at 14:43 -0000, Neil Dawkins wrote:

Carlos,

I had a similar problem on one of my 10.3 servers.

I had to reset /sys/devices/system/clocksource/clocksource0/current_clocksource (in this case to jiffies).

To list available sources:

cat /sys/devices/system/clocksource/clocksource0/available_clocksource

I have seen that. nimrodel:~ # cat /sys/devices/system/clocksource/clocksource0/available_clocksource acpi_pm pit jiffies tsc nimrodel:~ # cat /sys/devices/system/clocksource/clocksource0/current_clocksource acpi_pm I didn't know I could change the clock. How, writing the desired one to the "current..." file? Do you know of a link or file with documentation on each type of clock?

Before 10.3 I have not experienced this issue.

Same here... the problems started with 10.3. At least visible problems, any "time reset" message is bad. I'll try brute force... nimrodel:~ # echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource nimrodel:~ # cat /sys/devices/system/clocksource/clocksource0/current_clocksource tsc I'm not sure... I just updated the kernel tonight, and 45' after boot I see: Dec 6 22:14:08 nimrodel kernel: Clocksource tsc unstable (delta = 65620380907 ns) Dec 6 22:51:06 nimrodel kernel: set_rtc_mmss: can't update from 0 to 51 Dec 6 22:51:09 nimrodel syslog-ng[3946]: last message repeated 2 times Dec 6 22:51:09 nimrodel kernel: set_rtc_mmss: can't update from 1 to 51 Dec 6 22:51:35 nimrodel syslog-ng[3946]: last message repeated 22 times Dec 6 22:51:36 nimrodel kernel: set_rtc_mmss: can't update from 1 to 51 Lots of those messages till 23:09:54, then they stopped. Maybe the 'tsc' clock is bad and it switches to 'acpi_pm'. Perhaps I'll have to try them all. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHWJx5tTMYHG2NR9URAs+NAKCYXeF3pc3xfpVwsFBLBoTooVvA/wCeOb7Q w6+xIxtg70nensXuPARXyFc= =TilF -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2007-12-06 at 14:43 -0000, Neil Dawkins wrote:

Carlos,

I had a similar problem on one of my 10.3 servers.

I had to reset /sys/devices/system/clocksource/clocksource0/current_clocksource (in this case to jiffies).

To list available sources:

cat /sys/devices/system/clocksource/clocksource0/available_clocksource

Could you please report it here? https://bugzilla.novell.com/show_bug.cgi?id=350981 - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHd5EstTMYHG2NR9URAoXLAJ0VW8/ouPhkGNsKPgCQnUzLl1bROwCbBVBc 08Nrp14gXPYV7iezEYuBjJw= =u7HF -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Robert Smits wrote:

On December 6, 2007 05:54:39 am Carlos E. R. wrote:

...

The Friday 2007-12-07 at 00:05 +1100, Basil Chupin wrote:

...

Carlos,

I haven't been paying too much attention to what you have written re the problem, what result do you get when you try setting the time manually, as root, from the command line? You know, the old

ntpdate -u <IP-address-of-time-server> It works, of course. That's what I'm doing every time NTP quits.

The problem is that NTP can't keep the system clock disciplined, it strays off as soon as NTP looses the network peers, and not a second or two, but several minutes.

It seems a kernel problem, not an NTP problem.

Actually, it looks way more like a hardware problem than a software problem. Normally I can run any of my systems for more than a month without being more than a minute or two off. Have you considered that the backup battery may be low, or that you have a power supply problem?

Of course, one way to check it is if the same hardware shows different timing problems is to reinstall 10.2 but I know what a PITA that is.

Changing the CMOS battery would be simpler, and costs less than lunch in a restaurant. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2007-12-06 at 09:02 -0800, Robert Smits wrote:

...

It seems a kernel problem, not an NTP problem.

Actually, it looks way more like a hardware problem than a software problem. Normally I can run any of my systems for more than a month without being more than a minute or two off. Have you considered that the backup battery may be low, or that you have a power supply problem?

Please, remember that the system time does not use the cmos clock and battery at all. That's a different clock altogether. Plus, the cmos clock is running fine, I'm checking it at the moment.

Of course, one way to check it is if the same hardware shows different timing problems is to reinstall 10.2 but I know what a PITA that is.

It is very simple: 1 Nov 11:28:02 ntpd[4669]: time reset +0.493571 s 1 Nov 19:54:33 ntpd[6168]: time reset +0.324889 s 2 Nov 11:56:25 ntpd[6168]: time reset +0.493251 s 2 Nov 14:09:49 ntpd[6168]: time reset +0.761453 s 2 Nov 18:57:50 ntpd[6168]: time reset +0.267648 s 2 Nov 19:19:37 ntpd[6168]: time reset +0.633949 s 3 Nov 15:04:26 ntpd[4993]: time reset +13.963114 s <=== upgrade to 10.3 3 Nov 16:14:24 ntpd[4993]: time reset +126.365828 s 3 Nov 19:12:32 ntpd[5051]: time reset +42.074367 s 4 Nov 12:46:09 ntpd[5076]: time reset +22.996088 s 4 Nov 13:32:56 ntpd[5076]: time reset +393.672856 s 5 Nov 13:35:23 ntpd[5163]: time reset +351.141250 s You see how the resets increase just the very day I upgraded to 10.3? It is thus a demonstration that it is a software problem. I do have a partition with 10.2, I could try that one again. But there is no need, the above log proves it. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHWJ7XtTMYHG2NR9URAundAJ95D4ggQC4QvB81Rw1EPlMZE+ZE3QCdF68/ WHd8WOftZxd203s7Vps0NbE= =lw6f -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2007-12-06 at 17:26 -0800, Randall R Schulz wrote:

On Thursday 06 December 2007 17:16, Carlos E. R. wrote:

...

...

Please, remember that the system time does not use the cmos clock and battery at all. That's a different clock altogether. Plus, the cmos clock is running fine, I'm checking it at the moment.

"... at all ...?" I don't think this is really true, is it?

When the system starts up, the Linux kernel initializes it's notion of the current time from the mainboard's CMOS clock (which, on all machines built in the past twenty years or more, is powered and running even when the computer is powered down and even disconnected from the mains; that's in part what the battery is for).

I know that. I actually wrote a howto on that ;-) What I mean is that during normal system use it is not used at all. It is read on boot, and written on halt (and I think on NTP stop, by the script, not the daemon).

Thereafter, the Linux kernel updates its time based on a timer interrupt, also generated by local hardware, of course. These timers are, as has been noted, not particularly accurate and often exhibit considerable drift over even moderate real-time intervals.

Not really. I have been using this same machine without permanent network, and thus, no NTP, for years, and the clock drift was about a second or two per day.

Likewise, if the system cannot contact an NTP server, it has a reasonable guess as to the current time, and it makes do with that.

It should be able to keep accurate time for hours, even days. This was so with previous suse versions, but not with 10.3. It drifts minutes in half an hour. This is unthinkable! - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHWKQStTMYHG2NR9URArE/AJ9SHN6YTdaAi7+u8O2CohAzKdNZVQCgl3/G x2t2RjuZSl4uB3bIbSQwCsU= =4bdy -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2007-12-06 at 17:49 -0800, Joseph Loo wrote:

It does sound like your driftfile is messed up.

Which one? There are two. /var/lib/ntp/drift/ntp.drift? Certainly it is. I did try removing it to force NTP to recalculate it. No effect. /etc/adjtime? No. And has no effect during system use. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHWK4ltTMYHG2NR9URAmd8AJ4/KUKQLMM8UxC2RB5najztGEwU1wCdFWEA GVnpLsu0GFIP8DRDQBK+pFM= =6lbS -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2007-12-07 at 18:26 -0800, Joseph Loo wrote:

...

...

It does sound like your driftfile is messed up.

Which one? There are two.

/var/lib/ntp/drift/ntp.drift? Certainly it is. I did try removing it to force NTP to recalculate it. No effect.

/etc/adjtime? No. And has no effect during system use.

My understanding the ntp.drift is the one one that contains the information for the drift with the adjtime used for the cmos. I could be wrong though.

No... There is a file, '/etc/adjtime', which holds a correction applied to the time read from the cmos clock when the system boots, to compensate for the known estimated error of the cmos clock while the computer was powered off. Ie, if the computer was off 20 hours, and the cmos, battery powered, clock errors 0.1"/h, then the time will be corrected by 2 seconds before setting the system time. This file is not touched by ntpd; it is calculated and written by hwclock. Then, there is another file, '/var/lib/ntp/drift/ntp.drift', which holds the drift compensation currently applied by ntpd to the system or cpu time, in parts per million. Ie, the speed of the system clock is modified and calculated continuously. Well, not continuously, but when the ntpd daemon sees fit. This compensation does not apply to the CMOS clock, which is independent. The trick of deleting '/etc/adjtime' is used when the time is wrong right after booting, and in every boot, to force the computer to recalculate a new factor. It has no effect once the computer is running and the hour is set by whatever means; it will have effect on the next boot. That is not the problem I'm having, thus deleting that file will have no effect. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHWgh7tTMYHG2NR9URAmUqAJ0dVw50Lq1Thmua/EEhW+Q7vsAA8gCdEmCd 06HQw+MjQ+32FecJoooWdtw= =4N+i -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2007-12-06 at 17:58 -0800, Randall R Schulz wrote:

...

Not really. I have been using this same machine without permanent network, and thus, no NTP, for years, and the clock drift was about a second or two per day.

Then you have the luck of getting a pretty good crystal. That's just a matter of luck. One second per day is 0.0000116 or 0.00116% error.

Normal wrist watches are usually specified to 4 seconds per day at worst. Two seconds is typical.

...

It should be able to keep accurate time for hours, even days. This was so with previous suse versions, but not with 10.3. It drifts minutes in half an hour. This is unthinkable!

Clearly this represents a gross hardware failure or a similarly extreme software problem.

As the problem started the very same day I upgraded to suse 10.3, that points to software.

You might want to try to quantify the error to a few decimal places. I

Unfortunately, it appears to be random :-( 1 Nov 11:28:02 ntpd[4669]: time reset +0.493571 s 1 Nov 19:54:33 ntpd[6168]: time reset +0.324889 s 2 Nov 11:56:25 ntpd[6168]: time reset +0.493251 s 2 Nov 14:09:49 ntpd[6168]: time reset +0.761453 s 2 Nov 18:57:50 ntpd[6168]: time reset +0.267648 s 2 Nov 19:19:37 ntpd[6168]: time reset +0.633949 s 3 Nov 15:04:26 ntpd[4993]: time reset +13.963114 s <=== upgrade to 10.3 3 Nov 16:14:24 ntpd[4993]: time reset +126.365828 s 3 Nov 19:12:32 ntpd[5051]: time reset +42.074367 s 4 Nov 12:46:09 ntpd[5076]: time reset +22.996088 s 4 Nov 13:32:56 ntpd[5076]: time reset +393.672856 s 5 Nov 13:35:23 ntpd[5163]: time reset +351.141250 s Different amounts, often minutes after network peer is lost; perhaps an adsl reset. To calculate the drift I'd have to catch the computer in the act, and then compare the time accurately over a period. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHWK/htTMYHG2NR9URAtlyAJ4q7YEcJpV765qBYSd54GIXzqZlpgCcCU5R 2G9r0oc6GJbEou+DI+hyqv8= =iH4k -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2007-12-07 at 14:56 +1100, Basil Chupin wrote:

...

As the problem started the very same day I upgraded to suse 10.3, that points to software.

I note that you keep stating that you UPGRADED from 10.2 to 10.3. Does this mean a NEW installation? If not, is it possible that there is old 10.2 crud hanging around causing you lack of sleep?

No, I mean upgraded. However, the clock is a kernel thing, and the kernel file is new, and the modules directory is new. What you say could only affect config files. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHWTk9tTMYHG2NR9URApx1AJ4y4adRrBwpIeigEQIL5dY/3U12XACfWCta AqJY6zE+vRswUAECla/JU1Q= =z/LQ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2007-12-07 at 03:31 -0500, Aaron Kulkis wrote:

In your first post, one of your own logfile excerpts shows a line where it is syncing to a strata 10 source. Every line after that shows attempts to re-sync to a strata 2 source, with very large corrections, and if I remember correctly, fails to do so.

Perhaps you should comment out your strata 10 source.

That's the local system clock: 27 Nov 15:39:40 ntpd[12905]: synchronized to LOCAL(0), stratum 10 And I have disabled the local source on the config, no effect: server 127.127.1.0 # local clock (LCL) fudge 127.127.1.0 stratum 10 # LCL is unsynchronized

+ 27 Nov 15:31:56 ntpd[12905]: synchronized to 91.121...., stratum 2 + 27 Nov 15:38:31 ntpd[12905]: synchronized to 192.33...., stratum 2 + 27 Nov 15:39:25 ntpd[12905]: synchronized to 195.55...., stratum 2 + 27 Nov 15:39:40 ntpd[12905]: synchronized to LOCAL(0), stratum 10 + 27 Nov 16:22:22 ntpd[12905]: synchronized to 84.88...., stratum 2 + 27 Nov 16:22:22 ntpd[12905]: time correction of 1678 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time.

When the network peers are lost, it connects to the local clock. When it gets again a network peer, it discovers the error. After I disabled the local clock, it appears to find a peer faster; but that's early to say, because the "sanity" error /only/ happened 5 times in a month. Now I get the reset oftener.

...

It should be able to keep accurate time for hours, even days. This was so with previous suse versions, but not with 10.3. It drifts minutes in half an hour. This is unthinkable!

Because after it loses its strata 3 network source, it reverts to the strata 10 source (CMOS clock on the motherboard), and that's when your problems begin.

No, that's not the cmos clock. That's the system clock. The cmos clock is correct to the second: nimrodel:~ # cat /sys/devices/system/clocksource/clocksource0/current_clocksource ; cat /var/lib/ntp/drift/ntp.drift ; hwclock --show ; date tsc - -11.841 Fri Dec 7 13:25:20 2007 -0.520012 seconds Fri Dec 7 13:25:20 CET 2007 If the ntp where really using the cmos clock as a source there would be no problem: it is a faithful clock. But that can not be used as a source because querying the cmos clock is an "expensive" task. It is a read of two i/o ports and very slow: you try, try "hwclock --show ; date" and you will see that it takes about a second to respond - actually, the number with decimals is related to that time: nimrodel:~ # time ( hwclock --show ; date ) Fri Dec 7 13:33:19 2007 -0.975686 seconds Fri Dec 7 13:33:19 CET 2007 real 0m0.982s user 0m0.004s sys 0m0.000s nimrodel:~ # time ( hwclock --show ; date ) Fri Dec 7 13:33:27 2007 -0.944349 seconds Fri Dec 7 13:33:27 CET 2007 real 0m0.951s user 0m0.000s sys 0m0.004s nimrodel:~ # time ( hwclock --show ; date ) Fri Dec 7 13:33:33 2007 -0.437496 seconds Fri Dec 7 13:33:33 CET 2007 real 0m0.444s user 0m0.000s sys 0m0.008s - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHWT4LtTMYHG2NR9URAtktAJ9lmm/XrRAXy1CB5bVkGRx/sbNpMACfe9/C ohN/oyVkW7Bcx5Ytyl24tAQ= =YaF2 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2007-12-07 at 00:15 -0600, David C. Rankin wrote:

I seem to recall that you can adjust the drift of the system clock within ntp. I don't know if this will cure your problems, but it can't hurt to check. The file is /var/lib/ntp/drift/ntp.drift.

The value I have is: 10.460

That number changes a lot. I often see it around 80. Yesterday it was about 40, today it is -11, but it started at 4 two hours ago. There would be no good obtained from me touching it, as ntp is changing it continuosly. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHWT8otTMYHG2NR9URAv1/AJ90uSSaDhbef/7oqpjsv1V8AMDeQwCeJIT1 52K+h75imWmmSK5d+RHSZBk= =L1sC -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2007-12-07 at 08:47 +0100, Hans Witvliet wrote:

On Fri, 2007-12-07 at 02:16 +0100, Carlos E. R. wrote:

...

You see how the resets increase just the very day I upgraded to 10.3? It is thus a demonstration that it is a software problem. I do have a partition with 10.2, I could try that one again. But there is no need, the above log proves it.

Well proven,

Thanks.

Latest patches were applied?

Yep. The only one I'm withholding is the samba update, because it is broken (I get core dumps continuously - reported and known problem).

My college builded last week a 10.3 system with truly very strange behaviour. We found out that the system clock --> was standing stil <--.

Arghh! :-/

Havoc! ntp would not work (drift to large), could not update, Only after a manually ntpdate he could repair the system.

Uff.. That's awful. Did he try changing the clocksource? Did he open a bugzilla? You say "could repair". What was wrong, how did he solve it?

btw, you know that you have to be carefull with xen & time... (don't know if this relevant in your case)

I didn't know, but I don't use xen. I have vmware, but I haven't used it since before I upgraded, so that's not an issue - yet. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHWUCftTMYHG2NR9URAllLAJ9aIZsAH8p/m0lXIgV/zS5ISvVahACfe9o+ PRdVJXddbKhCAC/ag6FasUE= =oikA -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2007-12-06 at 12:20 -0500, Aaron Kulkis wrote:

Your logs says that when NTP looses the network connection,

Yes.

it is syncing to the CMOS clock.

No. You are confusing the system clock with the CMOS clock - which is running fine, by the way. I checked. More symptoms: the problem started the very same day I installed 10.3. it's in the logs. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHWJ2htTMYHG2NR9URAkRjAKCDwiEKhvS9IoPJzm3uUfYSw9TWLQCdHtji PNkKp+nNf3RQNb/LxnvmvZ4= =FM4B -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2007-12-07 at 03:31 -0500, Aaron Kulkis wrote:

...

...

Your logs says that when NTP looses the network connection,

Yes.

...

it is syncing to the CMOS clock.

No.

You are confusing the system clock with the CMOS clock - which is running fine, by the way. I checked.

Your original posting has part of a log which clearly indicates a sync to a strata 10 source, and all of your problems started right after that.

+ 27 Nov 15:31:56 ntpd[12905]: synchronized to 91.121...., stratum 2 + 27 Nov 15:38:31 ntpd[12905]: synchronized to 192.33...., stratum 2 + 27 Nov 15:39:25 ntpd[12905]: synchronized to 195.55...., stratum 2 + 27 Nov 15:39:40 ntpd[12905]: synchronized to LOCAL(0), stratum 10 + 27 Nov 16:22:22 ntpd[12905]: synchronized to 84.88...., stratum 2 + 27 Nov 16:22:22 ntpd[12905]: time correction of 1678 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time.

The CMOS clock is defined as a strata 10 time source in the ntp.conf file in the RPM package.

Which entry is the cmos clock? This? server 127.127.1.0 # local clock (LCL) fudge 127.127.1.0 stratum 10 # LCL is unsynchronized clockopt.html: ] The fudge command is used to provide additional information for ] individual clock drivers and normally follows immediately after the ] server command. The address argument specifies the clock address. The ] refid and stratum options control can be used to override the defaults ] for the device. There are two optional device-dependent time offsets and ] four flags that can be included in the fudge command as well. That clock is not the CMOS clock. It is the CPU, system clock, which NTP uses as a selfstrapping clock when it loses the network clock. And it is already disabled: no difference.

...

More symptoms: the problem started the very same day I installed 10.3. it's in the logs.

interesting.

Was your your ntp.conf file change at that time -- either by the upgrade or by you?

Nop, not touched at all, that day at least. Later, yes, of course, trying to solve this problem. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHWUObtTMYHG2NR9URAtxhAJsHy5qxQGxOFq6V/OEj1c8m6jZlHQCfZEOS JBOZIy5XrcJ3wNur1u94YKY= =mbOp -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2007-12-06 at 09:52 -0800, Sloan wrote:

...

It seems a kernel problem, not an NTP problem.

Just out of curiosity, are you running the stock suse kernel, or did you install something newer. I'd never had any problem with ntp on the stock kernel, but when I installed 2.6.23 I noticed that ntp would not run. Same thing with 2.6.24-rc4. I wanted to check out the new scheduler and it's effect on my frag rate, but with the ntp problems, I decided to just recompile the suse kernel source with HZ=1000 and be done with it. With the suse kernel, ntp is happy and running again.

Yesterday, I was running the suse kernel recompiled by me. Today I upgraded the new suse kernel, so it is the stock unmodified one. nimrodel:~ # uname -a Linux nimrodel 2.6.22.13-0.3-default #1 SMP 2007/11/19 15:02:58 UTC i686 i686 i386 GNU/Linux I have tried several frequency settings, from 250 (default) to 1000. No appreciable difference regarding this problem. I read a bugzilla at the NTP site, and it appears they think the linux kernel is broken regarding time adjustment and don't want to hear anything linux related :-( - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHWKBZtTMYHG2NR9URAnUuAJ4smKgINegpb5IIN1O7JF2p4raVBACfbp6y Y/hMyxHthhnfwfpM/iVDN38= =blrA -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2007-12-06 at 20:34 -0600, Rajko M. wrote:

...

I read a bugzilla at the NTP site, and it appears they think the linux kernel is broken regarding time adjustment and don't want to hear anything linux related

Have you disabled: [*] Tickless System (Dynamic Ticks) this is new in 10.3 comparing to 10.2.

Not yet. I think I will compile the kernel tomorrow: it takes about three hours in this machine. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHWLJmtTMYHG2NR9URAqBWAJ0cdEG0E6EkNz/UsRYmWevViFoMFwCZAZAP RSgTcqpwWyhMY5FwZtxo2Vc= =Lujg -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2007-12-07 at 16:45 -0600, Rajko M. wrote:

...

...

Have you disabled: [*] Tickless System (Dynamic Ticks) this is new in 10.3 comparing to 10.2.

Not yet. I think I will compile the kernel tomorrow: it takes about three hours in this machine.

So, what happened Carlos. Any change?

Not yet, I couldn't... however, I have been running tests. I wrote a cronjob to compare the system clock to the cmos clock every 5 minutes, and the difference varies between 0 and 1 seconds for several hours. Then I disconnected the router, to force ntpd to be unable to connect to its peers... and not 1" error! No drift! I'm astonished. I have an email pending with some logs of this, I'll send it promptly. The only thing I did was to force the kernel to use the 'tsc' clock instead of the 'acpi_pm' clocksource it was using: Dec 7 01:59:21 nimrodel kernel: Time: tsc clocksource has been installed. I don't understand. The tsc source had given errors previously: Dec 6 22:14:08 nimrodel kernel: Clocksource tsc unstable (delta = 65620380907 ns) Dec 6 22:51:06 nimrodel kernel: set_rtc_mmss: can't update from 0 to 51 Dec 6 22:51:09 nimrodel syslog-ng[3946]: last message repeated 2 times Dec 6 22:51:09 nimrodel kernel: set_rtc_mmss: can't update from 1 to 51 Dec 6 22:51:35 nimrodel syslog-ng[3946]: last message repeated 22 times Dec 6 22:51:36 nimrodel kernel: set_rtc_mmss: can't update from 1 to 51 Dec 6 22:52:00 nimrodel syslog-ng[3946]: last message repeated 17 times I will have to watch this for a longer time, but... I wish I knew the difference of each type of clock, I could do an informed selection. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHWd+6tTMYHG2NR9URAu9nAJ437+abI7qgIBMdNCCruwbYEnlLtQCeIXit 2W5w2WJOJ5hnrpKSImA7CTc= =EpU8 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2007-12-07 at 19:35 -0500, Patrick Shanahan wrote:

...

The only thing I did was to force the kernel to use the 'tsc' clock instead of the 'acpi_pm' clocksource it was using:

mine is set to jiffy, but i'm still on 10.1 x86_64

jiffy seems to be the classic clock method. Wish I knew. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHWeu2tTMYHG2NR9URAhfnAJ9ac35Fxd3nxxo5AD3qg+s/Idc9FACgkKko kTqD+q+JjTR1fxbCyCrgHD0= =HFXq -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Saturday 2007-12-08 at 12:41 +0100, I wrote: ...

Less than half a second of error, with no network! This is indeed surprising.

It seems that my computer works better with the 'tsc' clocksource than with the 'acpi_pm' one. Now the problem is to know why 'tsc' was rejected on boot or later.

Because of this: <4>Marking TSC unstable due to: possible TSC halt in C2. What is C2? Dec 8 13:51:36 nimrodel kernel: Time: tsc clocksource has been installed. Dec 8 13:56:52 nimrodel kernel: Clocksource tsc unstable (delta = 32800377181 ns) Nevertheless, the system clock using TSC is stable, and when it uses acpi_pm id delays entire minutes. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHWsZ4tTMYHG2NR9URArZTAJ9L2gLOo9Q3S81d93gHaaFzpbou+QCfVfIT VI9wEP88+Ou501PfrIlIgMw= =XjHJ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Saturday 2007-12-08 at 18:39 +0100, Anders Johansson wrote:

On Saturday 08 December 2007 17:29:41 Carlos E. R. wrote:

...

Because of this:

<4>Marking TSC unstable due to: possible TSC halt in C2.

What is C2?

A power state. It consumes less power than the full throttle mode

Ah, ok. Then it shouldn't be a problem. Previously (for years), the kernel said my cpu has no throtling capability. Now it is different: <6>ACPI: CPU0 (power states: C1[C1] C2[C2]) <6>ACPI: Processor [CPU0] (supports 2 throttling states) and current state is C2: nimrodel:~ # cat /proc/acpi/processor/CPU0/power active state: C2 max_cstate: C8 bus master activity: 4009d011 maximum allowed latency: 6666 usec states: C1: type[C1] promotion[C2] demotion[--] latency[000] usage[00356800] duration[00000000000000000000] *C2: type[C2] promotion[--] demotion[C1] latency[090] usage[01088180] duration[00000000033109569598] No, now is C1: nimrodel:~ # cat /proc/acpi/processor/CPU0/power active state: C1 max_cstate: C8 bus master activity: 00000000 maximum allowed latency: 6666 usec states: *C1: type[C1] promotion[C2] demotion[--] latency[000] usage[00358448] duration[00000000000000000000] C2: type[C2] promotion[--] demotion[C1] latency[090] usage[01102595] duration[00000000033614061041] Anyway, it uses both states and clock seem to be running good - for the time being, at least. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHWzCgtTMYHG2NR9URAvkEAJwN15rRnLhcrezZo3qkYaC2ZhDAqwCffHKw WgiAHxago5EYlpQsognBSPg= =iyuf -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2007-12-13 at 21:38 -0000, Roger Hayter wrote:

I don't think it is directly related to your problem, but as an example where the Linux system clock is not good enough for ntp I have a machine runing SuSE 9.3 which gains 0.28 seconds every hour on system time (nothing to do with CMOS clock!!). "ntpd" just refuses to synchronise this machine, and from the docs I gather this is expected behaviour if system time is too far out. I assumed this might be a hardware problem, perhaps an unstable or incorrect CPU clock signal.

I don't believe in hardware problems. I think it is bad programming somewhere. Or the wrong choice of clock type by the kernel. Do 'ls /sys/devices/system/clocksource/'. There should be a directory there (if there are more I don't know what they are) named "clocksource0". Look in there. There should be two files there: available_clocksource and current_clocksource. Do a 'cat' on both: nimrodel:~ # cat /sys/devices/system/clocksource/clocksource0/* acpi_pm pit jiffies tsc tsc nimrodel:~ # One is the types of system clocks in your system the kernel knows about, and the other is the one it is using. I know very little about them. The acpi_pm is related to some acpi hardware, and in mine is very wrong. The pit one I have no idea. The tsc one seems correct in mine, but may be problematic: I'm watching it closely. I don't know what type of clock it is really. The jiffies type is the classic one, I think. Try that one on your pc, it should work - this command changes the running clock: echo jiffies > /sys/devices/system/clocksource/clocksource0/current_clocksource If I'm correct, this one is simply a counter updated by an interrupt from an 8250? oscillator. The frequency of this oscillator can be corrected: that's what ntp does, I think. An educated guess on my part, of course. HTH - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHYdUytTMYHG2NR9URAjnSAKCX6PTvILpgvVXMLn2ChyW8VvQubwCfUhPk BTXhSInWVuDmOjTTRd4MXX8= =IKVS -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2007-12-07 at 08:54 +0100, Frank Fiene wrote:

Sorry for intervening, i haven't read the whole thread!

Do you run Linux in a VM infrastructure like VMware?

No... - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHWUO9tTMYHG2NR9URAsSSAJ4t6/GOxkC0HRaYaVKGq+YdIEO2LACfW/6c zUeomwz5p/u1bytnXunEqi4= =7B6R -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Aaron Kulkis wrote:

Carlos E. R. wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

The Thursday 2007-12-06 at 00:18 -0500, Aaron Kulkis wrote:

...

This is precisely why NTP was invented -- it solves this problem by obtaining time from calibrated time servers, and also takes into account network latency. Level 0

Don't you understand that NTP can not adjust my system clock and quits?

Yes I do.

I was explaining NTP it to Billie Walsh, who didn't seem to understand that NTP is a method of keeping accurate time.

I believe that NTP has an option for updating the time in your CMOS clock.

If I remember right Aaron wrote in an earlier e-mail that when his NTP synchronization quit his clock went squirreling of to who knows where. I use, and have for a LONG time, NTP to synch my clocks. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Fri, 2007-12-07 at 02:30 +0100, Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

The Thursday 2007-12-06 at 12:11 -0500, Aaron Kulkis wrote:

...

...

Don't you understand that NTP can not adjust my system clock and quits?

Yes I do.

I was explaining NTP it to Billie Walsh, who didn't seem to understand that NTP is a method of keeping accurate time.

Ok.

...

I believe that NTP has an option for updating the time in your CMOS clock.

Haven't seen it. Certainly, not in my config. The cmos clock is running fine; actually, I'm thinking of running a cron job to compare both cmos and system clocks and log it and sound a horn if they differ more than two seconds:

nimrodel:~ # hwclock --show ; date Fri Dec 7 02:26:57 2007 -0.036220 seconds Fri Dec 7 02:26:57 CET 2007

- -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux)

iD8DBQFHWKJEtTMYHG2NR9URAtTOAJ9Wgye6LzhfhoGSUNY3qQpHUUtVWACfRQr+ DDQjdd27lwsUR+kVkDIPEDk= =46Fl -----END PGP SIGNATURE----- I believe that the CMOS clock is updated when you shutdown. There is a specific routine that synchronize the cmos clock.

Could I make a suggestion that you try the following servers in your ntp configuration, you can use yast to do the configuration and test of the server: 0.pool.ntp.org 1.pool.ntp.org 2.pool.net.org I suggest those files because there is a protocol among the different strata time server. Many of them request that you inform them of your use. You can read more about the pool.ntp.org at http://www.pool.ntp.org/ -- Joseph Loo jloo@acm.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Aaron Kulkis wrote:

Billie Walsh wrote:

...

Somewhere in the past I read that computers are wonderful machines. Capable of great things. BUT, they are horrible clocks.

The way it was explained was that when system use was high and resources were strained the clock was the last thing to get updated. Thus, it looses time. I'm sure it isn't near the problem it was many years ago but if your a power user it still could be a problem.

This is precisely why NTP was invented -- it solves this problem by obtaining time from calibrated time servers, and also takes into account network latency. Level 0 sources are atomic clocks (such as run by the US Naval Observatory -- navies have VERY high interest in extremely accurate timekeeping because accurate navigation depends on it), Level 1 sources obtain their time from Level 0 sources, Level 2 from Level 1, etc. Most Level 0 and Level 1 sources are not for use by the general public.

Actually, there are several types of stratum (not level) 0 clocks. You can get receivers that will get time from GPS, CDMA cell phone network or a time & frequency standard broadcast such as WWV in the U.S. or CHU in Canada. Of course, all of those are traceable to some national atomic clock and all can be considered stratum 0.

Level 1 sources prefer that only 1 or a very very small percentage (like 1 in a 1000) of an organization's machines get time from the Level 1, and then use those hosts as Level 2 time hosts, which are then to serve the rest of the organization.

Do not under ANY circumstances get NTP time from a Level 0 time server without explicit permission from whoever owns or has the responsibility of operating it. If you need a level 0 time server, then you can get a device which recieves a radio signal from a US Navy Observatory, and connects to a communications port in your computer. These tend to run in the US $100 - $200 range, and will provide time accurate within 1 microsecond.

Actually, the signal comes from WWV or WWVB in Colorado or similar station (WWVH) in Hawaii. Many other countries have their own time & frequency standard broadcasts, such as CHU in Canada. You can also get an accurate time source from the PBS television network in the U.S. This is often used to set clocks in TV's and VCR's. I have a clock here, that receives the signal from WWVB. I bought it from a consumer electronics store.

In most NTP configuration files, the CMOS clock on the motherboard is rated as level 10 (kind of a "last resort"). I have no idea why onboard CMOS clocks are less accurate than a US $5 wristwatch which includes an LCD display in that price.

That would depend entirely on the accuracy of the crystal used. Watches often have trimmers, which allow the oscillator to be adjusted to improve accuracy. I have never seen one on in a computer. -- Use OpenOffice.org http://www.openoffice.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org