NTP howto: Difference between revisions

From Rsewiki
No edit summary
No edit summary
Line 3: Line 3:
'''NTPD how'''
'''NTPD how'''


NTPD - ntp deamon (ntpd) - must run on both (all) computers that needs to be synchronised.
NTPD - ntp demon (ntpd) - must run on both (all) computers that needs to be synchronized.


The sync is - should - be obtained in two steps:
The sync is - should - be obtained in two steps:


* initial (as root)
* initial
  ntpdate -u 192.168.1.10
  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).
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).
Line 15: Line 15:
The clocks will then drift - often between 0.1 to 1 ms each second - this (often) needs to be controlled:
The clocks will then drift - often between 0.1 to 1 ms each second - this (often) needs to be controlled:


* keep sync (as root)
* keep sync
  ntpd
  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.
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.
Line 22: Line 22:
'''The sync takes time'''
'''The sync takes time'''


When ntpd is started it will decide which server is the better, this takes typically about 8 minutes (requires about 8 samples spaced 64 seconds).
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')).


'''Test progress'''
'''Test progress'''
Line 29: Line 29:


  root@smr19:/rhome/demo# ntpq -p
  root@smr19:/rhome/demo# ntpq -p
    remote          refid      st t when poll reach  delay  offset  jitter
      remote          refid      st t when poll reach  delay  offset  jitter
  ==============================================================================
  ==============================================================================
   LOCAL(0)        .LOCL.          16 l   3   64 377   0.000    0.000  0.001
   192.168.1.10    .INIT.          16 u   -   64   0   0.000    0.000  0.000
  *pc89.iau.dtu.dk LOCAL(0)        3 u  58   64 377   0.257 -24.219   0.423
  *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 -24.219 ms
The last poll was performed 58 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 miliseconds).
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).


'''Configuration'''
'''Configuration'''
Line 43: Line 44:
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):
server  192.168.1.10
server pc89
#server kalman
#
driftfile /etc/ntp/drift
multicastclient                # listen on default 224.0.1.1
broadcastdelay  0.008
The server part shows in this case two clock sources, the 192.168.1.10 and the PC89.
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.
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.

Revision as of 11:07, 13 June 2008

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

NTPD how

NTPD - ntp demon (ntpd) - must run on both (all) computers that needs to be synchronized.

The sync is - should - be obtained in two steps:

  • initial
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.

The clocks will then drift - often between 0.1 to 1 ms each second - this (often) needs to be controlled:

  • keep sync
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.

The 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) as shown below - may reach 0377 (8 times '1')).

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).

Configuration

The ntpd configuration is typically at

/etc/ntp.conf

On the computer that should be synchronized the configuration file could look like (some comments removed):

server  192.168.1.10
server pc89
#server kalman
#
driftfile /etc/ntp/drift
multicastclient                 # listen on default 224.0.1.1
broadcastdelay  0.008

The server part shows in this case two clock sources, the 192.168.1.10 and the PC89.

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.

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.