NTP howto

From Rsewiki
(Difference between revisions)
Jump to: navigation, search
 
(24 intermediate revisions by one user not shown)
Line 1: Line 1:
−
This is a short description on how to get two computers have the same clock using NTP (Network Time Protocol)
+
This is a short description on how to make two computers have the same clock using NTP (Network Time Protocol)
  
−
'''NTPD how'''
+
==Packages==
  
−
NTPD - ntp demon (ntpd) - must run on both (all) computers that needs to be synchronized.
+
Install NTP and NTPDATE
  
−
The sync is - should - be obtained in two steps:
+
sudo apt-get install ntp ntpdate
 +
 
 +
==Quick instructions==
 +
 
 +
Assuming two computers are to be synchronized, one called master (192.168.0.210 (smr default)) and the other slave (192.168.0.20).
 +
If on one of the campus networks, use the network gateway as time server, here 10.59.8.1 is a fine stratum 4 server, and all other NTP servers are blocked on this network.
 +
 
 +
===Are master and slave running OK===
 +
 
 +
'''Test that master''' is running (as root on the master):
 +
 
 +
'''ntpq -p'''
 +
      remote          refid      st t when poll reach  delay  offset  jitter
 +
==============================================================================
 +
*LOCAL(0)        .LOCL.          6 l  39  64  377    0.000    0.000  0.001
 +
 
 +
The important things are that there is a '*' at the start of the line and the 'st' (stratum) value is less than 15. This should be the situation about 4 minutes after boot of the master.
 +
 
 +
'''Test the slave''' (as root on the slave)
 +
'''ntpq -p'''
 +
      remote          refid      st t when poll reach  delay  offset  jitter
 +
==============================================================================
 +
*192.168.1.10    LOCAL(0)        7 u  19  64  17    0.254  -20.070  1.857
 +
 
 +
The important things are the '*' in the first column, the stratum 'st' beeing less than 16 (stratum of master minus 1) and that the offset is acceptable (in ms).
 +
 
 +
===If offset is too big===
 +
 
 +
(regardless of stratum or '*') Update clock:
  
−
* initial
 
 
  root@smr19:/rhome/demo# '''ntpdate -u 192.168.1.10'''
 
  root@smr19:/rhome/demo# '''ntpdate -u 192.168.1.10'''
  
Line 13: Line 40:
 
The accuracy is typically better than 1 ms.
 
The accuracy is typically better than 1 ms.
  
−
The clocks will then drift - often between 0.1 to 1 ms each second - this (often) needs to be controlled:
+
NB! on stationary networks it is customary to use default gateway as NTP server, but at DTU this is no longer done (for security reasons). Instead use <code>ntp.ait.dtu.dk</code>.
 +
ntpdate -u ntp.ait.dtu.dk
  
−
* keep sync
+
===If stratum is 16 or no '*' in first column===
−
root@smr19:/rhome/demo# '''ntpd'''
+
  
−
ntpd will try to adjust the clock-speed to get an equal clock speed on the two clocks, without ever setting the clock. No steps backwards.
+
(and ntpd has been running for at least 4 minutes)
 +
Restart the ntpd daemon on the slave (as root):
  
−
'''The sync takes time'''
+
/etc/rc.d/ntpd restart (slackware)
 +
/etc/init.d/ntp restart (ubuntu)
  
−
When ntpd is started it will decide which server is the better, this takes typically about 4-8 minutes (requires about 4-8 samples spaced 64 seconds - the 'reach' field (octal) should have about 4 ones (017) as shown below - may reach 0377 (8 times '1')).
+
After another 4 minutes, the situation should be as shown above.  
  
−
'''Test progress'''
+
If not read next section
 +
 
 +
==Sync takes time==
 +
 
 +
When ntpd is started it will decide which server is the better, this takes typically about 4-8 minutes (requires about 4-8 samples spaced 64 seconds - the 'reach' field (octal) should have about 4 ones (017 octal) as shown below - may reach 0377 (8 times '1' in octal)).
 +
 
 +
===Test progress===
  
 
as root the status can be monitored by, e.g.:
 
