First add the line "tinker panic 0" to the top of ntp.conf (for ntpd, not openntp) This allows it to step when outside normal parameters. Otherwise it will register the time difference but wont try and correct it. If it is drifting faster than the allowable correction rate, it will slowly move to the threshold where ntp will stop correcting.
Second, some combinations of hardware (dell for me :( , kernels and applets will cause this. They "pause" the system when they access /proc/something. The one that did it for me was the gnome batt stat applet (which works ok these days). There's also some reports of KDE applets doing the same thing. If possible stop X and all X apps and monitor to confirm this is the area where the cause lies. Start by removing any applets that might be causing the problem. It sometimes happens that various config files and states contribute to the problem as when the clock is drifting so fast they set wild values when trying to correct. Boot to level 1 (simplifies things) so ntp is not running, remove /etc/adjtime and /etc/ntp.drift then set the clock using hwclock. Reboot and see how it goes. Never had much luck trying to sort it out when the system was fully up. BillK On Wed, 2005-08-31 at 17:13 -0500, Matt Garman wrote: > My system clock is running extremely fast... so fast that even > openntpd (apparently) can't catch up! > > I tried (oh how I tried) to get the "regular" ntp package to work. > I could correct my clock using ntpdate, but I could never get ntpd > to sync with any servers (see notes (*) below). > > So I got fed up with trying to get it to work, and thought I'd have > better luck with openntpd (which is much simpler). > > As far as I can tell, openntpd *is* working, as I have many lines in my > syslog that look like this: > > Aug 31 17:00:36 [ntpd] adjusting local clock by -344.003180s > > However, the clock is still drifting---not as fast as it does with no > ntp daemon running, but noticeably (it's gained about 5 minutes in less > than 24 hours). Note that without any ntp daemon running, my clock will > gain about 10 minutes per hour! > > I have a hunch that whatever prevented the "regular" ntpd from syncing > is preventing openntpd from properly keeping the clock in sync. > > So, my questions are: (1) what would cause my clock to run so fast? And > (2) why can't any ntp daemon keep correct time? > > Thanks, > Matt > > > > (*) If anyone is interested in the plight I had with ntp, here is some > info: > > This is what my /etc/ntp.conf looked like: > > restrict 127.0.0.1 nomodify > server pool.ntp.org prefer > server 0.pool.ntp.org > server 1.pool.ntp.org > server 2.pool.ntp.org > server 127.127.1.1 > fudge 127.127.1.1 stratum 10 > driftfile /var/lib/ntp/ntp.drift > logfile /var/log/ntpd.log > > After starting ntpd, and waiting a while, ntpq results looked like > this: > > ntpq> pe > > remote refid st t when poll reach delay offset jitter > ============================================================================== > frigg.interstro 138.195.130.71 3 u 21 128 377 124.592 -3950.7 1260.34 > cteha.ulp.co.il 192.114.62.249 3 u 26 128 377 201.236 -4670.9 1715.95 > Time4.Stupi.SE .PPS. 1 u 79 128 377 129.134 -1668.9 1996.01 > Time1.Stupi.SE 193.10.7.246 2 u 21 128 377 128.697 -3962.7 1253.70 > *LOCAL(1) LOCAL(1) 10 l 13 64 377 0.000 0.000 0.001 > > ntpq> assoc > > ind assID status conf reach auth condition last_event cnt > =========================================================== > 1 57708 9014 yes yes none reject reachable 1 > 2 57709 9014 yes yes none reject reachable 1 > 3 57710 9014 yes yes none reject reachable 1 > 4 57711 9014 yes yes none reject reachable 1 > 5 57712 9614 yes yes none sys.peer reachable 1 > > > -- > Matt Garman > email at: http://raw-sewage.net/index.php?file=email -- William Kenworthy <[EMAIL PROTECTED]> Home! -- gentoo-user@gentoo.org mailing list
