LinuxQuestions.org
Did you know LQ has a Linux Hardware Compatibility List?
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
Search this Thread
Old 04-30-2014, 10:11 AM   #16
GazL
Senior Member
 
Registered: May 2008
Posts: 3,584

Rep: Reputation: 1075Reputation: 1075Reputation: 1075Reputation: 1075Reputation: 1075Reputation: 1075Reputation: 1075Reputation: 1075

Quote:
Originally Posted by mlslk31 View Post
You could reduce your ntp.conf to this...

Code:
pool ca.pool.ntp.org
...and if it works, great! If not, leave it like that and start looking at other things. Again, be sure that you can reach out to the Internet on port 123/udp. After reading this thread several times, I wonder what the network-related files looked like when everything worked. If the old settings are lost, I'm not sure how a full reinstall would help. I've used DHCP only for PXE booting, so someone else will have to point out the subtle nuances of networking with ntpd.
I agree with mlslk31's assessment here. The fact that ntpdate itself was failing to find a server is telling, as the contents of the config file shouldn't matter in this case.

I'd be inclined to try "ntpdate -d ca.pool.ntp.org" and see if the additional diagnostics give you a clue as to the nature of the failure. (make sure ntpd isn't running when you run ntpdate, or you'll get a socket in use error)

The orphan mode v local clock discussion that tron and I have been having is probably confusing the issue, and you're probably better off without either of them in there until you get the thing to work with just a basic server or pool definition as mlslk31 suggests.


I'll step aside now, as I think there's a "too many cooks" issue going on here and its not helping your plight.
 
Old 04-30-2014, 10:46 AM   #17
WilliamS
Member
 
Registered: Nov 2003
Location: 46N 76W
Distribution: Slackware 14.1
Posts: 380

Original Poster
Rep: Reputation: 31
Installed from another dvd burnt with growisofs, and file browser behaves differently but I still get: format error frequency file /etc/ntp/drift from /var/log/syslog so I think that this dvd is also corrupt.
Downloaded another 14.1 and burnt to dvd with growisofs speed=4, but before it install again, can anyone tell me what this means?

# /etc/rc.d/rc.ntpd stop
Stopping NTP daemon...
bash-4.2# ntpdate -d ca.pool.ntp.org
30 Apr 11:42:01 ntpdate[11336]: ntpdate 4.2.6p5@1.2349-o Mon Oct 14 08:03:29 UTC 2013 (1)
Looking for host ca.pool.ntp.org and service ntp
host found : time.0x90.ca
transmit(174.142.10.100)
transmit(208.73.56.29)
transmit(209.172.32.214)
transmit(24.215.0.24)
receive(174.142.10.100)
receive(208.73.56.29)
receive(209.172.32.214)
receive(24.215.0.24)
transmit(174.142.10.100)
transmit(208.73.56.29)
transmit(209.172.32.214)
transmit(24.215.0.24)
receive(174.142.10.100)
receive(208.73.56.29)
receive(209.172.32.214)
receive(24.215.0.24)
transmit(174.142.10.100)
transmit(208.73.56.29)
transmit(209.172.32.214)
transmit(24.215.0.24)
receive(174.142.10.100)
receive(208.73.56.29)
receive(209.172.32.214)
receive(24.215.0.24)
transmit(174.142.10.100)
transmit(208.73.56.29)
transmit(209.172.32.214)
transmit(24.215.0.24)
receive(174.142.10.100)
receive(208.73.56.29)
receive(209.172.32.214)
receive(24.215.0.24)
server 174.142.10.100, port 123
stratum 2, precision -24, leap 00, trust 000
refid [174.142.10.100], delay 0.68056, dispersion 0.00064
transmitted 4, in filter 4
reference time: d70b9530.97edea3c Wed, Apr 30 2014 11:28:48.593
originate timestamp: d70b984a.d0ae846d Wed, Apr 30 2014 11:42:02.815
transmit timestamp: d70b9853.5f900dee Wed, Apr 30 2014 11:42:11.373
filter delay: 0.68056 0.68188 0.68179 0.68159
0.00000 0.00000 0.00000 0.00000
filter offset: -8.88591 -8.88769 -8.88715 -8.88616
0.000000 0.000000 0.000000 0.000000
delay 0.68056, dispersion 0.00064
offset -8.885914

server 208.73.56.29, port 123
stratum 2, precision -20, leap 00, trust 000
refid [208.73.56.29], delay 0.72992, dispersion 0.00055
transmitted 4, in filter 4
reference time: d70b92a4.a6f15487 Wed, Apr 30 2014 11:17:56.652
originate timestamp: d70b984b.080b130a Wed, Apr 30 2014 11:42:03.031
transmit timestamp: d70b9853.92c2ba71 Wed, Apr 30 2014 11:42:11.573
filter delay: 0.73053 0.73206 0.73251 0.72992
0.00000 0.00000 0.00000 0.00000
filter offset: -8.89451 -8.89357 -8.89580 -8.89403
0.000000 0.000000 0.000000 0.000000
delay 0.72992, dispersion 0.00055
offset -8.894034