as root the status can be monitored by, e.g.:
Line 42: Line 77:
 
The other source 192.168.1.10 shows 16 in the field 'st' (stratum - a measure of clock quality), ntpd will never try to synchronize to a source with stratum 16. See configuration of master clock source to ensure a low stratum.
 
The other source 192.168.1.10 shows 16 in the field 'st' (stratum - a measure of clock quality), ntpd will never try to synchronize to a source with stratum 16. See configuration of master clock source to ensure a low stratum.
  
−
'''Configuration of slave computer'''
+
==Configuration of slave computer==
  
 
The ntpd configuration is typically at  
 
The ntpd configuration is typically at  
 
  /etc/ntp.conf
 
  /etc/ntp.conf
  
−
On the computer that should be synchronized the configuration file could look like (some comments removed):
+
On the computer that should be synchronized the configuration file should add local time servers, like:
−
+
 
 
  # file /etc/ntp.conf
 
  # file /etc/ntp.conf
 
  #
 
  #
−
  server 192.168.1.10
+
  # pool ntp.ait.dtu.dk
−
  server pc89
+
  pool 192.168.0.210
−
#server kalman
+
 
  #
 
  #
−
  driftfile /etc/ntp/drift
+
  #driftfile /etc/ntp/drift
−
  multicastclient                # listen on default 224.0.1.1
+
  #multicastclient                # listen on default 224.0.1.1
−
  broadcastdelay  0.008
+
  #broadcastdelay  0.008
  
−
The ''server'' part shows in this case two clock sources, the 192.168.1.10 and the PC89.
+
After the change restart the NTP
  
−
The server pc89 is the one to use in this example, as the 192.168.1.10 is not available in this test setup. In the 'ntpq -p' above the 192.168.1.10 has never had a successful update.
+
sudo service ntp restart
  
 
The ''driftfile'' is the place where ntpd saves the adjustment to the local clock to maintain it at the same speed as the reference computers clock. NB! there is only one drift value, so if the computer has to keep sync with different computers, where these computers may drift at a a different rate, then ntpd will use 'very' long time to readjust to the new source. That is once is gets used to the errors in the PC89 clock source, and then is reconfigured to a sutuation where 192.168.1.10 is available and PC89 is not, then this will probably drift with a quite different value - and require maybe 8-20 hours to get back into sync.
 
The ''driftfile'' is the place where ntpd saves the adjustment to the local clock to maintain it at the same speed as the reference computers clock. NB! there is only one drift value, so if the computer has to keep sync with different computers, where these computers may drift at a a different rate, then ntpd will use 'very' long time to readjust to the new source. That is once is gets used to the errors in the PC89 clock source, and then is reconfigured to a sutuation where 192.168.1.10 is available and PC89 is not, then this will probably drift with a quite different value - and require maybe 8-20 hours to get back into sync.
Line 67: Line 101:
 
The restrict part and other parts of the configuration file are commented out.
 
The restrict part and other parts of the configuration file are commented out.
  
−
'''Start of slave'''
+
==Configuration of master computer==
−
 
+
−
In the startconfiguration of the slave computer the ntpd is usually started automatically - on a slagware distribution like this done in /etc/rc.d/rc.local
+
−
 
+
−
 
+
−
'''Configuration of master computer'''
+
  
 
The ntpd configuration is typically at  
 
The ntpd configuration is typically at  
Line 91: Line 120:
 
  ==============================================================================
 
  ==============================================================================
 
  *LOCAL(0)        .LOCL.          2 l  39  64  377    0.000    0.000  0.001
 
  *LOCAL(0)        .LOCL.          2 l  39  64  377    0.000    0.000  0.001
 +
 +
The users of this clock source should then obtain stratum level 3, as shown above.
 +
 +
==If it fails==
 +
 +
===no server suitable for synchronization found===
 +
 +
To test the time difference between two computers where ntpd is running, the following query can be used:
 +
 +
root@smr15:~# '''ntpdate -q pc89'''
 +
server 192.38.66.189, stratum 16, offset -4437.744951, delay 0.02577
 +
