1 |
First add the line "tinker panic 0" to the top of ntp.conf (for ntpd, |
2 |
not openntp) This allows it to step when outside normal parameters. |
3 |
Otherwise it will register the time difference but wont try and correct |
4 |
it. If it is drifting faster than the allowable correction rate, it |
5 |
will slowly move to the threshold where ntp will stop correcting. |
6 |
|
7 |
Second, some combinations of hardware (dell for me :( , kernels and |
8 |
applets will cause this. They "pause" the system when they |
9 |
access /proc/something. The one that did it for me was the gnome batt |
10 |
stat applet (which works ok these days). There's also some reports of |
11 |
KDE applets doing the same thing. If possible stop X and all X apps and |
12 |
monitor to confirm this is the area where the cause lies. Start by |
13 |
removing any applets that might be causing the problem. |
14 |
|
15 |
It sometimes happens that various config files and states contribute to |
16 |
the problem as when the clock is drifting so fast they set wild values |
17 |
when trying to correct. Boot to level 1 (simplifies things) so ntp is |
18 |
not running, remove /etc/adjtime and /etc/ntp.drift then set the clock |
19 |
using hwclock. Reboot and see how it goes. Never had much luck trying |
20 |
to sort it out when the system was fully up. |
21 |
|
22 |
BillK |
23 |
|
24 |
On Wed, 2005-08-31 at 17:13 -0500, Matt Garman wrote: |
25 |
> My system clock is running extremely fast... so fast that even |
26 |
> openntpd (apparently) can't catch up! |
27 |
> |
28 |
> I tried (oh how I tried) to get the "regular" ntp package to work. |
29 |
> I could correct my clock using ntpdate, but I could never get ntpd |
30 |
> to sync with any servers (see notes (*) below). |
31 |
> |
32 |
> So I got fed up with trying to get it to work, and thought I'd have |
33 |
> better luck with openntpd (which is much simpler). |
34 |
> |
35 |
> As far as I can tell, openntpd *is* working, as I have many lines in my |
36 |
> syslog that look like this: |
37 |
> |
38 |
> Aug 31 17:00:36 [ntpd] adjusting local clock by -344.003180s |
39 |
> |
40 |
> However, the clock is still drifting---not as fast as it does with no |
41 |
> ntp daemon running, but noticeably (it's gained about 5 minutes in less |
42 |
> than 24 hours). Note that without any ntp daemon running, my clock will |
43 |
> gain about 10 minutes per hour! |
44 |
> |
45 |
> I have a hunch that whatever prevented the "regular" ntpd from syncing |
46 |
> is preventing openntpd from properly keeping the clock in sync. |
47 |
> |
48 |
> So, my questions are: (1) what would cause my clock to run so fast? And |
49 |
> (2) why can't any ntp daemon keep correct time? |
50 |
> |
51 |
> Thanks, |
52 |
> Matt |
53 |
> |
54 |
> |
55 |
> |
56 |
> (*) If anyone is interested in the plight I had with ntp, here is some |
57 |
> info: |
58 |
> |
59 |
> This is what my /etc/ntp.conf looked like: |
60 |
> |
61 |
> restrict 127.0.0.1 nomodify |
62 |
> server pool.ntp.org prefer |
63 |
> server 0.pool.ntp.org |
64 |
> server 1.pool.ntp.org |
65 |
> server 2.pool.ntp.org |
66 |
> server 127.127.1.1 |
67 |
> fudge 127.127.1.1 stratum 10 |
68 |
> driftfile /var/lib/ntp/ntp.drift |
69 |
> logfile /var/log/ntpd.log |
70 |
> |
71 |
> After starting ntpd, and waiting a while, ntpq results looked like |
72 |
> this: |
73 |
> |
74 |
> ntpq> pe |
75 |
> |
76 |
> remote refid st t when poll reach delay offset jitter |
77 |
> ============================================================================== |
78 |
> frigg.interstro 138.195.130.71 3 u 21 128 377 124.592 -3950.7 1260.34 |
79 |
> cteha.ulp.co.il 192.114.62.249 3 u 26 128 377 201.236 -4670.9 1715.95 |
80 |
> Time4.Stupi.SE .PPS. 1 u 79 128 377 129.134 -1668.9 1996.01 |
81 |
> Time1.Stupi.SE 193.10.7.246 2 u 21 128 377 128.697 -3962.7 1253.70 |
82 |
> *LOCAL(1) LOCAL(1) 10 l 13 64 377 0.000 0.000 0.001 |
83 |
> |
84 |
> ntpq> assoc |
85 |
> |
86 |
> ind assID status conf reach auth condition last_event cnt |
87 |
> =========================================================== |
88 |
> 1 57708 9014 yes yes none reject reachable 1 |
89 |
> 2 57709 9014 yes yes none reject reachable 1 |
90 |
> 3 57710 9014 yes yes none reject reachable 1 |
91 |
> 4 57711 9014 yes yes none reject reachable 1 |
92 |
> 5 57712 9614 yes yes none sys.peer reachable 1 |
93 |
> |
94 |
> |
95 |
> -- |
96 |
> Matt Garman |
97 |
> email at: http://raw-sewage.net/index.php?file=email |
98 |
-- |
99 |
William Kenworthy <billk@×××××××××.au> |
100 |
Home! |
101 |
-- |
102 |
gentoo-user@g.o mailing list |