server 209.172.32.214, port 123
stratum 3, precision -20, leap 00, trust 000
refid [209.172.32.214], delay 0.68053, dispersion 0.00067
transmitted 4, in filter 4
reference time: d70b9785.abb835ae Wed, Apr 30 2014 11:38:45.670
originate timestamp: d70b984b.37177a13 Wed, Apr 30 2014 11:42:03.215
transmit timestamp: d70b9853.c5f6e166 Wed, Apr 30 2014 11:42:11.773
filter delay: 0.68053 0.68088 0.68265 0.68152
0.00000 0.00000 0.00000 0.00000
filter offset: -8.88580 -8.88671 -8.88708 -8.88607
0.000000 0.000000 0.000000 0.000000
delay 0.68053, dispersion 0.00067
offset -8.885807

server 24.215.0.24, port 123
stratum 2, precision -18, leap 00, trust 000
refid [24.215.0.24], delay 0.68903, dispersion 0.00198
transmitted 4, in filter 4
reference time: d70b96da.4b0b558d Wed, Apr 30 2014 11:35:54.293
originate timestamp: d70b984b.6a24379b Wed, Apr 30 2014 11:42:03.414
transmit timestamp: d70b9853.f92a156c Wed, Apr 30 2014 11:42:11.973
filter delay: 0.68903 0.69124 0.70248 0.69049
0.00000 0.00000 0.00000 0.00000
filter offset: -8.88975 -8.88838 -8.89732 -8.89115
0.000000 0.000000 0.000000 0.000000
delay 0.68903, dispersion 0.00198
offset -8.889750

30 Apr 11:42:12 ntpdate[11336]: step time server 174.142.10.100 offset -8.885914 sec
bash-4.2#

TIA


(just now checked again, and WWV shows computer is still 9 seconds fast.)

Last edited by WilliamS; 04-30-2014 at 10:50 AM.
 
Old 04-30-2014, 10:59 AM   #18
GazL
Senior Member
 
Registered: May 2008
Posts: 3,584

Rep: Reputation: 1075Reputation: 1075Reputation: 1075Reputation: 1075Reputation: 1075Reputation: 1075Reputation: 1075Reputation: 1075
Looking at that, ntpdate looks to be working correctly, which is different than you described before as you were reporting:
Quote:
29 Apr 09:36:53 ntpdate[1397]: no server suitable for synchronization found
I'd be inclined to ignore the error about the drift file for now (it might just be because it was empty/uninitialised), ntpd will most likely re-write it with something meaningful before too long.
Just do a /etc/rc.d/rc.ntpd start to restart ntpd and keep an eye on it with 'ntpq -pn' for now and see what happens.
 
Old 04-30-2014, 11:07 AM   #19
tronayne
Senior Member
 
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,148

Rep: Reputation: 835Reputation: 835Reputation: 835Reputation: 835Reputation: 835Reputation: 835Reputation: 835
Quote:
Originally Posted by WilliamS View Post
Tronayne, content of /etc/resolv.conf is
# Generated by dhcpcd from eth0
# /etc/resolv.conf.head can replace this line
nameserver 192.168.175.250
nameserver 192.168.175.251
# /etc/resolv.conf.tail can replace this line

Then: # ntpdate 0.ca.pool.ntp.org
29 Apr 23:38:22 ntpdate[13055]: no server suitable for synchronization found
When you execute that line and get that result, can you ping that address; e.g.,
Code:
ping -c 5 0.ca.pool.ntp.org
PING 0.ca.pool.ntp.org (206.108.0.132) 56(84) bytes of data.
64 bytes from ntp2.torix.ca (206.108.0.132): icmp_seq=1 ttl=239 time=931 ms
64 bytes from ntp2.torix.ca (206.108.0.132): icmp_seq=2 ttl=239 time=640 ms
64 bytes from ntp2.torix.ca (206.108.0.132): icmp_seq=3 ttl=239 time=634 ms
64 bytes from ntp2.torix.ca (206.108.0.132): icmp_seq=4 ttl=239 time=631 ms
64 bytes from ntp2.torix.ca (206.108.0.132): icmp_seq=5 ttl=239 time=617 ms

--- 0.ca.pool.ntp.org ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4656ms
rtt min/avg/max/mdev = 617.673/691.265/931.836/120.525 ms
If that does not work -- you can't ping it and get a response similar to the above -- then you have a DNS problem.

If you can ping and get a similar response but ntpdate still says that no server can be found, the port may not enabled (it is enabled by default in Slackware in the file /etc/services entries for Network Time Protocol). If the DNS addresses in your /etc/resolv.conf file are a local router and the router has port 123/tcp or 123/udp closed, you would want to enable NTPD, port 123 to port 123, protocol UDP in your router if necessary, routers don't always pass those ports by default (my Linksys BEFSR41 does not, I had to enable it in the Applications & Gaming section of the router set up).

Note that if you have a router connected to your network interface that it's recommended that you use a fixed-IP address for your system; e.g., 192.168.1.10 or something less than 192.168.1.100 (which is where DHCP starts addressing). The default gateway address, for a Linksys, is 192.168.1.1 (it's the base address of the router, other routers use different addresses). That's not me, that's Linksys' advice. The router uses DHCP to connect to the network interface, but your system connects to the router with a fixed address. Of course if you don't have a router connected between the system and the network interface, that's irrelevant.
Quote:
Originally Posted by WilliamS View Post
and
# ls /var/log/packages/ntp*
/var/log/packages/ntp-4.2.6p5-i486-5_slack14.1
That's the correct version of NTP.
Quote:
Originally Posted by WilliamS View Post
I'm thinking that ntp always worked before 14.1, I always did the servers and driftfile and commented out the fudge, as others, and nobody else complains.
So I intend to reinstall 14.1 from a different DVD.
You probably don't need to do that, but check your router set up and whether your DNS server is finding a pool server; all NTP pool servers are pingable.

