Re: [opensuse] ntp can not manage to put the clock in sync.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The Thursday 2007-12-06 at 14:43 -, 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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]
Re: [opensuse] ntp can not manage to put the clock in sync.
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 Do you know of a link or file with documentation on each type of clock? Sorry, found a link on a xen mailing list (server is a Xen Dom0 host), but haven't kept it. 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 have set clocksource=jiffies as a boot parameter. After this all my ntp time sync problems disappeared. 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. Can't comment on tsc, I've never used it. However, on a laptop with a new 10.3 install (standard kernel) acpi_pm did give me the same problems - changing to jiffies solved the problem for me. 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 -- 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.
Carlos E. R. wrote: -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). 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. + 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. 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! 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. -- 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.
-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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse] ntp can not manage to put the clock in sync.
-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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse] ntp can not manage to put the clock in sync.
-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 real0m0.982s user0m0.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 real0m0.951s user0m0.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 real0m0.444s user0m0.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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse] ntp can not manage to put the clock in sync.
-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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse] ntp can not manage to put the clock in sync.
Carlos E. R. wrote: -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. 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. 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? -- 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.
-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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse] ntp can not manage to put the clock in sync.
-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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse] ntp can not manage to put the clock in sync - it's not the CMOS clock
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The Wednesday 2007-12-05 at 00:42 +0100, I wrote: I'm investigating a problem I'm having with the clock getting very slow, and I have traced the problem to something new in opensuse 10.3. Some suggested that the CMOS clock could be running bad. While I'm sure the CMOS clock doesn't have anything to do, I wrote a cron job to make sure: it compares the system clock to the cmos clock every five minutes, and logs the possible error to syslog. It has been running the whole afternoon, and at most the difference is one second: Dec 7 16:25:02 nimrodel CLOCK: CMOS clock differs 1 at 16:25:02 Dec 7 16:50:02 nimrodel CLOCK: CMOS clock differs 1 at 16:50:02 Dec 7 17:50:02 nimrodel CLOCK: CMOS clock differs 1 at 17:50:02 Dec 7 17:55:02 nimrodel CLOCK: CMOS clock differs 1 at 17:55:02 Dec 7 18:10:02 nimrodel CLOCK: CMOS clock differs 1 at 18:10:02 Dec 7 18:25:02 nimrodel CLOCK: CMOS clock differs 1 at 18:25:02 Dec 7 18:40:02 nimrodel CLOCK: CMOS clock differs 1 at 18:40:02 Dec 7 18:50:02 nimrodel CLOCK: CMOS clock differs 1 at 18:50:02 Dec 7 19:00:02 nimrodel CLOCK: CMOS clock differs 1 at 19:00:02 Dec 7 19:15:02 nimrodel CLOCK: CMOS clock differs 1 at 19:15:02 Dec 7 19:20:02 nimrodel CLOCK: CMOS clock differs 1 at 19:20:02 Dec 7 19:35:02 nimrodel CLOCK: CMOS clock differs 1 at 19:35:02 Dec 7 20:00:02 nimrodel CLOCK: CMOS clock differs 1 at 20:00:02 Dec 7 20:30:02 nimrodel CLOCK: CMOS clock differs 1 at 20:30:02 Dec 7 21:05:02 nimrodel CLOCK: CMOS clock differs 1 at 21:05:02 Dec 7 21:15:02 nimrodel CLOCK: CMOS clock differs 1 at 21:15:02 Dec 7 22:20:02 nimrodel CLOCK: CMOS clock differs 1 at 22:20:02 And not always, the error gets corrected. Now, I should provoke a network error by powering down the adsl router and find out if either the system clock or cmos clock drifts. [...] One hour forty five minutes without network, and not a second of drift! Go figure... the clock is running fine now. Maybe the 'tsc' clock runs better than the 'acpi_pm' one on my machine... if it is not disabled. Dec 7 22:35:02 nimrodel CLOCK: CMOS clock differs 1 at 22:35:02 Dec 7 22:45:02 nimrodel CLOCK: CMOS clock differs 1 at 22:45:02 Dec 8 00:20:02 nimrodel CLOCK: CMOS clock differs 1 at 00:20:02 Dec 8 00:25:02 nimrodel CLOCK: CMOS clock differs 1 at 00:25:02 Dec 8 00:30:02 nimrodel CLOCK: CMOS clock differs 1 at 00:30:02 Dec 8 00:35:02 nimrodel CLOCK: CMOS clock differs 1 at 00:35:02 Dec 8 00:45:02 nimrodel CLOCK: CMOS clock differs 1 at 00:45:02 Dec 8 00:55:02 nimrodel CLOCK: CMOS clock differs 1 at 00:55:02 Dec 8 01:05:02 nimrodel CLOCK: CMOS clock differs 1 at 01:05:02 (ie, right now the diff is 0) And, for those that are curious, these are the drift values, logged every five minutes: Dec 7 16:25:02 -40.550 Dec 7 16:30:02 -40.550 Dec 7 16:35:02 -40.550 Dec 7 16:40:02 -40.550 Dec 7 16:45:02 -40.550 Dec 7 16:50:02 -40.550 Dec 7 16:55:02 -40.550 Dec 7 17:00:02 -40.550 Dec 7 17:05:02 -40.550 Dec 7 17:10:02 -40.550 Dec 7 17:15:02 -53.899 Dec 7 17:20:02 -53.899 Dec 7 17:25:02 -53.899 Dec 7 17:30:02 -53.899 Dec 7 17:35:02 -53.899 Dec 7 17:40:02 -53.899 Dec 7 17:45:02 -53.899 Dec 7 17:50:02 -53.899 Dec 7 17:55:02 -53.899 Dec 7 18:00:02 -53.899 Dec 7 18:05:02 -53.899 Dec 7 18:10:02 -53.899 Dec 7 18:15:02 -53.899 Dec 7 18:20:02 -62.444 Dec 7 18:25:02 -62.444 Dec 7 18:30:03 -62.444 Dec 7 18:35:02 -62.444 Dec 7 18:40:02 -62.444 Dec 7 18:45:02 -62.444 Dec 7 18:50:02 -62.444 Dec 7 18:55:02 -62.444 Dec 7 19:00:02 -62.444 Dec 7 19:05:02 -62.444 Dec 7 19:10:02 -62.444 Dec 7 19:15:02 -62.444 Dec 7 19:20:02 -70.013 Dec 7 19:25:02 -70.013 Dec 7 19:30:02 -70.013 Dec 7 19:35:02 -70.013 Dec 7 19:40:02 -70.013 Dec 7 19:55:02 -70.013 Dec 7 20:00:02 -70.013 Dec 7 20:05:02 -70.013 Dec 7 20:10:02 -70.013 Dec 7 20:15:02 -70.013 Dec 7 20:20:02 -70.013 Dec 7 20:25:02 -75.492 Dec 7 20:30:02 -75.492 Dec 7 20:35:02 -75.492 Dec 7 20:40:02 -75.492 Dec 7 20:45:02 -75.492 Dec 7 20:50:02 -75.492 Dec 7 20:55:02 -75.492 Dec 7 21:00:02 -75.492 Dec 7 21:05:02 -75.492 Dec 7 21:10:02 -75.492 Dec 7 21:15:02 -75.492 Dec 7 21:20:02 -75.492 Dec 7 21:25:02 -75.492 Dec 7 21:30:02 -79.780 Dec 7 21:35:02 -79.780 Dec 7 21:40:02 -79.780 Dec 7 21:45:02 -79.780 Dec 7 21:50:02 -79.780 Dec 7 21:55:02 -79.780 Dec 7 22:00:02 -79.780 Dec 7 22:05:02 -79.780 Dec 7 22:10:02 -79.780 Dec 7 22:15:02 -79.780 Dec 7 22:20:02 -79.780 Dec 7 22:25:02 -79.780 -- No network Dec 7 22:30:02 -82.365 Dec 7 22:35:02 -82.365 Dec 7 22:40:02 -82.365 Dec 7 22:45:02 -82.365 Dec 7 22:50:02 -82.365 Dec 7 22:55:02 -82.365 Dec 7 23:00:02 -82.365 Dec 7 23:05:02 -82.365 Dec 7 23:10:02 -82.365 Dec 7 23:15:02 -82.365 Dec 7 23:20:02 -82.365 Dec 7 23:25:02 -82.365 Dec 7 23:30:02 -82.365 Dec 7 23:35:02 -82.365
Re: [opensuse] ntp can not manage to put the clock in sync.
On Thursday 06 December 2007 08:39:31 pm Carlos E. R. wrote: 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. So, what happened Carlos. Any change? -- Regards, Rajko -- 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.
-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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse] ntp can not manage to put the clock in sync.
-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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse] ntp can not manage to put the clock in sync.
-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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse] ntp can not manage to put the clock in sync.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Carlos E. R. [EMAIL PROTECTED] [12-07-07 19:06]: 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: mine is set to jiffy, but i'm still on 10.1 x86_64 - -- Patrick Shanahan Plainfield, Indiana, USAHOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535@ http://counter.li.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFHWeboClSjbQz1U5oRAj/7AJ9dEmHFMv6WJmgTBEyMiaLdNV1VaQCgjwcA kMcFYlRXHTifZoqgb4g9cpA= =kt2J -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.
-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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse] ntp can not manage to put the clock in sync.
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse] ntp can not manage to put the clock in sync.
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? 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: [pruned] 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 I use ntpdate -u 203.12.160.2, as an example. Ciao. -- Past experience, if not forgotten, is a guide for the future. -- 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.
-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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse] ntp can not manage to put the clock in sync.
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 -- 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.
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse] ntp can not manage to put the clock in sync.
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. -- Bob Smits [EMAIL PROTECTED] A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? -- 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.
Carlos E. R. wrote: -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. Your logs says that when NTP looses the network connection, it is syncing to the CMOS clock. From another one of your posts: + + + 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. + + -- 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.
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse] ntp can not manage to put the clock in sync.
Carlos E. R. wrote: 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. 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. Joe -- 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.
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. -- 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.
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 Snip I just run a home desktop system, but thought I should add that I have noticed a similar problem in 10.1. The clock has run slow ever since install, about two years ago. I don't yet have the knowledge to offer more info, but am following this discussion closely in hope of learning more. -ED- -- 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.
-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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse] ntp can not manage to put the clock in sync.
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). 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. But it's only after the system is up and running and, one hopes, an NTP server is contacted that the system's mediocre hardware timebase is corrected by a high-precision, high-accuracy time source (and protocol, which NTP definitely is). 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. ... -- Cheers, Carlos E. R. Randall Schulz -- 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.
-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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse] ntp can not manage to put the clock in sync.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The Thursday 2007-12-06 at 14:43 -, 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse] ntp can not manage to put the clock in sync.
-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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse] ntp can not manage to put the clock in sync.
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse] ntp can not manage to put the clock in sync.
On Thursday 06 December 2007 17:38, Carlos E. R. wrote: 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. ... ... at all ...? I don't think this is really true, is it? When the system starts up, ... 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. Then you have the luck of getting a pretty good crystal. That's just a matter of luck. One second per day is 0.116 or 0.00116% error. 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! Clearly this represents a gross hardware failure or a similarly extreme software problem. You might want to try to quantify the error to a few decimal places. I had an early instance of the very first Macintosh, and it had a similarly excessive clock drift problem. I don't remember the details now (it was twenty-some years ago) but I realized that the problem was something like every 2^8 seconds it added a second. Since 2^8 seconds is only 4 minutes 16 seconds, this was a very blatant error! But the real point was that it was clear that a single-bit glitch on a predictable interval was responsible for the empirical error I witnessed. -- Cheers, Carlos E. R. Randall Schulz -- 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.
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 [EMAIL PROTECTED] -- 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.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The Thursday 2007-12-06 at 12:28 -0500, Aaron Kulkis wrote: Changing the CMOS battery would be simpler, and costs less than lunch in a restaurant. The system time is not affected by the CMOS battery at all. - -- Cheers, Carlos E. R. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHWJzNtTMYHG2NR9URAvanAKCUO9gboc0UPS6ifQ5B2gB0kMfk6wCfXn3R WYRXkQf8sFy12K+7IfcZuuU= =bV+h -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.
On Thursday 06 December 2007 07:22:32 pm Carlos E. R. wrote: 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 Have you disabled: [*] Tickless System (Dynamic Ticks) this is new in 10.3 comparing to 10.2. -- Regards, Rajko -- 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.
-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- -- 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.
-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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse] ntp can not manage to put the clock in sync.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The Thursday 2007-12-06 at 17:47 -0800, Joseph Loo wrote: I believe that the CMOS clock is updated when you shutdown. There is a specific routine that synchronize the cmos clock. Yes, that is correct. Have a look here - it is old, but mostly valid: http://susefaq.sourceforge.net/howto/time.html 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 Yes, I use the pool of servers, but not exactly those. I try to use European servers that should be closer. 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. I know. But if they are on the pool, it's ok to use them. - -- Cheers, Carlos E. R. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHWKy1tTMYHG2NR9URAmwxAJ0R84khTvoRHAGhxh5CW5UQHdaIDQCglBKt xstnPklnIKQNEcdKLWiGcpQ= =Ws4R -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.
-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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse] ntp can not manage to put the clock in sync.
-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.116 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse] ntp can not manage to put the clock in sync.
-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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse] ntp can not manage to put the clock in sync.
On Fri, 2007-12-07 at 02:38 +0100, Carlos E. R. wrote: -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- It does sound like your driftfile is messed up. -- Joseph Loo [EMAIL PROTECTED] -- 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.
Carlos E. R. wrote: -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.116 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. 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? Ciao. -- Past experience, if not forgotten, is a guide for the future. -- 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.
Carlos E. R. wrote: 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. 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 -- David C. Rankin, J.D., P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com -- 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.
On Fri, 2007-12-07 at 02:16 +0100, Carlos E. R. wrote: -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. Well proven, Latest patches were applied? My college builded last week a 10.3 system with truly very strange behaviour. We found out that the system clock -- was standing stil --. Havoc! ntp would not work (drift to large), could not update, Only after a manually ntpdate he could repair the system. btw, you know that you have to be carefull with xen time... (don't know if this relevant in your case) hw -- 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.
On Freitag 07 Dezember 2007, Carlos E. R. wrote: [...] 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 :-( Sorry for intervening, i haven't read the whole thread! Do you run Linux in a VM infrastructure like VMware? Regards! Frank -- 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.
On Wed, 2007-12-05 at 22:48 +0100, Theo v. Werkhoven wrote: Tue, 04 Dec 2007, by [EMAIL PROTECTED]: 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. Certain OS made in Seattle had (have? I don't know, hopefully not) a problem with missing clock interrupts, as billie describes. It's not a question of hardware reliability but of software correctness. Cheers, Dave -- 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.
Tue, 04 Dec 2007, by [EMAIL PROTECTED]: 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. WerkhovenRegistered Linux user# 99872 http://counter.li.org ICBM 52 13 26N , 4 29 47E. + ICQ: 277217131 SUSE 10.3 + Jabber: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse] ntp can not manage to put the clock in sync.
Tue, 04 Dec 2007, by [EMAIL PROTECTED]: 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.21, synch distance 0.013900 Mainboard is an old(ish) Asus A7V600 Theo -- Theo v. WerkhovenRegistered Linux user# 99872 http://counter.li.org ICBM 52 13 26N , 4 29 47E. + ICQ: 277217131 SUSE 10.3 + Jabber: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse] ntp can not manage to put the clock in sync.
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. I don't have it in this installation, but I did it 2 times before to give enough ticks to my obsolete scanner, and all that happened is scanner worked fine without need for high priority (niceness) for the driver. -- Regards, Rajko -- 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.
-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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse] ntp can not manage to put the clock in sync.
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse] ntp can not manage to put the clock in sync.
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[opensuse] ntp can not manage to put the clock in sync.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I'm investigating a problem I'm having with the clock getting very slow, and I have traced the problem to something new in opensuse 10.3. I wonder if any body has the same problem - the check is simple, run this grep command: grep time reset /var/log/ntp | less I find: (opensuse 10.2) 23 Feb 02:05:45 ntpd[4617]: time reset +0.624127 s 23 Feb 14:28:52 ntpd[4617]: time reset +0.487172 s 23 Feb 14:49:00 ntpd[4617]: time reset +0.138037 s 23 Feb 22:26:08 ntpd[4617]: time reset +0.243491 s 24 Feb 11:54:28 ntpd[4674]: time reset +0.495337 s 25 Feb 11:56:40 ntpd[4674]: time reset +0.380593 s 27 Feb 11:39:30 ntpd[4674]: time reset -0.169734 s 1 Mar 11:24:29 ntpd[4676]: time reset +0.574879 s ... 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 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 5 Nov 14:00:25 ntpd[5163]: time reset +318.950445 s 5 Nov 14:50:51 ntpd[5163]: time reset +0.164107 s 5 Nov 19:55:07 ntpd[5163]: time reset +27.860709 s 5 Nov 23:15:44 ntpd[5163]: time reset +436.175607 s You see that the time resets are small when I had suse 10.2, but with 10.3 they jumped in size up to almost 400 seconds. If the error is larger than 1000 seconds, ntp 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. The delay was half an hour! I restarted the daemon when I noticed. Nov 27 17:13:53 nimrodel ntpdate[18860]: step time server 212.13 offset 1677.937114 sec Other events - here I have removed these two lines from the config, as a test: server 127.127.1.0 # local clock (LCL) fudge 127.127.1.0 stratum 10 # LCL is unsynchronized 3 Dec 19:11:29 ntpd[29084]: synchronized to 88.191.43.2, stratum 2 3 Dec 19:12:44 ntpd[29084]: synchronized to 213.96.197.96, stratum 2 3 Dec 19:13:34 ntpd[29084]: no servers reachable 3 Dec 19:20:14 ntpd[29084]: synchronized to 88.191.43.2, stratum 2 3 Dec 19:21:32 ntpd[29084]: synchronized to 213.96.197.96, stratum 2 3 Dec 19:22:36 ntpd[29084]: synchronized to 88.191.43.2, stratum 2 3 Dec 19:31:42 ntpd[29084]: time reset +309.343782 s 300 seconds of error after being disconeected from servers for just 20 minutes! Before an hour passes, it happens again: 3 Dec 19:31:42 ntpd[29084]: system event 'event_clock_reset' (0x05) status 'sync_alarm, sync_unspec, 15 events, event_peer/strat_chg' (0xc0f4) 3 Dec 19:31:42 ntpd[29084]: system event 'event_peer/strat_chg' (0x04) status 'sync_alarm, sync_unspec, 15 events, event_clock_reset' (0xc0f5) 3 Dec 19:31:44 ntpd[29084]: peer 213.96.200.126 event 'event_reach' (0x84) status 'unreach, conf, 2 events, event_reach' (0x8024) 3 Dec 19:31:45 ntpd[29084]: peer 81.19.16.225 event 'event_reach' (0x84) status 'unreach, conf, 2 events, event_reach' (0x8024) 3 Dec 19:32:23 ntpd[29084]: peer 88.191.43.2 event 'event_reach' (0x84) status 'unreach, conf, 2 events, event_reach' (0x8024) 3 Dec 19:32:24 ntpd[29084]: peer 195.92.137.112 event 'event_reach' (0x84) status 'unreach, conf, 2 events, event_reach' (0x8024) 3 Dec 19:32:30 ntpd[29084]: peer 193.138.215.60 event 'event_reach' (0x84) status 'unreach, conf, 2 events, event_reach' (0x8024) 3 Dec 19:32:34 ntpd[29084]: peer 213.96.197.96 event 'event_reach' (0x84) status 'unreach, conf, 2 events, event_reach' (0x8024) 3 Dec 19:36:40 ntpd[29084]: synchronized to 88.191.43.2, stratum 2 3 Dec 19:36:40 ntpd[29084]: system event 'event_sync_chg' (0x03) status 'leap_none, sync_ntp, 15 events, event_peer/strat_chg' (0x6f4) 3 Dec 19:36:40 ntpd[29084]: system event 'event_peer/strat_chg' (0x04) status 'leap_none, sync_ntp, 15 events, event_sync_chg' (0x6f3) 3 Dec 20:01:13 ntpd[29084]: offset 0.002029 sec freq 79.654 ppm error 0.002737 poll 6 3 Dec 20:15:34 ntpd[29084]: synchronized to 213.96.197.96, stratum 2 3 Dec 20:28:15 ntpd[29084]: no servers reachable 3 Dec 20:30:41 ntpd[29084]: synchronized to 88.191.43.2, stratum 2 3 Dec 20:34:30 ntpd[29084]: time reset +220.290279 s 220 delay.
Re: [opensuse] ntp can not manage to put the clock in sync.
Carlos E. R. wrote: I'm investigating a problem I'm having with the clock getting very slow, and I have traced the problem to something new in opensuse 10.3. I believe there must be a kernel problem or ntp problem in 10.3. Excellent work, Carlos, someone on PCLinux told me of a similar problem and i first did not believe him, but now i do. Kind regards Philippe -- 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.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The Wednesday 2007-12-05 at 01:05 +0100, Philippe Landau wrote: Carlos E. R. wrote: I'm investigating a problem I'm having with the clock getting very slow, and I have traced the problem to something new in opensuse 10.3. I believe there must be a kernel problem or ntp problem in 10.3. Excellent work, Carlos, someone on PCLinux told me of a similar problem and i first did not believe him, but now i do. Then, please point him to this bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=344356 so that he can see if we have the same problem, and if so, he could add his notes there. This other bugzilla: https://support.ntp.org/bugs/show_bug.cgi?id=780 is somewhat related. Interesting to know that NTP developers do not want to hear anything about linux kernel! - -- Cheers, Carlos E. R. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHVfD0tTMYHG2NR9URAj2CAJsEManzlqCMEXAFl379P5TSp1Ak2ACfWXDn o0zUJAOozhMpUH6qJPX4qKE= =NuQu -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.
Carlos E. R. wrote: Hi, I'm investigating a problem I'm having with the clock getting very slow, and I have traced the problem to something new in opensuse 10.3. I wonder if any body has the same problem - the check is simple, run this grep command: 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. -- Use OpenOffice.org http://www.openoffice.org -- 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.
On Tue, 2007-12-04 at 20:24 -0500, James Knott wrote: Carlos E. R. wrote: Hi, I'm investigating a problem I'm having with the clock getting very slow, and I have traced the problem to something new in opensuse 10.3. I wonder if any body has the same problem - the check is simple, run this grep command: 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. -- Use OpenOffice.org http://www.openoffice.org 21 Oct 22:33:59 ntpd[17037]: time reset -0.175443 s 23 Oct 18:07:42 ntpd[3637]: time reset -0.151811 s 1 Nov 19:35:19 ntpd[4209]: time reset +0.614816 s 9 Nov 20:36:56 ntpd[4282]: time reset -0.211439 s 10 Nov 02:13:43 ntpd[3925]: time reset +0.212136 s 10 Nov 02:46:05 ntpd[3925]: time reset -0.296528 s 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 -- Joseph Loo [EMAIL PROTECTED] -- 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.
-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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse] ntp can not manage to put the clock in sync.
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. -- 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.
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 since I installed 10.3. The system is a Dell Inspiron 8100. I know it is ancient, but it still works. There are a few messages were it had a problem contacting the time server, but it always recovered. Bill Anderson WW7BA -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
