NTP howto
This is a short description on how to get two computers have the same clock using NTP (Network Time Protocol)
Contents |
Introduction - 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.
- Both in one command
root@smr19:/rhome/demo# ntpd -g
This command should accept that the initial clock difference is high - but requires that the source is available when the command is issued. This may not be the case if the master clock source is booted at the same time as this computer.
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')).
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.
Configuration of slave computer
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):
# file /etc/ntp.conf # 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.
The restrict part and other parts of the configuration file are commented out.
Start of slave
In the startconfiguration of the slave computer the ntpd is usually started automatically - on a slagware distribution like this:
??? - /etc/rc.d/rc.local? - make a copy of relevant lines
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.
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)