Hope this helps some.
 
Old 04-30-2014, 11:27 AM   #20
mlslk31
Member
 
Registered: Mar 2013
Location: Florida, USA
Distribution: Slackware, FreeBSD
Posts: 196

Rep: Reputation: 68
Quote:
Originally Posted by tronayne View Post
For right now, tos orphan may not be a Real Good Idea; you can go read information about orphan mode at http://support.ntp.org/bin/view/Support/OrphanMode. I will admit that I don't totally understand precisely what the difference is between an end-user (such as you, me, and most other folks that don't serve time to the Internet) using an undisciplined local clock (as in the above example) and orphan mode which is mostly about preventing reflected denial of server (DRDoS) attacks.
Orphan mode is better explained at http://www.eecis.udel.edu/~mills/ntp/html/orphan.html. Also, the current documentation for the undisciplined local clock states about itself, "This is not recommended for new installations."

LOCAL was great in the days of intermittent dial-up Internet. Those days are mostly gone. Orphan mode is a way for the NTP developers to admit they were wrong the first time without admitting they were wrong; that maybe it was a bad idea to risk having fake UTC sources getting mixed up with real sources. The difference seems to be that with LOCAL, it's a simulated UTC refclock that can compete with the other refclocks. With orphan, you work with legitimate refclocks, and when they don't work, the server refid turns to 127.0.0.1 when sources of time have been lost. After that, it seems like only other explicit orphans will play with this orphan scheme...though orphan is confusing, and I could be wrong about this last part.

Otherwise, you're right. Orphan is rather tricky and evil, giving unexpected results until everything is setup perfectly for server and clients. It should be configured after normal time service has been set up. Leave orphan out for now.

Just curious, WilliamS, does CHU come in loud and clear on any of 3330, 7850, or 14670 kHz? You had some coordinates in your info, and they seemed rather close to the CHU transmitters in Ottawa...just didn't know if you were in CHU's skip zone. I use CHU here in Florida when WWV has propagation issues.
 
Old 04-30-2014, 11:34 AM   #21
tronayne
Senior Member
 
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,148

Rep: Reputation: 835Reputation: 835Reputation: 835Reputation: 835Reputation: 835Reputation: 835Reputation: 835
Quote:
Originally Posted by GazL View Post
Looking at that, ntpdate looks to be working correctly, which is different than you described before as you were reporting:

I'd be inclined to ignore the error about the drift file for now (it might just be because it was empty/uninitialised), ntpd will most likely re-write it with something meaningful before too long.
Just do a /etc/rc.d/rc.ntpd start to restart ntpd and keep an eye on it with 'ntpq -pn' for now and see what happens.
Yup it does!

Ta-da!

You can
Code:
cat /etc/ntp/drift
any you should see a floating-point number (it could be zero, too).

For example, mine looks like (your will not be the same):
Code:
cat /etc/ntp/drift
-11.857
There is only one line, no comments, no blank lines, only one value on the line and it is numeric.

The file mode should be
Code:
ls -al /etc/ntp/drift
-rw-r--r-- 1 root root 8 Apr 30 11:59 /etc/ntp/drift
NTP will walk your clock into synchronization to the point that it will be a few milliseconds off (it's never going to be dead nuts unless you've got an expensive GPS or radio timeserver connected to your network). A millisecond here, a millisecond there, you're talking nits. That 9 seconds off you're seeing will, after a few days, become almost nothing, just wait a while.

Take GazL's advice, it's pretty good.
 
Old 04-30-2014, 11:35 AM   #22
WilliamS
Member
 
Registered: Nov 2003
Location: 46N 76W
Distribution: Slackware 14.1
Posts: 380

Original Poster
Rep: Reputation: 31
Tried this, still the same:
# ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
192.95.20.208 .INIT. 16 u - 1024 0 0.000 0.000 0.000
142.137.247.109 .INIT. 16 u - 1024 0 0.000 0.000 0.000
208.81.2.13 .INIT. 16 u - 1024 0 0.000 0.000 0.000
206.108.0.131 .INIT. 16 u - 1024 0 0.000 0.000 0.000
bash-4.2#

I have no router. Direct satellite connection.
# ping -c 3 0.ca.pool.ntp.org
PING 0.ca.pool.ntp.org (67.215.197.151) 56(84) bytes of data.
64 bytes from swordfish.hopcount.ca (67.215.197.151): icmp_seq=1 ttl=54 time=707 ms
64 bytes from swordfish.hopcount.ca (67.215.197.151): icmp_seq=2 ttl=54 time=674 ms
64 bytes from swordfish.hopcount.ca (67.215.197.151): icmp_seq=3 ttl=54 time=645 ms

--- 0.ca.pool.ntp.org ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2501ms
rtt min/avg/max/mdev = 645.930/676.067/707.991/25.376 ms
bash-4.2#
 
Old 04-30-2014, 12:38 PM   #23
mlslk31
Member
 
Registered: Mar 2013
Location: Florida, USA
Distribution: Slackware, FreeBSD
Posts: 196

