ntpd still not working

Petri Kaukasoina <kaukasoina802n54jc045.TakeThisOut@sci.fi> wrote:
>
> 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.

root <NoEMail RemoveThis @home.org> wrote:
> 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.

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

On Tue, 3 Nov 2009 09:47:23 +0000 (UTC),
Petri Kaukasoina <kaukasoina802n54jc045 DeleteThis @sci.fi> wrote:
> root <NoEMail DeleteThis @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.

Aha! Good catch, thanks for pointing it out!

--
Theodore (Ted) Heise <theo DeleteThis @heise.nu> Bloomington, IN, USA

On Tue, 3 Nov 2009 16:05:52 +0000 (UTC),
root <NoEMail.DeleteThis@home.org> wrote:
> root <NoEMail.DeleteThis@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.

--
Theodore (Ted) Heise <theo.DeleteThis@heise.nu> Bloomington, IN, USA

On Mon, 02 Nov 2009 15:46:55 +0000, root wrote:

> After everyone's help, the damned thing still 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.

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

root <NoEMail.DeleteThis@home.org> wrote in news:hcmutf$f0f$1@news.albasani.net:

> 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!

On Sat, 7 Nov 2009 18:33:27 +0000 (UTC), james <mentor.TakeThisOut@arisia.invalid> wrote:

>root <NoEMail.TakeThisOut@home.org> wrote in news:hcmutf$f0f$1@news.albasani.net:
>
>> 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

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-0
#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

Looking back over the problems you're having, one thing I've noticed is
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.

Thomas Ronayne <trona DeleteThis @ameritech.net> wrote:
> 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.

Thomas Ronayne wrote:
>
> 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