16 Jun 15:28:00 ntpdate[7235]: no server suitable for synchronization found
 +
 +
In this case the PC89 computer is 4437 seconds offset relative to this computer, shat is OK, but the ''no server suitable for synchronization found'' is bad. This means - in this case - that the server clock quality is too bad, stratum is 16, as the PC89 server is just restarted. Wait a few minutes and try again:
 +
 +
root@smr15:~# '''ntpdate -q pc89'''
 +
server 192.38.66.189, stratum 3, offset -4437.762400, delay 0.02577
 +
16 Jun 15:31:54 ntpdate[7237]: step time server 192.38.66.189 offset -4437.762400 sec
 +
 +
Now the PC89 clock source is OK (stratum 3 is less than 16 and thus OK), ready for a synchronization:
 +
 +
root@smr15:~# '''ntpdate -u pc89'''
 +
16 Jun 14:19:39 ntpdate[7238]: step time server 192.38.66.189 offset -4437.770068 sec
 +
 +
and now the query shows
 +
 +
root@smr15:~# '''ntpdate -q pc89'''
 +
server 192.38.66.189, stratum 3, offset -0.000240, delay 0.02577
 +
16 Jun 14:19:43 ntpdate[7239]: adjust time server 192.38.66.189 offset -0.000240 sec
 +
 +
===Right to access the server===
 +
 +
In the configuration file there may be some ''restrict'' lines, that can make the master unavailable as a clock source. In these  configuration all ''restrict'' lines are changed to comments.
 +
 +
Firewalls may further prohibit access (consult google for details)
 +
 +
--[[User:Jca|Jca]] 12:37, 16 June 2008 (UTC)

Latest revision as of 11:09, 5 August 2019

This is a short description on how to make two computers have the same clock using NTP (Network Time Protocol)

Contents

[edit] Packages

Install NTP and NTPDATE 

sudo apt-get install ntp ntpdate

[edit] Quick instructions

Assuming two computers are to be synchronized, one called master (192.168.0.210 (smr default)) and the other slave (192.168.0.20). If on one of the campus networks, use the network gateway as time server, here 10.59.8.1 is a fine stratum 4 server, and all other NTP servers are blocked on this network.

[edit] Are master and slave running OK

Test that master is running (as root on the master): 

ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*LOCAL(0)        .LOCL.           6 l   39   64  377    0.000    0.000   0.001

The important things are that there is a '*' at the start of the line and the 'st' (stratum) value is less than 15. This should be the situation about 4 minutes after boot of the master.

Test the slave (as root on the slave) 

ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*192.168.1.10    LOCAL(0)         7 u   19   64   17    0.254  -20.070   1.857

The important things are the '*' in the first column, the stratum 'st' beeing less than 16 (stratum of master minus 1) and that the offset is acceptable (in ms).

[edit] If offset is too big

(regardless of stratum or '*') Update clock: 

root@smr19:/rhome/demo# ntpdate -u 192.168.1.10

This will update the clock on this computer to the clock on the 192.168.1.10 computer (if the difference is above 0.5 second - else nothing is changed). The accuracy is typically better than 1 ms.

NB! on stationary networks it is customary to use default gateway as NTP server, but at DTU this is no longer done (for security reasons). Instead use ntp.ait.dtu.dk. 

ntpdate -u ntp.ait.dtu.dk

[edit] If stratum is 16 or no '*' in first column

(and ntpd has been running for at least 4 minutes) Restart the ntpd daemon on the slave (as root): 

/etc/rc.d/ntpd restart (slackware)
/etc/init.d/ntp restart (ubuntu)

After another 4 minutes, the situation should be as shown above.

If not read next section

[edit] Sync takes time

When ntpd is started it will decide which server is the better, this takes typically about 4-8 minutes (requires about 4-8 samples spaced 64 seconds - the 'reach' field (octal) should have about 4 ones (017 octal) as shown below - may reach 0377 (8 times '1' in octal)).

[edit] Test progress

as root the status can be monitored by, e.g.: 

