Re: [opensuse] ntp can not manage to put the clock in sync - seems solved
In message [EMAIL PROTECTED], Carlos E. R. [EMAIL PROTECTED] writes 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: 4Marking 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: 6ACPI: CPU0 (power states: C1[C1] C2[C2]) 6ACPI: 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: usec states: C1: type[C1] promotion[C2] demotion[--] latency[000] usage[00356800] duration[] *C2: type[C2] promotion[--] demotion[C1] latency[090] usage[01088180] duration[033109569598] No, now is C1: nimrodel:~ # cat /proc/acpi/processor/CPU0/power active state:C1 max_cstate: C8 bus master activity: maximum allowed latency: usec states: *C1: type[C1] promotion[C2] demotion[--] latency[000] usage[00358448] duration[] C2: type[C2] promotion[--] demotion[C1] latency[090] usage[01102595] duration[033614061041] Anyway, it uses both states and clock seem to be running good - for the time being, at least. 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. -- Roger Hayter -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse] ntp can not manage to put the clock in sync - seems solved
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The Thursday 2007-12-13 at 21:38 -, 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse] ntp can not manage to put the clock in sync - seems solved
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The Saturday 2007-12-08 at 01:05 +0100, Carlos E. R. wrote: 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: I left the computer on all night, with no network, and... no drift! The error this morning was, surprise: 8 Dec 11:31:06 ntpd[26893]: offset 0.011621 sec freq -98.861 ppm error 0.002463 poll 7 8 Dec 11:51:44 ntpd[26893]: synchronized to 193.62..., stratum 1 8 Dec 11:51:49 ntpd[26893]: time reset +0.252153 s 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. Googling for 'acpi_pm' I find references to problems similar to mine on other distros, so there is definitely a problem somewhere in the kernel. The question on what are each clock type is also asked with no answer. The 'acpi_pm.c' source says: * Driver to use the Power Management Timer (PMTMR) available in some * southbridges as primary timing source for the Linux kernel. So that's not the typical cpu, IRQ based clock! The 'tsc.c' source says nothing: * This code largely moved from arch/i386/kernel/timer/timer_tsc.c * which was originally moved from arch/i386/kernel/time.c. * See comments there for proper credits. And I have no 'arch/i386/kernel/timer/' dir at all, not 'arch/i386/kernel/time.c' file. Good grief. Free code may be good and all that, but things are difficult to find out, unless you are an insider! [...] For instance, in http://marc.info/?l=linux-kernelm=117812987231998w=2 (march 2007) they say the clock is lossing time when the computer is iddling - which matches my findings, too, even though mine is a desktop, i686, 32 bits. - -- Cheers, Carlos E. R. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHWoL1tTMYHG2NR9URArBaAJ4kcaM7fCb7LpE8OlUvCE0hv/lmagCfS+r0 JkCxmhH8V6rKcF19wvIFndo= =OFzo -END PGP SIGNATURE- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse] ntp can not manage to put the clock in sync - seems solved
-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: 4Marking 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse] ntp can not manage to put the clock in sync - seems solved
On Saturday 08 December 2007 17:29:41 Carlos E. R. wrote: 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: 4Marking TSC unstable due to: possible TSC halt in C2. What is C2? A power state. It consumes less power than the full throttle mode Anders -- Madness takes its toll -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse] ntp can not manage to put the clock in sync - seems solved
-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: 4Marking 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: 6ACPI: CPU0 (power states: C1[C1] C2[C2]) 6ACPI: 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: usec states: C1: type[C1] promotion[C2] demotion[--] latency[000] usage[00356800] duration[] *C2: type[C2] promotion[--] demotion[C1] latency[090] usage[01088180] duration[033109569598] No, now is C1: nimrodel:~ # cat /proc/acpi/processor/CPU0/power active state:C1 max_cstate: C8 bus master activity: maximum allowed latency: usec states: *C1: type[C1] promotion[C2] demotion[--] latency[000] usage[00358448] duration[] C2: type[C2] promotion[--] demotion[C1] latency[090] usage[01102595] duration[033614061041] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