Rep: Reputation: 68
Remember, ping and NTP are two different issues. The net is not as friendly as it used to be--can't just use `ntpq -p hostname` any more and expect it to work--so I had to resort to this method to see which hosts were up:

Code:
root:~# ntpq -np
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
-69.172.212.61   142.54.181.202   3 u  746 1024  377   90.414   -8.290   5.853
+38.229.71.1     172.16.32.4      2 u  423  512  377   69.731   -0.363   3.173
-173.230.158.30  199.102.46.73    2 u  127  512  337  101.367    2.431   3.780
+71.19.149.98    204.123.2.72     2 u  344  512  377   95.606   -1.690   1.382
*137.190.2.4     .GPS.            1 u  474  512  377   70.180    2.825   4.049

# I use those number addresses from above and feed them to nmap...

root:~# nmap -p123 -sU 137.190.2.4 38.229.71.1 71.19.149.98

Starting Nmap 6.01 ( http://nmap.org ) at 2014-04-30 13:10 EDT
Nmap scan report for tedc-gps1.weber.edu (137.190.2.4)
Host is up (0.10s latency).
PORT    STATE SERVICE
123/udp open  ntp

Nmap scan report for clock.team-cymru.org (38.229.71.1)
Host is up (0.087s latency).
PORT    STATE SERVICE
123/udp open  ntp

Nmap scan report for rcloran.xen.prgmr.com (71.19.149.98)
Host is up (0.11s latency).
PORT    STATE SERVICE
123/udp open  ntp

Nmap done: 3 IP addresses (3 hosts up) scanned in 0.31 seconds
Also, should debugging be in your ntpd (I think), you can stop ntpd and try this:

Code:
root:~# ntpd -Nndg -c whatever_ntp_conf_you_want_to_use

# comments are mine
ntpd 4.2.6p5@1.2349-o Tue Apr  8 23:14:07 UTC 2014 (1)
# ... much internal setup snipped ...
# setup remote "server"
key_expire: at 0 associd 57333
peer_clear: at 0 next 1 associd 57333 refid INIT
event at 0 199.19.167.36 8011 81 mobilize assoc 57333
newpeer: 192.168.0.129->199.19.167.36 mode 3 vers 4 poll 6 10 flags 0x1 0x1 ttl 0 key 00000000
# setup remote "server"
key_expire: at 0 associd 57334
peer_clear: at 0 next 2 associd 57334 refid INIT
event at 0 199.182.221.110 8011 81 mobilize assoc 57334
newpeer: 192.168.0.129->199.182.221.110 mode 3 vers 4 poll 6 10 flags 0x1 0x1 ttl 0 key 00000000
# setup remote "server"
key_expire: at 0 associd 57335
peer_clear: at 0 next 3 associd 57335 refid INIT
event at 0 208.80.96.70 8011 81 mobilize assoc 57335
newpeer: 192.168.0.129->208.80.96.70 mode 3 vers 4 poll 6 10 flags 0x1 0x1 ttl 0 key 00000000
key_expire: at 0 associd 57336
# setup remote "server"
peer_clear: at 0 next 4 associd 57336 refid INIT
event at 0 198.245.49.187 8011 81 mobilize assoc 57336
newpeer: 192.168.0.129->198.245.49.187 mode 3 vers 4 poll 6 10 flags 0x1 0x1 ttl 0 key 00000000
# internal state
event at 0 0.0.0.0 c016 06 restart
event at 0 0.0.0.0 c012 02 freq_set kernel 0.000 PPM
event at 0 0.0.0.0 c011 01 freq_not_set
# good receive
transmit: at 1 192.168.0.129->199.19.167.36 mode 3 len 48
auth_agekeys: at 1 keys 1 expired 0
receive: at 1 192.168.0.129<-199.19.167.36 mode 4 len 48
event at 1 199.19.167.36 8024 84 reachable
clock_filter: n 1 off 0.007866 del 0.083710 dsp 7.937502 jit 0.000001
# good receive
transmit: at 2 192.168.0.129->199.182.221.110 mode 3 len 48
receive: at 2 192.168.0.129<-199.182.221.110 mode 4 len 48
event at 2 199.182.221.110 8024 84 reachable
clock_filter: n 1 off 0.008942 del 0.105870 dsp 7.937501 jit 0.000001
# good receive
transmit: at 3 192.168.0.129->208.80.96.70 mode 3 len 48
receive: at 3 192.168.0.129<-208.80.96.70 mode 4 len 48
event at 3 208.80.96.70 8024 84 reachable
clock_filter: n 1 off 0.007138 del 0.076863 dsp 7.937502 jit 0.000001
# good receive
transmit: at 4 192.168.0.129->198.245.49.187 mode 3 len 48
receive: at 4 192.168.0.129<-198.245.49.187 mode 4 len 48
event at 4 198.245.49.187 8024 84 reachable
clock_filter: n 1 off 0.005559 del 0.082381 dsp 7.937501 jit 0.000001
# good transmit to client
receive: at 13 192.168.0.129<-192.168.0.134 mode 3 len 48
transmit: at 13 192.168.0.129->192.168.0.134 mode 4 len 48
ntpd[15545]: ntpd exiting on signal 2
If not, maybe you should think about putting debugging in there. Sorry for the long cut-and-paste.

9 seconds should be well within what ntpd can correct, so I've stopped short of asking you to use the date command to set the time, then start ntpd.

BTW, satellite makes things a little different. I hope they haven't filtered out port 123. My only experience with satellite has been HughesNet. It seemed like ntpd took longer to work well over satellite, and that it was best to choose servers closest to whatever building HughesNet used to uplink to the satellite. Memory is hazy...
 
Old 04-30-2014, 12:52 PM   #24
GazL
Senior Member
 
Registered: May 2008
Posts: 3,584

Rep: Reputation: 1075Reputation: 1075Reputation: 1075Reputation: 1075Reputation: 1075Reputation: 1075Reputation: 1075Reputation: 1075
What I don't get is why, when they both use the same protocol, ntpdate managed to work when ntp isn't managing to get past INIT.
But perhaps the debugging options will reveal something interesting.
 
Old 04-30-2014, 01:16 PM   #25
tronayne
Senior Member
 
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,148

Rep: Reputation: 835Reputation: 835Reputation: 835Reputation: 835Reputation: 835Reputation: 835Reputation: 835
OK, thought I'd give tos orphan a shot so I shut down one of my LAN servers (that is normally synchronized with my main work station with NTP).

I copied /etc/ntp.conf to /etc/ntp.conf.bak

I copied /etc/ntp.conf.new to /etc/ntp.con

I edited /etc/ntp.conf with these changes:
Code:
# Comment the local clock out to enable tos orphan
#server	127.127.1.0	# local clock
#fudge	127.127.1.0 stratum 10	
#
# Enable tos orphan
tos orphan

#
# NTP server (list one or more) to synchronize with:
#server pool.ntp.org iburst
server 0.us.pool.ntp.org
server 1.us.pool.ntp.org
server 2.us.pool.ntp.org
I made no other changes in the configuration.

I immediately ran ntpq -pn
Code:
ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 142.54.185.82   216.229.0.49     3 u    1   64    1  615.862   12.121   0.001
 208.75.89.4     .INIT.          16 u    -   64    0    0.000    0.000   0.000
 134.121.64.62   .INIT.          16 u    -   64    0    0.000    0.000   0.001
Result as expected, no synchronization, three candidates.

I then decided to see how long it would take to get synchronized and did
Code:
snafu-root-/etc: while true
> do
>       ntpq -pn
>       sleep 60
> done
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*142.54.185.82   216.229.0.49     3 u    2   64    3  574.522   11.046   7.418
 208.75.89.4     134.121.64.86    2 u    4   64    3  596.296   17.907  20.648
 134.121.64.62   .GPS.            1 u    1   64    3  594.460    6.778  11.397
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*142.54.185.82   216.229.0.49     3 u   62   64    3  574.522   11.046   7.418
 208.75.89.4     134.121.64.86    2 u   64   64    3  596.296   17.907  20.648
 134.121.64.62   .GPS.            1 u   61   64    3  594.460    6.778  11.397
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*142.54.185.82   216.229.0.49     3 u   54   64    7  574.522   11.046   9.373
 208.75.89.4     134.121.64.86    2 u   55   64    7  596.296   17.907  58.949
 134.121.64.62   .GPS.            1 u   54   64    7  594.460    6.778  13.137
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*142.54.185.82   216.229.0.49     3 u   46   64   17  574.522   11.046   9.624
 208.75.89.4     134.121.64.86    2 u   49   64   17  597.221    0.980  67.293
 134.121.64.62   .GPS.            1 u   44   64   17  594.460    6.778 140.104
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*142.54.185.82   216.229.0.49     3 u   38   64   37  558.553    5.681  11.736
+208.75.89.4     134.121.64.86    2 u   42   64   37  615.788   23.223  57.660
+134.121.64.62   .GPS.            1 u   37   64   37  615.222    6.495 140.291
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+142.54.185.82   216.229.0.49     3 u   32   64   77  558.553    5.681  12.241
+208.75.89.4     134.121.64.86    2 u   36   64   77  615.967    5.863  89.746
*134.121.64.62   .GPS.            1 u   31   64   77  611.150    0.776 142.894
Took five minutes to get synchronized with additional candidates identified and one more minute to switch from the original synchronized server to the GPS reference server.

Conclusion: looks like it works as advertised.

I did not specify a value for orphan (the default is 16, that's good enough, methinks). The recommended value for N is 2 less than the worst-case externally-reachable source of time. Normally, the reason for either Undisciplined Local Clock (the old method) or Orphan (the new method) is that NTP continues running when the Internet (or a local time reference) is unavailable; NTP would fall back to synchronizing with the local (system) clock with no external source of time then resynchronize with an external reference when the Internet comes back and one or more are available. It would do the same thing on my LAN if the time server becomes unavailable (shut down for some reason or other).

An examination of the ntpq displays indicates that the recommended value (which is also an example value in the documentation) be 6; i.e., stratum 1 - 5 servers (I have never seen a stratum 4 server being used, the normal in my installation is stratum 2 or 3 and the GPS server in the examples above being referenced to a stratum 1 server is the first I've ever seen).

I'm inclined to edit /etc/ntp.conf and add the value 6 as the N argument to the tos orphan line. Ought to cover pretty much everything.

But, what happens when the Internet goes away? Supposed to go into orphan mode and wait until an external server becomes available.

OK, pull the plug, wait a while (like 5 minutes) and plug it back in.

Synchronized right up.

Hm.
 
Old 04-30-2014, 01:45 PM   #26
tronayne
Senior Member
 
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,148

Rep: Reputation: 835Reputation: 835Reputation: 835Reputation: 835Reputation: 835Reputation: 835Reputation: 835
Quote:
Originally Posted by mlslk31 View Post
BTW, satellite makes things a little different. I hope they haven't filtered out port 123. My only experience with satellite has been HughesNet. It seemed like ntpd took longer to work well over satellite, and that it was best to choose servers closest to whatever building HughesNet used to uplink to the satellite. Memory is hazy...
It does a little longer, like a couple of minutes, just because of the 22,500 miles up, down, back up, back down delay. Had the laptop attached to one of Merit's fiber optic connections a couple of weeks ago and it took about two- or three minutes to synchronize (there's a lot of mumbling to itself that goes on in NTP).

Seem like, if the OPs provider was filtering out port 123, probably wouldn't be able to get a time setting from ntpdate -- but I really don't know that for absolute certain.
 
Old 04-30-2014, 03:29 PM   #27
WilliamS
Member
 
Registered: Nov 2003
Location: 46N 76W
Distribution: Slackware 14.1
Posts: 380

Original Poster
Rep: Reputation: 31
2# ntpq -np
remote refid st t when poll reach delay offset jitter
==============================================================================
192.95.20.208 .INIT. 16 u - 1024 0 0.000 0.000 0.000
142.137.247.109 .INIT. 16 u - 1024 0 0.000 0.000 0.000
208.81.2.13 .INIT. 16 u - 1024 0 0.000 0.000 0.000
206.108.0.131 .INIT. 16 u - 1024 0 0.000 0.000 0.000
bash-4.2# nmap -p123 -sU nmap -p123 -sU 206.108.0.131
Only 1 -p option allowed, separate multiple ranges with commas.
QUITTING!
bash-4.2# nmap -p1 -sU nmap 206.108.0.131

Starting Nmap 6.40 ( http://nmap.org ) at 2014-04-30 16:23 EDT
Failed to resolve "nmap".
Nmap scan report for ntp1.torix.ca (206.108.0.131)
Host is up (0.0019s latency).
PORT STATE SERVICE
1/udp open|filtered tcpmux

Nmap done: 1 IP address (1 host up) scanned in 3.00 seconds
bash-4.2# nmap -p1 -sU nmap 142.137.247.109

Starting Nmap 6.40 ( http://nmap.org ) at 2014-04-30 16:24 EDT
Failed to resolve "nmap".
Nmap scan report for ntp.lanets.ca (142.137.247.109)
Host is up (0.0011s latency).
PORT STATE SERVICE
1/udp open|filtered tcpmux

Nmap done: 1 IP address (1 host up) scanned in 2.85 seconds
bash-4.2# /etc/rc.d/rc.ntpd stop
Stopping NTP daemon...
bash-4.2# 142.137.247.109

and

# ntpd -Nndg -c /etc/ntp.conf
ntpd 4.2.6p5@1.2349-o Mon Oct 14 08:03:28 UTC 2013 (1)
30 Apr 16:26:19 ntpd[15539]: proto: precision = 0.208 usec
event at 0 0.0.0.0 c01d 0d kern kernel time sync enabled
Finished Parsing!!
30 Apr 16:26:19 ntpd[15539]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
30 Apr 16:26:19 ntpd[15539]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
30 Apr 16:26:19 ntpd[15539]: Listen and drop on 1 v6wildcard :: UDP 123
30 Apr 16:26:19 ntpd[15539]: Listen normally on 2 lo 127.0.0.1 UDP 123
restrict: op 1 addr 127.0.0.1 mask 255.255.255.255 mflags 00003000 flags 00000001
30 Apr 16:26:19 ntpd[15539]: Listen normally on 3 eth0 192.95.192.36 UDP 123
restrict: op 1 addr 192.95.192.36 mask 255.255.255.255 mflags 00003000 flags 00000001
30 Apr 16:26:19 ntpd[15539]: Listen normally on 4 lo ::1 UDP 123
restrict: op 1 addr ::1 mask ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff mflags 00003000 flags 00000001
30 Apr 16:26:19 ntpd[15539]: Listen normally on 5 eth0 fe80::1e6f:65ff:fe4c:79cd UDP 123
restrict: op 1 addr fe80::1e6f:65ff:fe4c:79cd mask ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff mflags 00003000 flags 00000001
30 Apr 16:26:19 ntpd[15539]: peers refreshed
30 Apr 16:26:19 ntpd[15539]: Listening on routing socket on fd #22 for interface updates
restrict: op 1 addr 0.0.0.0 mask 0.0.0.0 mflags 00000000 flags 000000c0
restrict: op 1 addr :: mask 0.0.0.0 mflags 00000000 flags 000000c0
restrict: op 1 addr 127.0.0.1 mask 255.255.255.255 mflags 00000000 flags 00000000
30 Apr 16:26:19 ntpd[15539]: format error frequency file /etc/ntp/drift
key_expire: at 0 associd 652
peer_clear: at 0 next 1 associd 652 refid INIT
event at 0 206.108.0.131 8011 81 mobilize assoc 652
newpeer: 192.95.192.36->206.108.0.131 mode 3 vers 4 poll 6 10 flags 0x1 0x1 ttl 0 key 00000000
key_expire: at 0 associd 653
peer_clear: at 0 next 2 associd 653 refid INIT
event at 0 208.80.96.70 8011 81 mobilize assoc 653
newpeer: 192.95.192.36->208.80.96.70 mode 3 vers 4 poll 6 10 flags 0x1 0x1 ttl 0 key 00000000
key_expire: at 0 associd 654
peer_clear: at 0 next 3 associd 654 refid INIT
event at 0 198.50.145.138 8011 81 mobilize assoc 654
newpeer: 192.95.192.36->198.50.145.138 mode 3 vers 4 poll 6 10 flags 0x1 0x1 ttl 0 key 00000000
key_expire: at 0 associd 655
peer_clear: at 0 next 4 associd 655 refid INIT
event at 0 198.50.209.202 8011 81 mobilize assoc 655
newpeer: 192.95.192.36->198.50.209.202 mode 3 vers 4 poll 6 10 flags 0x1 0x1 ttl 0 key 00000000
event at 0 0.0.0.0 c016 06 restart
event at 0 0.0.0.0 c012 02 freq_set kernel 0.000 PPM
event at 0 0.0.0.0 c011 01 freq_not_set
transmit: at 1 192.95.192.36->206.108.0.131 mode 3 len 48
auth_agekeys: at 1 keys 1 expired 0
transmit: at 2 192.95.192.36->208.80.96.70 mode 3 len 48
transmit: at 3 192.95.192.36->198.50.145.138 mode 3 len 48
transmit: at 4 192.95.192.36->198.50.209.202 mode 3 len 48
transmit: at 66 192.95.192.36->208.80.96.70 mode 3 len 48
transmit: at 68 192.95.192.36->206.108.0.131 mode 3 len 48
transmit: at 68 192.95.192.36->198.50.145.138 mode 3 len 48
transmit: at 71 192.95.192.36->198.50.209.202 mode 3 len 48
transmit: at 130 192.95.192.36->208.80.96.70 mode 3 len 48
transmit: at 132 192.95.192.36->198.50.145.138 mode 3 len 48
transmit: at 134 192.95.192.36->206.108.0.131 mode 3 len 48
transmit: at 136 192.95.192.36->198.50.209.202 mode 3 len 48
 
Old 04-30-2014, 04:55 PM   #28
mlslk31
Member
 
Registered: Mar 2013
Location: Florida, USA
Distribution: Slackware, FreeBSD
Posts: 196

Rep: Reputation: 68
That should be `nmap -p123 -sU hosts-to-check`. "-p123" means "check port 123." "-sU" means "scan UDP." It should work, but it's worth that extra try, in case it doesn't work.

Your ntpd debug output is showing that has sent out trasmit packets to the external time servers. However, it has not received any replies from any of them. It keeps re-sending those packets every 64s, which is expected. Hopefully, all of your restrict lines have been removed from ntp.conf for that test.

I'd be looking to see where the round trip from PC to time server and back has been broken. In case multiple devices on your network can be the gateway, be sure that the correct device is chosen. In case there's a mix of IPv4 and IPv6 PCs, try using `server -4 whatever-pc` instead of `server whatever-pc`.

This is the part where I'd be looking at a backup of /etc from your previous system to see what's different, or compare settings with another PC on your network that's working just fine.
 
Old 04-30-2014, 06:02 PM   #29
Xsane
Member
 
Registered: Jan 2014
Posts: 60

Rep: Reputation: 28
Quote:
Originally Posted by tronayne View Post
Hardware clocks are, any more, fairly accurate. System clocks are notorious for drifting all over the place without something (like NTP) keeping them on time...
It is possible for an offline Linux Box to keep good datetime. I have been working to make this true in Slackware.

While System Clocks typically need to have their rate set, they are also typically more stable than the RTC. For example, the System Clock rate can be set in /etc/rc.d/rc.local like this:
Code:
/sbin/adjtimex --tick 10000 --freq 1838292
Of course, you must first figure out the correct values for your machine.

Quote:
Originally Posted by tronayne View Post
Others prefer both the hardware and software clocks to use local time.
System Clock always ticks in UTC. That is why hwclock must be told what RTC is ticking in, so that it can covert it to UTC as necessary for --hctosys.

.
 
Old 05-01-2014, 07:52 AM   #30
tronayne
Senior Member
 
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,148

Rep: Reputation: 835Reputation: 835Reputation: 835Reputation: 835Reputation: 835Reputation: 835Reputation: 835
OK, let's stop screwing around.

There was a fumble finger in an earlier post about looking for UTC in two files in /etc; this is the correction:
Code:
grep UTC /etc/* 2>/dev/null
adjtime:UTC
hardwareclock:UTC
You should have that if for no other reason than eliminating any possible goofy (technical term) stuff.

I used the standard Slackware /etc/ntp.conf file as installed (no edits whatsoever in it).

I edited and added the server section:
Code:
server	127.127.1.0	# local clock
fudge	127.127.1.0 stratum 10	

#
# NTP server (list one or more) to synchronize with:
#server pool.ntp.org iburst
server	0.ca.pool.ntp.org
server	1.ca.pool.ntp.org
server	2.ca.pool.ntp.org
I added logging entires:
Code:
# Log file
logfile /var/log/ntp.log
# Log file config
logconfig=clockall +peerall +sysall +syncall
Nothing else was removed or added or edited.

I stopped my running NTP daemon and started it using this /etc/ntp.conf file (remember, I'm in the US but I used Canadian pool servers).

After about five minutes,
Code:
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 127.127.1.0     .LOCL.          10 l  774   64    0    0.000    0.000   0.000
+198.50.145.138  206.108.0.131    2 u   46  128  377  621.634   21.428  81.650
+198.27.65.66    142.3.100.2      2 u  106  128  377  650.440   36.507 125.289
*142.165.36.190  142.3.100.2      2 u  117  128  377  649.398   -3.896  37.421
I'm synchronized. It works.

The working ntp.conf.txt file is attached for you to try -- do not edit it in any way.

To use it, as root
  • Stop the NTP daemon: /etc/rc.d/rc.ntpd stop
  • Create a clean, empty NTP log file (if it does not already exist): rm /var/log/ntp.log; touch /var/log/ntp.log
  • Back up your existing conf file: cp /etc/ntp.conf /etc/ntp.conf.bak
  • Save the attachment on your system.
  • Copy the attached file to /etc: cp ntp.conf.txt /etc/ntp.conf
  • Note: the following line will set the clock using the servers in /etc/ntp.conf it might take a couple of minutes to do so because it will sample the three pool servers, set the clock and exit.
  • Set the clock: ntpd -g -q
  • Start the NTP daemon: /etc/rc.d/rc.ntpd start
If you immediately execute ntpq -pn, you should see the .LOCL. and three external servers. At this point you're not synchronized (there will be an asterisk at the head of the .LOCL. line.

Wait about five minutes (maybe a little longer) and you should see something similar to this:
Code:
ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 127.127.1.0     .LOCL.          10 l  774   64    0    0.000    0.000   0.000
+198.50.145.138  206.108.0.131    2 u   46  128  377  621.634   21.428  81.650
+198.27.65.66    142.3.100.2      2 u  106  128  377  650.440   36.507 125.289
*142.165.36.190  142.3.100.2      2 u  117  128  377  649.398   -3.896  37.421
After a while, if you view the log, you should see something similar to this:
Code:
cat /var/log/ntp.log
 1 May 07:51:17 ntpd[768]: LOCAL(0) 8011 81 mobilize assoc 60152
 1 May 07:51:17 ntpd[768]: 198.50.145.138 8011 81 mobilize assoc 60153
 1 May 07:51:20 ntpd[768]: 198.27.65.66 8011 81 mobilize assoc 60154
 1 May 07:51:21 ntpd[768]: 142.165.36.190 8011 81 mobilize assoc 60155
 1 May 07:51:21 ntpd[768]: 0.0.0.0 c016 06 restart
 1 May 07:51:21 ntpd[768]: 0.0.0.0 c012 02 freq_set kernel -12.214 PPM
 1 May 07:51:21 ntpd[768]: LOCAL(0) 8024 84 reachable
 1 May 07:51:21 ntpd[768]: LOCAL(0) 903a 8a sys_peer
 1 May 07:51:21 ntpd[768]: 0.0.0.0 c515 05 clock_sync
 1 May 07:51:23 ntpd[768]: 198.50.145.138 8024 84 reachable
 1 May 07:51:24 ntpd[768]: 198.27.65.66 8024 84 reachable
 1 May 07:51:25 ntpd[768]: 142.165.36.190 8024 84 reachable
 1 May 07:54:41 ntpd[768]: 142.165.36.190 903a 8a sys_peer
 1 May 07:56:53 ntpd[768]: 198.50.145.138 943a 8a sys_peer
 1 May 07:59:05 ntpd[768]: 142.165.36.190 941a 8a sys_peer
 1 May 08:03:05 ntpd[768]: LOCAL(0) 8043 83 unreachable
 1 May 08:21:13 ntpd[768]: 198.27.65.66 943a 8a sys_peer
The line above
Code:
 1 May 08:03:05 ntpd[768]: LOCAL(0) 8043 83 unreachable
is where the daemon synchronized to, on the line below that
Code:
 1 May 08:21:13 ntpd[768]: 198.27.65.66 943a 8a sys_peer
This all presupposes that you have not edited /etc/rc.d/rc.ntpd; if you did, you might want to remove any edits before starting the daemon.

If this works, we can change /etc/ntp.conf to use tos orphan if you want to, just don't do that right now, let's start with a know good configuration file, eh?

Hope this helps some.
Attached Files
File Type: txt ntp.conf.txt (2.3 KB, 2 views)

Last edited by tronayne; 05-01-2014 at 10:39 AM.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
NTP client is not syncing to ntp server LittleMaster Linux - Newbie 6 04-05-2013 02:37 PM
[SOLVED] NTP configuration in client to synchronize with NTP server. antnish Linux - General 12 04-01-2013 01:49 PM
ntp drift file in /etc/ntp instead of /var/lib/ntp - suggestion for a patch in Slack niels.horn Slackware 16 05-07-2009 07:35 PM
ntp problem,,, Anmar Linux - Software 0 03-26-2004 10:35 AM
ntp problem ? virtaava Linux - Newbie 0 10-09-2001 05:27 AM


All times are GMT -5. The time now is 11:46 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration