NTP

From Omnia
Jump to navigation Jump to search

Subpages

Subpage Table of Contents


ntp

NTP homepage

NTP stands for Network Time Protocol, and it is an Internet protocol used to synchronize the clocks of computers to some time reference. NTP is an Internet standard protocol originally developed by Professor David L. Mills at the University of Delaware.

Summary

package

Name   : ntp
Version: 4.2.2p1

Summary: Synchronizes system time using the Network Time Protocol (NTP).

Description:
The Network Time Protocol (NTP) is used to synchronize a computer's
time with another reference time source. The ntp package contains
utilities and daemons that will synchronize your computer's time to
Coordinated Universal Time (UTC) via the NTP protocol and NTP servers.
The ntp package includes ntpdate (a program for retrieving the date
and time from remote machines via a network) and ntpd (a daemon which
continuously adjusts system time).

Install the ntp package if you need tools for keeping your system's
time synchronized via the NTP protocol.

Firewall

Allow UDP port 123

How does it work

How does it work

Whenever ntpd starts it checks its configuration file (/etc/ntp.conf) to determine syncronization sources, authentication options, monitoring options, access control and other operating options. It also checks the frequency file (/etc/ntp/drift) that contains the latest estimate of clock frequency error. If specified, it will also look for a file containing the authentication keys (/etc/ntp/keys).

Note that the path and/or name of these configuration files may vary in your system. Check the -c command line option.

Once the NTP daemon is up and running, it will operate by exchanging packets (time and sanity check exchanges) with its configured servers at poll intervals and its behaviour will depend on the delay between the local time and its reference servers. Basically, the process starts when the NTP client sends a packet containing its timestamp to a server. When the server receives such a packet, it will in turn store its own timestamp and a transmit timestamp into the packet and send it back to the client. When the client receives the packet it will log its receipt time in order to estimate the travelling time of the packet.

The packet exchange takes place until a NTP server is accepted as a synchronization source, which take about five minutes. The NTP daemon tries to adjust the clock in small steps and will continue until the client gets the accurate time. If the delay between both the server and client is big enough the daemon will terminate and you will need to adjust the time manually and start the daemon again.

Source: Time Synchronization with NTP

Basic features of NTP

  • NTP needs some reference clock that defines the true time to operate. All clocks are set towards that true time. (It will not just make all systems agree on some time, but will make them agree upon the true time as defined by some standard.)
  • NTP uses UTC as reference time
  • NTP is a fault-tolerant protocol that will automatically select the best of several available time sources to synchronize to. Multiple candidates can be combined to minimize the accumulated error. Temporarily or permanently insane time sources will be detected and avoided.
  • NTP is highly scalable: A synchronization network may consist of several reference clocks. Each node of such a network can exchange time information either bidirectional or unidirectional. Propagating time from one node to another forms a hierarchical graph with reference clocks at the top.
  • Having available several time sources, NTP can select the best candidates to build its estimate of the current time. The protocol is highly accurate, using a resolution of less than a nanosecond (about 2^-32 seconds). (The popular protocol used by rdate and defined in [RFC 868] only uses a resolution of one second).
  • Even when a network connection is temporarily unavailable, NTP can use measurements from the past to estimate current time and error.

Source: Time Synchronization with NTP

Initial Sync

The NTP client program ntpdate sets the system clock once. As real clocks drift, you need periodic corrections. Basically you can run ntpdate in a cron job hourly or daily, but your machine won't be an NTP server then.

Crontab entry to update the system clock once a day:

0 2 * * * /usr/sbin/ntpdate -s -b -p 8 -u 129.132.2.21
  • -b
Force the time to be stepped using the settimeofday() system call, rather than slewed (default) using the adjtime() system call. This option should be used when called from a startup file at boot time.
  • -p samples
Specify the number of samples to be acquired from each server as the integer samples, with values from 1 to 8 inclusive. The default is 4.
  • -s
Divert logging output from the standard output (default) to the system syslog facility. This is designed primarily for convenience of cron scripts.
  • -u
Direct ntpdate to use an unprivileged port or outgoing packets. This is most useful when behind a firewall that blocks incoming traffic to privileged ports, and you want to synchronise with hosts beyond the firewall. Note that the -d option always uses unprivileged ports.

Source: Time Synchronization with NTP

ntpd

Installation:

