ntpd still not working
in [Slackware]
|
Prev: ntpd question
Next: slack 13 OpenOffice
From: root on 3 Nov 2009 02:07 Henrik Carlqvist <Henrik.Carlqvist(a)deadspam.com> wrote: > Could you please post your entire ntp.conf again? Did you remove or > comment out the multicast and broadcast lines? Those lines should probably > be removed or commented out. > > You could try the following file: > > -8<--------------------- > server 127.127.1.0 # local clock > fudge 127.127.1.0 stratum 10 > driftfile /etc/ntp/drift > pidfile /var/run/ntpd.pid > server 0.pool.ntp.org > server 1.pool.ntp.org > server 2.pool.ntp.org > server 3.pool.ntp.org > server tick.ucla.edu > -8<--------------------- > > regards Henrik Your file was identical to my last attempt, except that I had omitted the fudge line. I just restarted the daemon with your conf file. As was suggested earlier I added a log file to the invocation of ntpd. Here is the resulting file: 2 Nov 22:55:48 ntpd[4766]: logging to file /tmp/ntp.log 2 Nov 22:55:48 ntpd[4766]: precision = 4000.000 usec 2 Nov 22:55:48 ntpd[4766]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16 2 Nov 22:55:48 ntpd[4766]: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled 2 Nov 22:55:48 ntpd[4766]: Listening on interface #1 lo, 127.0.0.1#123 Enabled 2 Nov 22:55:48 ntpd[4766]: Listening on interface #2 eth0, 10.0.0.3#123 Enabled 2 Nov 22:55:48 ntpd[4766]: kernel time sync status 0040 2 Nov 22:55:48 ntpd[4766]: frequency initialized 1.211 PPM from /etc/ntp/drift 2 Nov 22:59:01 ntpd[4766]: synchronized to LOCAL(0), stratum 10 2 Nov 22:59:01 ntpd[4766]: kernel time sync status change 0001 Someone else had line in his log file that said his kernel was synched to one of the servers. I have no such line. Here is the result of ntpq -p: remote refid st t when poll reach delay offset jitter ============================================================================== *LOCAL(0) .LOCL. 10 l 6 64 37 0.000 0.000 3.906 ntp.pbx.org 192.5.41.40 2 u - 64 37 78.773 121166. 1671.51 ns1.your-site.c 10.1.11.62 3 u 64 64 17 82.288 118730. 1317.26 phoenix.netserv 64.113.44.54 2 u - 64 37 72.498 120571. 1180.28 valkyrie.netser 64.113.44.54 2 u 61 64 17 66.549 119336. 868.405 tick.ucla.edu .GPS. 1 u 60 64 17 11.436 119369. 877.524 I was told that the poll entry above should gradually increase to 1024. In fact I have never seen it change from 64. The jitter entry changes. Somewhere along the line my drift entry was changed from 0.000 to 1.211 but I failed to notice when it changed and what the config file was when it changed. I might have had a working ntpd at that instant and walked away from it. Regardless, I have never seen ntpd improve the timekeeping. Thanks for your continued help Henrik.
From: root on 3 Nov 2009 02:09 buck <buck(a)private.mil> wrote: > > Use OpenNTP, not ISC ntpd. You'll be glad you switched. > -- > buck I am running 12.2, what did Patrick choose? Why would I be glad to switch, is the Open version a plug in replacement?
From: Petri Kaukasoina on 3 Nov 2009 04:47 root <NoEMail(a)home.org> wrote: >After over two hours of operation >I had drifted by 84 seconds, which is just the >drift I had always been getting. So, the rate of your clock is about 11700 ppm too fast or too slow. ntpd can fix the rate only if it's less than 500 ppm off if I remember right. Try this: first kill ntpd, then "adjtimex -f 0" to reset the frequency offset. Then give either "tickadj 10117" or "tickadj 9883" depending on whether your clock was 11700 ppm too slow or too fast. (10000 is the default value for tickadj). Don't start ntpd yet. Use the eyeball-and-wristwatch method to check if the clock is better now. Now ntpd should be able to control the clock.
From: Petri Kaukasoina on 3 Nov 2009 04:53 Petri Kaukasoina <kaukasoina802n54jc045(a)sci.fi> wrote: >root <NoEMail(a)home.org> wrote: >>After over two hours of operation >>I had drifted by 84 seconds, which is just the >>drift I had always been getting. > >So, the rate of your clock is about 11700 ppm too fast or too slow. By the way, which clock source are you using? cat /sys/devices/system/clocksource/clocksource0/current_clocksource cat /sys/devices/system/clocksource/clocksource0/available_clocksource For example, if you are not using "acpi_pm" but if it is available, you could try to use it (as root): echo acpi_pm > /sys/devices/system/clocksource/clocksource0/current_clocksource
From: root on 3 Nov 2009 05:44
root <NoEMail(a)home.org> wrote: > > I was told that the poll entry above should gradually increase to > 1024. In fact I have never seen it change from 64. The jitter entry changes. > The system has been running for 3 hours now. ntpq -p yields: remote refid st t when poll reach delay offset jitter ============================================================================== *LOCAL(0) .LOCL. 10 l 60 64 377 0.000 0.000 3.906 perturb.org 69.25.96.13 2 u 1013 1024 377 35.927 86638.8 9604.60 router.w0ss.com 67.128.71.65 3 u 1010 1024 377 88.084 86658.5 9632.20 rikku.vrillusio 64.236.96.53 2 u 42 1024 377 80.385 95739.1 9598.11 li4-205.members 132.239.1.6 2 u 35 1024 377 14.733 86180.4 9626.63 tick.ucla.edu .GPS. 1 u 37 1024 377 11.808 95789.4 9620.79 And all the external polls have risen to 1024. I synched time just before I started ntpd. It has been running 3 hours now and the time has drifted off by 154 seconds: I think it is drifting more than without ntpd. It was suggested that I should set the kernel option for high precision time resolution. I didn't do that. Is it possible that there is some kernel option I should set for ntpd to work? I would have designed ntpd to set the time immediately after invocation (which it doesn't). I would have ntpd poll the servers at some frequency and keep track of the acccumulated error while computing and updating the drift factor. Over time I would expect the drift factor would stabilize and I would decrease the frequency at which I polled the servers. I don't see any of this behavior, the drift factor has remained at 1.211 since it was changed, whenever it was changed. The time is never set correctly after ntpd is started. I shut the machine down every day, it is never up for longer than 15 hours at a time. Does ntpd assume the machine is on 24/7 and that it can take days before the timekeeping corrects itself? |