My potentially groundless assumption is that because the motherboard is new, that the battery is good. My only option would be to replace as I couldn't test.
The problem machine kernel is: jupiter:/home/roger # uname -r 2.6.18.8-0.5-default This machine I am replying with, also 64bit SuSE, shows 2.6.18.2-34-default. In Yast Software Management for both, it reports that the kernel-default installed version and available version are the same - which doesn't make much sense! And little confusing. So as a first step, a kernel update would seem to be in order, but how, given Yast doesn't report a more recent version? And what is considered "recent"? And why is this one (these ones) so out of date? Any answers to these very welcome while I attempt further investigations... Christopher Sawtell wrote: > This is a well known problem. > A Google search "clock drift linux nvidia" yields much info. > Have you checked the state of the battery which powers the crystal > clock and CMOS? > btw what kernel version are you running? > > On 9/17/07, Roger Searle <[EMAIL PROTECTED]> wrote: > >> I should have said, 10.2.1.1 is the IPCop box. Also, there had been one >> or more ntp restarts on the 11th and 12th. Strange that there are no >> log entries over the weekend, uptime is 18 days. >> >> Roger Searle wrote: >> >>> Hi, I have a SuSE 64bit install on an Asus M2N motherboard, and I recall >>> others having (unresolvable?) time drift issues with a 64bit >>> installation. Perhaps the common factor was nvidia chipsets, but I could >>> be making that up. It is losing something like an hour a day. >>> >>> ntpd is running and getting time from an IPCop box. Yet the time >>> reported by that box according to the "date" command continues to >>> drift. Running "service ntp restart" brings it back in line, so a >>> solution to keep the box's time in sync might be to put this in a cron >>> job and run every 15 minutes. Interestingly after the ntp restart at >>> 9am this morning (had lost around 3 hours over the weekend), the time is >>> accurate within a second 3 hours later, which doesn't help me understand >>> what's happening. >>> >>> I could be missing something obvious, so would be interested in any >>> suggestions from anyone about resolving this? Here is the last few days >>> from /var/log/ntp: >>> >>> 11 Sep 09:04:10 ntpd[9766]: synchronized to 10.2.1.1, stratum 11 >>> 11 Sep 09:04:10 ntpd[9766]: kernel time sync disabled 0001 >>> 11 Sep 09:38:25 ntpd[9766]: no servers reachable >>> 11 Sep 09:43:49 ntpd[9766]: synchronized to 10.2.1.1, stratum 11 >>> 11 Sep 09:48:11 ntpd[9766]: time reset +6.475822 s >>> 11 Sep 09:51:37 ntpd[9766]: synchronized to 10.2.1.1, stratum 11 >>> 11 Sep 11:20:47 ntpd[9766]: no servers reachable >>> 11 Sep 11:55:08 ntpd[9766]: synchronized to 10.2.1.1, stratum 11 >>> 11 Sep 12:00:29 ntpd[9766]: time reset +64.498256 s >>> 11 Sep 12:04:07 ntpd[9766]: synchronized to 10.2.1.1, stratum 11 >>> 11 Sep 12:48:27 ntpd[9766]: time reset -0.132544 s >>> 11 Sep 12:52:39 ntpd[9766]: synchronized to 10.2.1.1, stratum 11 >>> 11 Sep 16:23:28 ntpd[9766]: ntpd exiting on signal 15 >>> 11 Sep 16:27:46 ntpd[11380]: synchronized to 10.2.1.1, stratum 11 >>> 11 Sep 16:27:46 ntpd[11380]: time reset -0.224694 s >>> 11 Sep 16:27:46 ntpd[11380]: kernel time sync enabled 0001 >>> 11 Sep 16:32:10 ntpd[11380]: synchronized to 10.2.1.1, stratum 11 >>> 11 Sep 17:26:48 ntpd[11380]: no servers reachable >>> 11 Sep 17:31:08 ntpd[11380]: synchronized to 10.2.1.1, stratum 11 >>> 11 Sep 17:36:37 ntpd[11380]: time reset +73.901648 s >>> 11 Sep 17:40:38 ntpd[11380]: synchronized to 10.2.1.1, stratum 11 >>> 11 Sep 19:34:09 ntpd[11380]: no servers reachable >>> 11 Sep 19:59:49 ntpd[11380]: synchronized to 10.2.1.1, stratum 11 >>> 11 Sep 20:17:02 ntpd[11380]: time reset +7.640369 s >>> 11 Sep 20:20:29 ntpd[11380]: synchronized to 10.2.1.1, stratum 11 >>> 11 Sep 21:03:23 ntpd[11380]: time reset +0.165117 s >>> 11 Sep 21:07:21 ntpd[11380]: synchronized to 10.2.1.1, stratum 11 >>> 12 Sep 01:29:42 ntpd[11380]: time reset +648.102905 s >>> 12 Sep 01:33:29 ntpd[11380]: synchronized to 10.2.1.1, stratum 11 >>> 12 Sep 02:19:46 ntpd[11380]: no servers reachable >>> 12 Sep 02:36:56 ntpd[11380]: synchronized to 10.2.1.1, stratum 11 >>> 12 Sep 02:36:56 ntpd[11380]: time correction of 1156 seconds exceeds >>> sanity limit (1000); set clock manually to the correct UTC time. >>> 14 Sep 17:10:43 ntpd[31392]: synchronized to 10.2.1.1, stratum 11 >>> 14 Sep 17:10:43 ntpd[31392]: kernel time sync disabled 0001 >>> 14 Sep 18:42:00 ntpd[31392]: no servers reachable >>> 14 Sep 18:52:38 ntpd[31392]: synchronized to 10.2.1.1, stratum 11 >>> 14 Sep 19:10:17 ntpd[31392]: time reset +28.615506 s >>> 14 Sep 19:13:52 ntpd[31392]: synchronized to 10.2.1.1, stratum 11 >>> 14 Sep 21:18:07 ntpd[31392]: time reset -0.147810 s >>> 14 Sep 21:21:39 ntpd[31392]: synchronized to 10.2.1.1, stratum 11 >>> 14 Sep 23:48:07 ntpd[31392]: no servers reachable >>> 14 Sep 23:56:39 ntpd[31392]: synchronized to 10.2.1.1, stratum 11 >>> 14 Sep 23:56:39 ntpd[31392]: time correction of 1234 seconds exceeds >>> sanity limit (1000); set clock manually to the correct UTC time. >>> 17 Sep 09:00:43 ntpd[7407]: synchronized to 10.2.1.1, stratum 11 >>> 17 Sep 09:00:43 ntpd[7407]: kernel time sync disabled 0001 >>> 17 Sep 11:26:34 ntpd[7407]: no servers reachable >>> >>> Cheers, >>> Roger >>> >>> >>> > > >