yum install ntp
chkconfig ntpd on
service ntpd restart

Allow local computers to update with this ntp server:

# /etc/ntp.conf:
restrict 10.10.10.0 mask 255.255.255.0 nomodify notrap

Normally run as the time sync daemon, but there are other things you can do with it:

You can force a time sync and then exit:

# service ntp stop   # ubuntu
service ntpd stop
ntpd -c /etc/ntp.conf -q
ntpd -c /etc/ntp.conf -q -g  # force update if there is large time difference

You can check the update status with:

ntpq -p

ntpq

Query Time Daemon

ntpq -p

Monitor NTP Sync:

watch 'ntpq -p'

The fields returned by ntpq have these meanings: [1]

  • remote: Hostname or IP address of the configured upstream NTP server.
  • refid: Identification of the time stream to which the NTP server is synchronized. If you receive a refid of " .INIT.", the host has not received a response from the configured NTP server.
  • st: Stratum is a value representing the hierarchy of the upstream NTP servers. Higher values indicate NTP servers further away from the root time source. Values are relative, and can be set manually by an NTP server.
  • t: Type of packet exchange used for NTP communication. Usually "u" for unicast UDP.
  • when: Quantity of seconds which have elapsed since the last attempted poll of the configured upstream NTP server.
  • poll: Interval in seconds according to which the host polls the configured NTP server.
  • reach: An 8-bit shift register in octal (base 8), with each bit representing success (1) or failure (0) in contacting the configured NTP server. A value of 377 is 11111111 (base 2), which indicates that every query was successful during the last 8 poll intervals.
  • delay: Roundtrip delay (in milliseconds) for communication between the configured NTP server and the host.
  • offset: The offset (in milliseconds) between the time on the configured NTP server and the host. A value closer to 0 is ideal.
  • jitter: The observed timing jitter or variation between clock pulses of time with the configured NTP server. A value closer to 0 is ideal.


---

* means current synced server
+ means backup synced server

The columns labels mean: [2] [3]

remote

The IP address or DNS name of the remote server

refid

An identification of the type of the reference clock.

st

The "stratum" or level of the server: for almost all systems, 2 is great. Your local system will have a higher number.

t

The type of service. Your setup will show "l" for local on your local system, or "u" for "unicast" for communicating with remote servers.

when

This is the number of seconds since the server was last heard from. After a couple of minutes of operation your server should start to report numeric values here.

poll

Current polling interval in seconds. When remote servers are responding, "when" should be no greater than "poll".

reach

This and the remaining fields are important indicators of the health of your local server, your remote servers, and their communication. This field is really a bit array indicating whether responses have been received to your local server's eight most recent requests. The value starts at 0. If your local server is receiving responses to all its requests, it will go to 1, then 3, then 7. The display is in octal, so 377 is the maximum value. Anything less indicates that either your local server recently started or some requests did not receive responses.

delay

Recent average roundtrip time in milliseconds from request to response.

offset

Estimated differential between your system clock and this time server's clock, in milliseconds. You may consider this the "bottom line" on the accuracy of your system clock. NTP can usually drive this down to the level of the jitter or less. If your clock gets ahead or behind by more than

jitter

A measure of the variability of the delays between request and receipt of a response, in milliseconds. High jitter tends to limit your server's ability to synchronize accurately.

Debug

To query the date, but not set it:

$ ntpdate -q [server]

To show the server debug details:

$ ntpdate -d [server]
...
server 216.119.202.155, port 123
stratum 3, precision -20, leap 00, trust 000

To show the stratum of a server:

$ ntptrace [server]
[server]: stratum 11, offset 0.000000, synch distance 0.948634

# to avoid tracing up the chain
$ ntptrace -n -m 1 [server]

To show the server's synchronizing servers:

$ ntpq -n -p 216.119.202.155
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*72.18.205.156   128.138.140.44   2 u   31   64  177   31.444  -11.538  69.185
+209.114.111.1   128.138.140.44   2 u   29   64  177   65.443  -35.255  84.801
+207.171.30.106  .PPS.            1 u   25   64  177   27.051  -24.358  73.947
 127.127.1.0     .LOCL.          10 l   24   64  177    0.000    0.000   0.001

To debug network ntpd traffic: [4]

tcpdump udp port 123

Access Restrictions

Access Restrictions:

Windows Synchronization