root@smr19:/rhome/demo# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 192.168.1.10    .INIT.          16 u    -   64    0    0.000    0.000   0.000
*pc89.iau.dtu.dk LOCAL(0)         3 u   19   64   17    0.254  -20.070   1.857


This shows that the pc89 computer is the time source (the * as first character) the offset is -20.070 ms The last poll was performed 19 seconds ago and the poll interval is 64 seconds.

After a few hours the clock difference will reduce to about the magnitude of the jitter (in ms - here about 1.8 ms).

The other source 192.168.1.10 shows 16 in the field 'st' (stratum - a measure of clock quality), ntpd will never try to synchronize to a source with stratum 16. See configuration of master clock source to ensure a low stratum.

[edit] Configuration of slave computer

The ntpd configuration is typically at 

/etc/ntp.conf

On the computer that should be synchronized the configuration file should add local time servers, like: 

# file /etc/ntp.conf
#
# pool  ntp.ait.dtu.dk
pool 192.168.0.210
#
#driftfile /etc/ntp/drift
#multicastclient                 # listen on default 224.0.1.1
#broadcastdelay  0.008

After the change restart the NTP 

sudo service ntp restart

The driftfile is the place where ntpd saves the adjustment to the local clock to maintain it at the same speed as the reference computers clock. NB! there is only one drift value, so if the computer has to keep sync with different computers, where these computers may drift at a a different rate, then ntpd will use 'very' long time to readjust to the new source. That is once is gets used to the errors in the PC89 clock source, and then is reconfigured to a sutuation where 192.168.1.10 is available and PC89 is not, then this will probably drift with a quite different value - and require maybe 8-20 hours to get back into sync.

The restrict part and other parts of the configuration file are commented out.

[edit] Configuration of master computer

The ntpd configuration is typically at 

# /etc/ntp.conf on clock master
#
server 127.127.1.0 #local clock
fudge 127.127.1.0 stratum 2
#
driftfile  /etc/ntp/drift

This shows one server only, being the local real-time clock. The 'fudge' line tels ntpd to fake local clock as stratum 2 (a high quality) clock source.

The ntpd need to be started on this computer, and a ntpq -p would show something like: 

pc89 jca # ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*LOCAL(0)        .LOCL.           2 l   39   64  377    0.000    0.000   0.001

The users of this clock source should then obtain stratum level 3, as shown above.

[edit] If it fails

[edit] no server suitable for synchronization found

To test the time difference between two computers where ntpd is running, the following query can be used: 

root@smr15:~# ntpdate -q pc89
server 192.38.66.189, stratum 16, offset -4437.744951, delay 0.02577
16 Jun 15:28:00 ntpdate[7235]: no server suitable for synchronization found

In this case the PC89 computer is 4437 seconds offset relative to this computer, shat is OK, but the no server suitable for synchronization found is bad. This means - in this case - that the server clock quality is too bad, stratum is 16, as the PC89 server is just restarted. Wait a few minutes and try again: 

root@smr15:~# ntpdate -q pc89
server 192.38.66.189, stratum 3, offset -4437.762400, delay 0.02577
16 Jun 15:31:54 ntpdate[7237]: step time server 192.38.66.189 offset -4437.762400 sec

Now the PC89 clock source is OK (stratum 3 is less than 16 and thus OK), ready for a synchronization: 

root@smr15:~# ntpdate -u pc89
16 Jun 14:19:39 ntpdate[7238]: step time server 192.38.66.189 offset -4437.770068 sec

and now the query shows 

root@smr15:~# ntpdate -q pc89
server 192.38.66.189, stratum 3, offset -0.000240, delay 0.02577
16 Jun 14:19:43 ntpdate[7239]: adjust time server 192.38.66.189 offset -0.000240 sec

[edit] Right to access the server

In the configuration file there may be some restrict lines, that can make the master unavailable as a clock source. In these configuration all restrict lines are changed to comments.

Firewalls may further prohibit access (consult google for details)

--Jca 12:37, 16 June 2008 (UTC)

Retrieved from "http://rsewiki.elektro.dtu.dk/index.php?title=NTP_howto&oldid=3935"
Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox