Shortcut Menu

Skip

Main Navigation

Choose your language

You are here:

ActiveXperts.com > Network Component > Tutorials > Introduction to NTP

ActiveXperts Network Component Add network capabilities to any Windows or .NET application

Quicklinks


Introduction to NTP

It is becoming increasingly important to have accurate time synchronisation across computer networks. Reasons for this include the need for time-stamping in security systems, reliable log-scanning to analyse security breaches, and the maintenance of consistency in distributed file systems. A system running NTP software requests time-related information as a client of certain other systems running NTP, which enables it to set its own clock accurately, allowing for variation of quality in the neighbouring systems and network delays that are involved. In turn the system may pass on information as a server to other NTP machines. The true time is fed in at the bottom level of the hierarchical mesh of communicating systems via radio clocks that receive broadcast time signals from specially dedicated satellite navigation systems. The number of steps that a particular system lies from a primary time source is known as its "stratum". A radio-clock has stratum-0. The computer directly linked to it has stratum-1. Although having a low stratum is good, having an excessive number of clients on one server may seriously degrade the system. It is generally best to limit a machine to under 100 clients, unless its primary purpose is time provision, which is not usually the case. Intermediate servers are therefore used, and the majority of end-user systems will run at stratum-3,4 or 5. NTP is designed to be highly fault-tolerant. For this purpose it is usually best for a machine to be connected to several different servers with independent paths back to a primary time source. It is also usual for machines to "peer" with others at the same stratum to increase overall resillience of the protocol. OUCS run four stratum-2 time servers, each of which is connected to five out of ten independent stratum-1 servers situated in the UK, France and Germany. Each stratum-2 server is also peered with the other three. It is proposed that access to these machines will provide a service to at least two machines from each department, which will operate at stratum-3 and will be free to peer with those from other departments. End user machines will run at stratum-4, taking their time information from their designated departmental servers.

Hierarchical client-server model

NTP is organised in a hierarchical client-server model. In the top of this hierarchy there are a small number of machines known as reference clocks. A reference clock is known as stratum 0 and is typically a cesium clock or a Global Positioning System (GPS) that receives time from satellites. Attached to these machines there are the so-called stratum 1 servers (that is, stratum 0 clients), which are the top level time servers available to the Internet, that is, they are the best NTP servers available. Note: in the NTP lingo measure for synchronization distance is termed as stratum: the number of steps that a system lies from a primary time source. Following this hierarchy, the next level in the structure are the stratum 2 servers which in turn are the clients for stratum 1 servers. The lowest level of the hierarchy is made up by stratum 16 servers. Generally speaking, every server syncronized with a stratum n server is termed as being at stratum n+1 level. So, there are a few stratum 1 servers which are referenced by stratum 2 servers, wich in turn are refenced by stratum 3 servers, which are referenced by stratum 4 and so on. NTP servers operating in the same stratum may be associated with others in a peer to peer basis, so they may decide who has the higher quality of time and then can synchronise to the most accurate. In addition to the client-server model and the peer to peer model, a server may broadcast time to a broadcast or multicast IP addresses and clients may be configured to synchronise to these broadcast time signals. So, at this point we know that NTP clients can operate with NTP servers in three ways:

  • In a client-server basis;
  • In a peer to peer mode;
  • Sending the time using broadcast/multicast.

How does NTP 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. Sample ntp.conf configuration file

     server 134.214.100.6
     server swisstime.ee.ethz.ch

     peer 192.168.100.125
     peer 192.168.100.126
     peer 192.168.100.127

     driftfile /etc/ntp/drift
     #multicastclient  # listen on default 224.0.1.1
     #broadcastdelay  0.008

     authenticate no

     #keys           /etc/ntp/keys
     #trustedkey     65535
     #requestkey     65535
     #controlkey     65535

     # by default ignore all ntp packets
     restrict 0.0.0.0 mask 0.0.0.0 ignore

     # allow localhost
     restrict 127.0.0.1 mask 255.255.255.255

     # accept packets from...
     restrict 192.168.100.125 mask 255.255.255.255
     restrict 192.168.100.126 mask 255.255.255.255
     restrict 192.168.100.127 mask 255.255.255.255

NTP Client on a Unix Workstation

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

Options:

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

NTP Server on a Unix Workstation

First of all you have to download the NTP sources from www.ntp.org. On RedHat Linux 7.0 / 7.1 the NTP server ntpd is already included in the distribution. The NTP server ntpd will learn and remember the clock drift and it will correct it autonomously, even if there is no reachable server. Therefore large clock steps can be avoided while the machine is synchronized to some reference clock. In addition ntpd will maintain error estimates and statistics, and finally it can offer NTP service for other machines.

  • Look at the Startup Script in /etc/rc.d/init.d/ntpd

        start() {
          # Adjust time to make life easy for ntpd
          if [ -f /etc/ntp/step-tickers ]; then
            echo -n $"Synchronizing with time server: "
            /usr/sbin/ntpdate -s -b -p 8 -u \
            `/bin/sed -e 's/#.*//' /etc/ntp/step-tickers`
            success
            echo
          fi
          # Start daemons.
          echo -n $"Starting $prog: "
          daemon ntpd
          RETVAL=$?
          echo
          [ $RETVAL -eq 0 ] && touch /var/lock/subsys/ntpd
          return $RETVAL
        }
        
  • Insert swisstime.ethz.ch or more NTP Servers to /etc/ntp/step-tickers

    129.132.2.21

  • Edit the configuration file /etc/ntp.conf:

        server 127.127.1.0  # local clock
        server 129.132.2.21 # swisstime.ethz.ch (stratum 1)
        driftfile /etc/ntp/drift
        multicastclient     # listen on default 224.0.1.1
        broadcastdelay 0.008
        
  • Start NTP Server and check /var/log/messages:

    # /etc/rc.d/init.d/ntpd start


NTP Client on a Windows 2000 workstation or server

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.

RFC 1305 - THE NTP PROTOCOL

To view the RFC 1305 Specification, click here.