ntpd still not working
root
isn't working. I thought I was there when
I got what looked like correct entries in the
logfile, but one line was missing:
2 Nov 08:22:24 ntpd[3007]: synchronized to 65.255.217.202, stratum 3
I didn't get synchronized to any server, even
though ntpq -p showed I was in contact with
three servers. After over two hours of operation
I had drifted by 84 seconds, which is just the
drift I had always been getting.
vince
wrote:
>After everyone's help, the damned thing still
>isn't working.
I'm far from an expert, but since nothing has worked to this point,
try removing or commenting out these two lines
server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10
root
Thanks, but I have tried that.
Henrik Carlqvist
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
--
The address in the header is only to prevent spam. My real address is:
hc3(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost
buck
Use OpenNTP, not ISC ntpd. You'll be glad you switched.
--
buck
root
> 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.
root
>
> 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?
Petri Kaukasoina
>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 1170 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 1170 ppm too slow or too fast. 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.
Petri Kaukasoina
>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
Petri Kaukasoina
>root <NoE...@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
root
>
> 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?
root
OK, I have done the adjtimex, and tickadj 10117 (my clock runs slow).
I will repost when the machine has run an hour.
Is the tickadj tick=xxx preserved over reboot. If so,
I will screw around until the timekeeping is good enough.
Thanks.
root
The first gives me jiffies. The second says I can use
jiffies or tsc.
Petri Kaukasoina
>OK, I have done the adjtimex, and tickadj 10117 (my clock runs slow).
>I will repost when the machine has run an hour.
>
>Is the tickadj tick=xxx preserved over reboot. If so,
>I will screw around until the timekeeping is good enough.
It's reset in reboot. If the line helps, you could put it for example in
/etc/rc.d/rc.local or maybe in /etc/rc.d/rc.M just before the line starting
/etc/rc.d/rc.ntpd. Preferably with the whole path:
/usr/sbin/tickadj 10117
root
>
> OK, I have done the adjtimex, and tickadj 10117 (my clock runs slow).
> I will repost when the machine has run an hour.
>
> Is the tickadj tick=xxx preserved over reboot. If so,
> I will screw around until the timekeeping is good enough.
>
> Thanks.
The adjtimex man page was a gift, thanks. I played around
with various tick values. It turns out you need not run
the system for any longer than 10 minutes with a given
tick value to resolve the "correct" value to within +/- 1
After trying your original value, I found I needed to
correct 10117 to 10094. Finally I had to change that to
10093:
10094 after 10 min -.208 sec
10093 after 10 min .022 sec
It's a very easy process. I put the tick setting in
rc.local, and I also call ntpdate to set the clock
when I power up.
I have restarted ntpd, and will check after running
100 minutes.
Thanks again.
Petri Kaukasoina
>The adjtimex man page was a gift, thanks. I played around
>with various tick values. It turns out you need not run
>the system for any longer than 10 minutes with a given
>tick value to resolve the "correct" value to within +/- 1
>After trying your original value, I found I needed to
>correct 10117 to 10094. Finally I had to change that to
>10093:
>10094 after 10 min -.208 sec
>10093 after 10 min .022 sec
>
Now that you have tuned the tick value so accurately, the error in clock
rate will probable be less than 50 ppm (change of 1 in the tick value
changes the rate by about 100 ppm). You could tinker with it even more if
you didn't use ntpd: for example "ntptime -f -1.234" or "ntptime -f 1.234"
would change the frequency by -1.234 or +1.234 ppm. This is the same value
that ntpd is changing and which ntpd writes in /etc/ntp/drift. Of course,
ntpd can do it better than you because it can compensate against rate
changes caused by temperature changes (both ambient and cpu load related) by
syncing to reference ntp servers.
root
>
> I have restarted ntpd, and will check after running
> 100 minutes.
>
> Thanks again.
>
According to my setting of tick, after 100 minutes the
clock would have been off by 2 sec. Instead it was spot
on. I continued the test, now after 440 minutes the
clock is still perfect. ntpd is working now.
Thanks to everyone.
root
>
> Now that you have tuned the tick value so accurately, the error in clock
> rate will probable be less than 50 ppm (change of 1 in the tick value
> changes the rate by about 100 ppm). You could tinker with it even more if
> you didn't use ntpd: for example "ntptime -f -1.234" or "ntptime -f 1.234"
> would change the frequency by -1.234 or +1.234 ppm. This is the same value
> that ntpd is changing and which ntpd writes in /etc/ntp/drift. Of course,
> ntpd can do it better than you because it can compensate against rate
> changes caused by temperature changes (both ambient and cpu load related) by
> syncing to reference ntp servers.
After something like 450 minutes of operation the drift value
is 23.365. My clock is way more accurate than I need now.
Thanks for your help.
After this experience I offered to fix the clock on my
wife's machine. Her clock is accurate to a couple of
seconds/week so she doesn't need my help.
Henrik Carlqvist
> I would have designed ntpd to set the time immediately after invocation
> (which it doesn't).
On my machines I call ntpdate just before starting ntpd. That gives me the
behavior that you want.
Nice to see that you were able to get ntpd working with tickadj.
Theodore Heise
Aha! Good catch, thanks for pointing it out!
--
Theodore (Ted) Heise <th...@heise.nu> Bloomington, IN, USA
Theodore Heise
root <NoE...@home.org> wrote:
> root <NoE...@home.org> wrote:
>>
>> I have restarted ntpd, and will check after running 100
>> minutes.
> According to my setting of tick, after 100 minutes the clock
> would have been off by 2 sec. Instead it was spot on. I
> continued the test, now after 440 minutes the clock is still
> perfect. ntpd is working now.
>
> Thanks to everyone.
Glad you were able to get it running! Nice persistence on your
part too, I might add.
geep
Hi,
Here's a copy of the script I run from rc.local to start and check ntp.
/etc/rc.d/rc.ntpd is already set executable.
e.g. -rwxr-xr-x 1 root root 561 2008-11-20 22:07 /etc/rc.d/rc.ntpd
Adjust to suit your own favourite timesource.
Cheers,
Peter
#!/bin/bash
#First, stop existing daemon
/etc/rc.d/rc.ntpd stop
#From http://support.ntp.org/bin/view/Support/GettingStarted
#3.2.4. "Manually" set the clock correctly just once
echo "Set the correct time..."
timeserver1="ntp1.npl.co.uk"
timeserver2="ntp2.npl.co.uk"
/usr/sbin/ntpdate -b $timeserver1 $timeserver2
#3.2.6. Keep the clock in sync permanently and continuously.
# (Having already setup /etc/ntp.conf)
/etc/rc.d/rc.ntpd start
#3.2.8. Check your work.
echo "Check time sync peers..."
/usr/sbin/ntpdc -c peers
#Check that ntpd daemon running for continuous time synch
echo "Check that ntpd daemon running for continuous time synch..."
echo -n " ntpd PID: "
/usr/bin/pgrep ntpd
/usr/sbin/ntpq -p
echo -n "Clock frequency drift="
cat /etc/ntp/drift
james
> After everyone's help, the damned thing still
> isn't working.
I had the same problem after updating ntpd on my box that is my
home time server. The solution was finding that the definitions
of some of the options of 'restrict' had changed. Changed to
the new option format and everything started working.
Here's my complete ntp.conf from the affected box (there are even
notes about what changed and where to find the docs):
#
# /etc/ntp.conf
driftfile /etc/ntp.drift
logfile /var/log/ntp.log
pidfile /var/run/ntp.pid
# next 2 lines is how ntpd queries the local clock.
# different addresses for different, specialized time sources
# stratum 15 so that we'll definitely be low on the list
# Hint: as of /usr/doc/ntp-4.2.0/html/notes.html 15 is highest stratum
# 8/17/2006 - we'll, we're syncing to ourselves again. comment this
# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available. The
# default stratum is usually 3, but in this case we elect to use stratum
# 0. Since the server line does not have the prefer keyword, this driver
# is never used for synchronization, unless no other other
# synchronization source is available. In case the local host is
# controlled by some external source, such as an external oscillator or
# another protocol, the prefer keyword would cause the local host to
# disregard all other synchronization sources, unless the kernel
# modifications are in use and declare an unsynchronized condition.
#
server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10
# The following servers hourly round-robin the actual time server
returned
# It helps balance load for upper level servers, but you need at least 3
# see http://www.ntp.org for others
# be friendly, don't use more than 3
server 0.us.pool.ntp.org
server 1.us.pool.ntp.org
server 2.us.pool.ntp.org
#server 3.us.pool.ntp.org
#server 0.north-america.pool.ntp.org
#server 1.north-america.pool.ntp.org
#server 2.north-america.pool.ntp.org
#server 3.north-america.pool.ntp.org
#
#
# Keys file. If you want to diddle your server at run time, make a
# keys file (mode 600 for sure) and define the key number to be
# used for making requests.
# PLEASE DO NOT USE THE DEFAULT VALUES HERE. Pick your own, or remote
# systems might be able to reset your clock at will.
#
#keys /etc/ntp/keys
#trustedkey 65535
#requestkey 65535
#controlkey 65535
# In 4.2 and beyond, cryptographic stuff changed notrust and nomodify
# see: http://support.ntp.org/bin/view/Support/AccessRestrictions
# original default line:
# restrict default noquery notrust nomodify
# trust localhost and my subnet
restrict 127.0.0.1
restrict 192.168.42.0 mask 255.255.255.0 notrap
--
The email address, above, is most certainly munged. Perhaps you
might reply to the newsgroup, instead? Thanks!
Grant
FWIW here's mine, working properly for years:
~$ cat /etc/ntp.conf
# /etc/ntp.conf for slackware on deltree 2004-11-18
# 2005-03-02 Added tpg.com.au timeserver
#
# Configuration, see
# http://twiki.ntp.org/bin/view/Servers/NTPPoolServers
# http://ntp.isc.org/bin/view/Support/ConfRestrict
# configure local clock as dummy refclock, making sure any clients
# know that it is not a high quality clock with stratum = 10
# Note that setting a dummy refclock seems a bad idea (2005-01-08)
#server 127.127.1.0
#fudge 127.127.1.0 stratum 10
# drift and log files
driftfile /etc/ntp/drift
#logfile /var/log/ntp_log
# Monitoring performance
# from: http://www.ntp.org/ntpfaq/NTP-s-trouble.htm
#statistics loopstats
#statsdir /var/log/
#filegen peerstats file peers type day link enable
#filegen loopstats file loops type day link enable
# Access control and server selection:
# set default restrictions
restrict default kod nomodify notrap nopeer noquery
# select time servers
server ntp2.tpg.com.au
server 0.au.pool.ntp.org
server 1.au.pool.ntp.org
server 2.au.pool.ntp.org
server au.pool.ntp.org
# restrict local server users less
restrict 127.0.0.1
restrict 192.168.3.0 mask 255.255.255.0 nomodify notrap nopeer
# end
--
http://bugsplatter.id.au
Thomas Ronayne
that your delay, offset and jitter values look way out of line (and may
-- may -- be a source of your problems). I'm sitting on a dial-up at the
moment (my high-speed connection is 200 miles away right now) and ntpq
-p reports
ntpq -p
remote refid st t when poll reach delay
offset jitter
==============================================================================
LOCAL(0) .LOCL. 10 l 24 64 377 0.000
0.000 0.001
*64.73.32.134 255.175.234.61 2 u 25 64 377 175.955
-9.592 2.271
+ip-72-167-54-20 192.12.19.20 2 u 52 64 377 243.968
-17.978 13.373
+lime1.adamantsy 72.18.205.156 3 u 1 64 377 200.945
-13.084 17.887
Which ain't great but ain't bad either.
Doing an ssh connection to my server (the one far, far away)
ntpq -p
remote refid st t when poll reach delay
offset jitter
==============================================================================
LOCAL(0) .LOCL. 10 l 15 64 377 0.000
0.000 0.001
+socorro.dayww.n 64.183.55.54 2 u 221 1024 377 55.792
3.700 0.364
*knowledge.globa 129.6.15.28 2 u 281 1024 377 37.576
-0.972 1.067
+packman-1.isc.o 131.107.13.100 2 u 259 1024 377 89.575
-4.860 0.814
Better.
So, I'm wondering if it would be worthwhile for you to abandon the pool
servers in favor of looking through the lists of stratum 2 servers
available where you physically are, ping them and make a list of three
stratum 2 servers that are electrically closest to you (which will
reduce the delay, offset and jitter values to a minimum for your
physical and electrical location. There is a list of stratum 2 servers
at http://support.ntp.org/bin/view/Servers/StratumTwoTimeServers that
may be useful (look for your country code).
The "best" (a relative term) may be at universities, state or province
sites, possibly some others -- the thing you're looking for is the
shortest ping time; e.g., the ping time for the stratum 2 server that
I'm currently synchronized to
ping -c 5 64.73.32.134
PING 64.73.32.134 (64.73.32.134) 56(84) bytes of data.
64 bytes from 64.73.32.134: icmp_seq=1 ttl=55 time=44.7 ms
64 bytes from 64.73.32.134: icmp_seq=2 ttl=55 time=39.4 ms
64 bytes from 64.73.32.134: icmp_seq=3 ttl=55 time=38.8 ms
64 bytes from 64.73.32.134: icmp_seq=4 ttl=55 time=38.7 ms
64 bytes from 64.73.32.134: icmp_seq=5 ttl=55 time=39.0 ms
--- 64.73.32.134 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4008ms
rtt min/avg/max/mdev = 38.715/40.174/44.761/2.314 ms
NTP is going to have a tough time synchronizing when the delay, offset
and jitter values are huge (matter of fact, it just flat won't).
Hope this helps some.
root
> NTP is going to have a tough time synchronizing when the delay, offset
> and jitter values are huge (matter of fact, it just flat won't).
>
> Hope this helps some.
I managed to get the daemon working after I changed the tick
value to get the clock close enough for ntpd to take over.
In fact, the new tick value makes the clock accurate enough
that I probably don't need ntpd.
nptd syncs up to different servers every time I boot. The
jitter values change accordingly, so I guess I win some
and lose some. I am happy with how the problem was resolved
and give thanks to everyone, including you, who helped.
Bud
>
> NTP is going to have a tough time synchronizing when the delay, offset
> and jitter values are huge (matter of fact, it just flat won't).
>
> Hope this helps some.
Here are a list of time servers http://tf.nist.gov/tf-cgi/servers.cgi
that use WWV in Boulder, CO which broadcasts time on 2.5, 5, 10 and 30
mHZ. There is also one in Hawaii and sometimes you can hear both and
hear the difference. Canada also has one, which I forget the name of the
radio station and frequency.
--
Bud