ref: [1]

net stop w32time
w32tm /config /syncfromflags:manual /manualpeerlist:"0.it.pool.ntp.org 1.it.pool.ntp.org 2.it.pool.ntp.org 3.it.pool.ntp.org"
net start w32time
w32tm /config /update
w32tm /resync /rediscover

Set time from the command line:

net time /set \\10.10.10.1 /y

Windows XP change time synchronization frequency:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient
"double click on 'SpecialPollInterval' in the right hand pane - default is 604800 (7 days) in seconds (Decimal). You can change the Decimal value to what ever you want. I have mine set to 86400 (24 Hours). You will need to restart your system for this change to take effect." [5]

weekly_time_update.reg - update 7 days (default):

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time\TimeProviders\NtpClient]
"SpecialPollInterval"=dword:00093a80

daily_time_update.reg - update daily:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time\TimeProviders\NtpClient]
"SpecialPollInterval"=dword:00015180

Windows 2000 (Win2K) uses a time service, known as Windows Time Synchronization Service (Win32Time), to ensure that all Win2K computers on your network use a common time. The W32Time Service is a fully compliant implementation of the Simple Network Time Protocol (SNTP) as detailed in IETF RFC 1769. SNTP uses UDP port 123 by default. If you want to synchronize your time server with an SNTP server on the Internet, make sure that port is available.

  • Select a NTP server, using
net time /setsntp:swisstime.ethz.ch
  • Start the W32time service with
net start W32Time

You can also set the start option of the Windows Time Synchronization Service (W32Time) to Automatic, so the service will start when Windows/2000 starts.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters

LocalNTP : REG_DWORD
# Used to start the SNTP server.
1 = always start the SNTP server

Type : REG_SZ
# Used to control how a computer synchronizes.
NTP = synchronize to manually configured source

Source: Time Synchronization with NTP

sntp

sntp -P no -r pool.ntp.org

rcntp ntptimeset
ntpd -q
service ntp start
chkconfig ntp on
ntpq -p

You can check the update status with:

ntpq -p

You can force a large time update with:

ntpd -c /etc/ntp.conf -q
ntpd -c /etc/ntp.conf -q -g  # force update if there is large time difference

SLES uses sntp instead of ntpdate. If you try calling ntpdate:

# ntpdate
       !!!!!!!!!!!!!!  WARNING !!!!!!!!!!!!!!!!!!

The ntpdate program is deprecated and should not be used any more.  To
quote the upstream ntp developers:

  "The functionality ntpdate offered is now provided by the ntpd daemon
  itself.  If you call ntpd with the command line option -q it will
  retrieve the current time and set it accordingly."

Please check the Network Time Protocol (NTP) daemon man page and
  http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate
for further information.

You can replace the ntpdate call with "rcntp ntptimeset" to achieve an
inital poll of the servers specified in /etc/ntp.conf.

The program /usr/sbin/sntp offers comparable functionality to ntpdate.
Specifically
  sntp -P no -r pool.ntp.org
is equivalent to
  ntpdate pool.ntp.org

For further details please refer to the man page of sntp.

SLES's ntpdate also calls sntp as such if any parameters are passed:

/usr/sbin/sntp -F -P no -r $1

Issues

startup synchronization failed

Failing Synchronizing on service start:

[root@mythtv etc]# service ntpd restart
Shutting down ntpd:                                        [  OK  ]
ntpd: Synchronizing with time server:                      [FAILED]
Starting ntpd:                                             [  OK  ]

This is caused by there being data within the /etc/ntp/step-tickers file. Simply clear out this file, and the error will happen no longer.

no server suitable for synchronization found

Error:

[root@ken ~]# ntpdate 10.10.0.2
11 Nov 13:33:45 ntpdate[6249]: no server suitable for synchronization found


Cause #1:

  • The server is not an NTP server

Solution #1:

  • Install NTP server or startup service


Cause #2:

  • Stratum is too high
[root@ken ~]# ntpdate -q 10.10.0.2
server 10.10.0.2, stratum 16, offset -0.036291, delay 0.02583
11 Nov 13:34:15 ntpdate[6252]: no server suitable for synchronization found

Solution #2:

  • There is a long delay (about 5 minutes) after the ntp server is started before it is confident that it is synced. Please wait for this time to elapse, and it will move to stratum 3.

keywords