There are many services in operating systems, normal functioning which depends on the accuracy of the system clock. If the exact time is not set on the server, this can cause various problems.

For example, in local network it is required that the clocks of machines sharing files be synchronized - otherwise it will not be possible to correctly set the modification time of files. This, in turn, can cause version conflicts or important data to be overwritten.

If the server does not have an exact time set, there will be problems with Cron jobs - it is not clear when they will run. It will be very difficult to analyze the system event logs to diagnose the causes of failures and malfunctions ...

You can go on for a long time...

To avoid all the described problems, you need to set up synchronization of the system clock. Linux uses NTP (Network Time Protocol) for this. In this article, we will talk in detail about how to install and configure NTP on the server. Let's start with a little theoretical introduction.

How does the NTP protocol work?

The NTP protocol is based on a hierarchical structure of exact time servers, in which different levels (English strata) are distinguished. Level 0 refers to the reference clock (atomic clock or GPS clock). At level zero, NTP servers don't work.

Tier 1 NTP servers, which are sources for Tier 2 servers, synchronize with the reference clock. Tier 2 servers synchronize with Tier 1 servers, but can also synchronize with each other. Tier 3 and below servers work the same way. In total, up to 256 levels are supported.

The hierarchical structure of the NTP protocol is characterized by fault tolerance and redundancy. In case of connection failures with upstream servers backup servers take over the synchronization process. Redundancy ensures that NTP servers are always available. By synchronizing with multiple servers, NTP uses data from all sources to calculate the most accurate time.

Installing and configuring an NTP server

The most famous and widespread software tool for time synchronization is the ntpd daemon. Depending on the settings specified in configuration file(this will be discussed below), it can act both as a server and as a client (that is, it can both receive time from remote hosts and distribute it to other hosts). Below we will describe in detail how to install and configure this daemon in OC Ubuntu.

Installation

The NTP program is included in the distributions of most modern Linux systems and is installed using a standard package manager:

$ sudo apt-get install ntp

Setting

After the installation is completed, open in text editor/etc/ntp.conf file. It stores all program settings. Let's consider them in more detail.

Logging options

The first line of the config file looks like this:

Driftfile /var/lib/ntp/ntp.drift

It specifies a file for storing information about the frequency of the time offset. This file stores the value resulting from previous time adjustments. If external NTP servers become unavailable for one reason or another, the value will be taken from it.

Logfile /var/log/ntp.log

List of servers for synchronization

The configuration file specifies the list of NTP servers with which synchronization will be performed. By default it looks like this:

Server 0.ubuntu.pool.ntp.org server 1.ubuntu.pool.ntp.org server 2.ubuntu.pool.ntp.org server 3.ubuntu.pool.ntp.org

Each line means a group of servers that will report the correct time to our server. You can improve synchronization accuracy using the iburst option (it indicates that not one, but several packets should be sent to the server for synchronization):

Server 0.ubuntu.pool.ntp.org iburst server 1.ubuntu.pool.ntp.org iburst server 2.ubuntu.pool.ntp.org iburst server 3.ubuntu.pool.ntp.org iburst

You can also specify your preferred server with the prefer option:

Server 0.ubuntu.pool.ntp.org iburst prefer

NTP servers are scattered around the world (here, for example, is a list of available public NTP servers). To ensure a more accurate setting of the system clock, it is recommended to synchronize only with ntp servers of the region in which our server is geographically located. To do this, in the /etc/ntp.conf configuration file, specify the regional subdomain for pool.ntp.org in the server addresses:

  • Asia - asia.pool.ntp.org;
  • Europe - europe.pool.ntp org;
  • Africa — africa.pool.ntp.org;
  • North America - north-america.pool.ntp.org;
  • South America - south-america.pool.ntp.org;
  • Oceania - oceania.pool.ntp.org.

You can also specify subdomains for individual countries (for more details, see ). There is also a subdomain for Russia - ru.pool.ntp.org

Backup time server

An NTP server that is disconnected from the Internet for any reason may transmit its system clock data for synchronization. To do this, add the following line to the configuration file:

Server 127.127.1.0

Restrictions

Recently, cases of using NTP servers to amplify traffic in DDoS attacks have become more frequent (for more details, see, for example,). To prevent our server from becoming a victim of abuse, it would be useful to set access restrictions for external clients. By default, the following restrictions are set in the /etc/ntp.conf file:

Restrict −4 default kod notrap nomodify nopeer noquery restrict −6 default kod notrap nomodify nopeer noquery

The nomodify, notrap, nopeer, and noquery options prevent third-party clients from modifying anything on the server. The kod parameter (this abbreviation means kiss of death - "kiss of death") provides additional protection: A client that sends too many requests will first receive a so-called kod packet (denial of service warning) and then be disconnected from the server.

In order for machines from the local network to synchronize with the NTP server, add the following line to the configuration file:

Restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap

For the local host, you can set access to the NTP server without restrictions:

Restrict 127.127.1.0

Synchronization check

After all the necessary changes have been made to the configuration file and saved, restart the NTP server:

$ service restart ntp

Then run the following command:

$ ntpq -pn

Its output will be presented in the form of a table:

Remote refid st t when poll reach delay offset jitter ======================================= ===================================== *62.76.96.4 130.173.91.58 2 u 207 256 37 10.985 -215.79 256.992 +85.21.78.91 89.175.22.41 2 U 193 256 37 32.623 -207.70 259.121 +31.131.249.27 89.175.22.41 2 U 19621 -216.90 257.037 +85.21.11.11111.11.111111.11.1111111111.1AND 207.41 259.863 +91.189.94.4 193.79.237.14 2 u 192 256 37 50.573 -206.62 259.542

The table indicates the following parameters:

  • remote — exact time server address (this column displays servers from the list in the configuration file);
  • refid - upstream server (the one from which the server from the previous columns receives synchronization);
  • st — level (stratum) of the server;
  • t — peer type (u- unicast, m- multicast);
  • when is the time of the last synchronization;
  • poll is the time in seconds it takes for the NTP daemon to synchronize with the peer.
  • reach — server availability status; after eight successful synchronization attempts, the value of this parameter becomes equal to 377;
  • delay — response delay time from the server;
  • offset is the time difference between our server and the synchronization server; a positive value of this parameter means that our clock is fast, a negative value means that it is behind;
  • jitter is the time offset on the remote server.

The following characters can be specified to the left of the server address:

  • * server selected for synchronization;
  • + a server suitable for updating (with which you can synchronize);
  • — it is not recommended to synchronize with the server;
  • x server is unavailable.

You can check if a server from the list is suitable for synchronization using the command:

Ntpdate -q server хх.ххх.ххх.ххх, stratum 2, offset −0.127936, delay 0.02600 7 Jul 14:30:23 ntpdate: adjust time server хх.ххх.ххх.ххх offset −0.127936 sec

From the above output, it can be seen that the server is suitable for synchronization, its level is 2, the offset is 0.127936 ms, and the delay is 0.026 ms.

You can also find out how the synchronization went (successfully or with errors) from the logs:

7 Jul 15:17:17 ntpd: synchronized to 91.198.10.4, stratum=2 7 Jul 15:17:17 ntpd: kernel time sync disabled 0041 7 Jul 15:17:21 ntpd: kernel time sync enabled 0001

Setting the local date and time

The ntpdate command can be used to set the local date and time on the server by sending a request to the NTP server.

Introduction.

The Linux system, like most other modern operating systems, actually has two clocks. The first clock is a hardware clock, sometimes called the Real Time Clock, abbreviated (RTC), or BIOS clock, usually associated with an oscillating quartz crystal, which has an accuracy of up to several seconds per day. The accuracy depends on various fluctuations, such as ambient temperature. The second clock is an internal software clock that runs continuously, including during breaks in the system. They are subject to fluctuations associated with high system load and interrupt latency. However, the system usually reads the hardware clock at boot and then uses the system clock. The date command does not set the hardware clock, but the system clock.

If NTP is used, you can set the hardware clock during the first installation of the system and never worry about it again.

The real time clock (RTC) chip used on motherboards, is not particularly accurate, and usually lags or gets ahead by a certain amount of time each day.

You can synchronize the hardware clock with the system clock using the hwclock command with the -w or --systohc option, and synchronize the system clock with the hardware clock with the hwclock command with the -s or --hctosys option.

Setting.

First, in the /etc/ntp.conf file, add the line:

The time will be synchronized from the specified server. If the first one is not available, the next ones in the list are taken. First prescribed local server NTP.

The next moment, sets the local or universal time to be used.

#cat /etc//etc/sysconfig/clock

We don't have:

We rule ZONE - on "Europe/Moscow"

We get:

UTC=true system clock does not use universal time representation

ARC=true The normal UNIX epoch is used.

The timezone under Linux is set via a symbolic link from /etc/localtime to a file in the /usr/lib/zoneinfo (or /usr/share/zoneinfo) directory, which indicates which timezone you are in.

Picture. Contents of /usr/share/zoneinfo

We execute commands.

rm -rf /etc/localtime

ln -s /usr/share/zoneinfo/Europe/Moscow /etc/localtime

Everything is working!

If the ntpd daemon is running, the following message is displayed when attempting to synchronize with the ntp server.

This command shows which servers to connect to.

Addition:

Setting the hardware clock

To set the hardware clock, first set the system time and then the hardware time using the program "/sbin/clock -w" (or "/sbin/clock -wu" if using universal time). To find out the hardware time, run clock without parameters. If the hardware clock is set to local time and you want to see the world time type "/sbin/clock -u"

Setting the system clock

To set the system clock in Linux, use the date program. For example, setting the current time (system!) and date to July 31, 23:16, type "date 07312316" (note that the time is given in 24-hour notation) If you want to change the year, type "date 073123161998". To set the seconds, dial "date 07312316.30" or "date 073123161998.30". To get the system time, run date with no arguments.

Sources used.

Sometimes the clock on an Ubuntu computer gets off, slow, or fast. Although this situation is not critical, it is very unpleasant and can have disastrous consequences, ranging from confusion in the logs due to the ambiguity of time to being late for a meeting because you trusted the wrong hours. Also, the exact time is important for the correct operation of some programs, such as Tor anonymizer.

Fortunately, this does not happen so often and is usually associated with such non-standard actions as loading operating systems using different algorithms for storing machine time or resetting BIOS memory. But this does not mean that you do not need to do anything, you can set up local time synchronization via the Internet, this is quite still a handy thing if you often knock down the clock and you are too lazy to set it up every time. Ubuntu uses the NTP service and the ntpd daemon to do this. It is about them that will be discussed in this article.

First, a little about how to see the time from the terminal in Ubuntu. To find out the current time, run the command:

To view data in UTC format, type:

Let's find out how much the time of our Ubuntu lags behind the reference:

sudo ntpdate -q ntp.ubuntu.com

Further, there is a lot of theory, if you came here only for installation instructions, feel free to scroll down. UTC stands for Coordinated Universal Time, that is, Coordinated Universal Time. This GMT standard is the same for the whole world, and it is in this form that the system time is stored in Linux, including Ubuntu, and the time zone correction is already added locally for each user. This is where the reason for time failures lies. using Windows and Unix.

As I said, Ubuntu stores the time in UTC format, while Windows uses the local format for this already with the addition of the time zone. Each time the computer is turned off or restarted, the operating system saves its timer value in the BIOS timer, and reads it from there when it boots up.

And it turns out that Microsoft's OS saves local time, and Ubuntu thinks it's UTC... do you already understand what's going on? That's right, the more such reboots, the more the time will differ from the real one. But I've already gone off topic. How to set up synchronization algorithms in both systems, I will not tell here, my goal today is time synchronization in Ubuntu.

Installing NTP in Ubuntu

The ntpdate time synchronization utility comes with ubuntu, and is automatically started at startup. If you want to sync time to now run in terminal:

ntpdate -s ntp.ubuntu.com

The ntpd service is not included in the standard package, its task is to constantly monitor the system clock and correct any deviations. To install ntpd, type:

sudo apt-get install ntp

To start the daemon, type:

sudo service ntp start

And to add to autoload:

sudo rc-update add ntp defaults

You can configure the servers with which our Ubuntu will check in the /etc/ntp.conf file. The entry format is server address, for example the standard configuration is:

# Use servers from the NTP Pool Project. Approved by Ubuntu Technical Board
# on 2011-02-08 (LP: #104525). See http://www.pool.ntp.org/join.html for
# more information.
server0.ubuntu.pool.ntp.org
server1.ubuntu.pool.ntp.org
server2.ubuntu.pool.ntp.org
server3.ubuntu.pool.ntp.org

After editing the configuration, don't forget to restart the service:

sudo service ntp restart

Solution of problems

The synchronization service uses port 123 to connect to the server, so if you use a firewall, access to these ports may be blocked, you must allow access by adding the following rules:

iptables -A output -p udp -s 192.168.1.1 --sport 1024:65535 -d 0/0 --dport 123 -m state --state NEW,ESTABLISHED -j ACCEPT

iptables -A input -p udp -s 0/0 --sport 123 -d 192.168.1.1 --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT

Now the clock on your computer will always run correctly.


Time synchronization is an important task, although not many people have thought about it. Well, what's wrong with running away on the server time? Did you know that many clock issues affect protocols related to cryptography? For this reason, in Active Directory clock differences greater than 5 minutes will result in Kerberos authentication problems.

hourly levels. Strata.

To understand an NTP device, you should know about the concept strata or stratum. Authoritative time sources such as GPS satellites, cesium atomic clocks, WWVB radio waves - all this stratum 0. They are authoritative on the grounds that they have some way of maintaining highly accurate timekeeping. You can, of course, use ordinary quartz watches, but knowing that it is easy to lose 15 seconds with them in a month, it is better not to use them as a measure of time. Stratum 0 this is when a second is not lost in 300,000 years!

Computers that directly (not over the network!) take time from stratum 0- this is stratum 1. Since there are always delays due to signal transmission and costs for setting time, computers stratum 1 not as accurate as stratum 0, but in real life the difference reaches a couple of microseconds (1 µs = 10 -6 s), which is quite an acceptable deviation.

The next level of computers taking time over the network from stratum 1- it's... drumroll... intrigue... stratum 2! Again, due to various delays (network for sure), stratum 2 a bit behind stratum 1 and certainly from stratum 0. In practice, this difference ranges from a few microseconds (1 µs = 10 -6 s) to a few milliseconds (1 ms = 10 -3 s). Many want to sync with the layer no further stratum 2.

As is clear from the diagram, stratum 4 takes time from superiors stratum 3. stratum 5 at stratum 4 and so on. stratum 16 is considered the lowest layer and time is considered there out of sync.

To synchronize the time using the NTP protocol, you must first manually set your time. More than 1000 seconds difference between your exact time and your watch is not allowed. If the time server you are using lies for more than 1000 milliseconds (1 second), then it will be delisted and others will be used instead. This mechanism allows you to filter out bad sources of time.

Time client.

In the /etc/ntp.conf file, the Server lines are important for the client. There can be several - up to 10 pieces!

How much to add? Keep in mind:

  • If you have only one server (one server line), then if this server starts lying, then you will blindly follow it. If his time runs out by 5 seconds and you run after him.
  • If 2 servers are added (2 server lines), then NTP will mark both of them as false tickers. If one of them lies, then NTP cannot understand who is lying, since there is no quorum.
  • If 3 or more time servers are added, then one liar can be calculated false tickers. If there are 5 or 6 time servers, then you can find 2 liars false tickers. If there are 7 or 8 servers, then 3 false tickers. If there are 9 and 10 servers, then 4 false tickers.

NTP Pool project.

There is such a project NTP Pool at the address of which pool.ntp.org/zone/ru/ you can find time servers recommended for Russian users.

server0.ru.pool.ntp.org
server1.ru.pool.ntp.org
server2.ru.pool.ntp.org
server3.ru.pool.ntp.org

Operating systems such as Debian and Ubuntu offer users their own time servers.

server0.debian.pool.ntp.org
server1.debian.pool.ntp.org
server2.debian.pool.ntp.org
server3.debian.pool.ntp.org

server0.ubuntu.pool.ntp.org
server1.ubuntu.pool.ntp.org
server2.ubuntu.pool.ntp.org
server3.ubuntu.pool.ntp.org

If you call ntpq -pn on your Linux machine that uses NTP

Remote refid st t when poll reach delay offset jitter ======================================= ===================================== +93.180.6.3 77.37.134.150 2 u 62 1024 377 53.658 -0.877 1.174 +85.21.78.23 193.190.230.65 2 u 1027 1024 377 54.651 0.167 1.531 *62.173.138.130 89.109.251.24 2 u 940 1024 377 52.796 -0.143 1.001 +91.206.16.3 194.190.168.1 2 u 258 1024 377 93.882 -0.680 2.196 -91.189.94.4 193.79.237.14 2 u 596 1024 377 100.219 1.562 1.482

What do the column names say?

  • remote- remote servers with which you synchronize time.
  • refid- superior stratum for this server.
  • st- stratum level. From 0 (not available to us) to 16 (not desirable for us). Ideal - 2.
  • t- connection type. " u"- unicast or manycast, " b"-broadcast or multicast, " l" local reference clock, " s" - symmetrical node, " A" - manycast server, " B"-broadcast server, " M"- multicast server.
  • when- the time when the server last answered us. The parameter displays the number in seconds, but may be in minutes if the number is m or hours if h.
  • poll- polling frequency. Minimum 16 seconds, maximum 32 hours. The number must be 2 n . Usually in this parameter there is either 64 seconds or 1024.
  • reach- An 8 bit octet indicating the status of communication with the remote time server: success or failure. If the bits are set, then success, otherwise, failure. The value 377 is binary 0000 0000 1111 1111.
  • delay- the value in milliseconds shows the time between sending and receiving a response (round trip time - RTT).
  • offset- offset in milliseconds between you and the time servers. Can be positive or negative number.
  • jitter- an absolute value in milliseconds indicating the standard deviation of your offset.

Before the IP address of the NTP server there is a symbol - this is tally code. Kinds tally code:

  • " " - discarded as invalid. For example, there is no connection with him or he is offline, he is too high in rank and does not serve people like you.
  • "x"- discarded by the "intersection" algorithm. The intersection algorithm prepares a list of candidate partners that can become synchronization sources and calculates a confidence interval for each of them.
  • "." - dropped due to table overflow.
  • "-" - discarded by the cluster algorithm. The clustering algorithm sorts the list of candidates by layer codes and synchronization distances.
  • "+" - the server is enabled by the "combine algorithm". This server is a great candidate if your current time server starts to fail you.
  • "#" - the server is a great alternative time server. The server with # can only be seen if you have more than 10 server entries in /etc/ntp.conf
  • "*" - current time server. Its readings are used to synchronize your clocks.
  • "o"- Pulse per second (PPS) server. This usually means that this time server uses time sources such as GPS satellites and other precise time signals. If drawn about, then other types of tally code will no longer be displayed.

In field refid can be the following values:

  • IP address - address of the remote time server.
  • .ACST.- NTP manycast server.
  • .ACTS.-Automated Computer Time Service from the American National Institute of Standards and Technology.
  • .AUTH.- authentication error.
  • .AUTO. - error in Autokey sequences.
  • .BCST.- NTP broadcast server.
  • .CHU.- Shortwave radio receiver from CHU station in Ottawa, Ontario, Canada.
  • .CRYPT. - Autokey protocol error.
  • .DCFx.- LF radio receiver from station DCF77 in Mainflingen, Germany.
  • .DENY.- Access denied.
  • .GAL.-European Galileo satellite receiver.
  • .GOES.- American Geostationary Operational Environmental Satellite receiver.
  • .GPS.- American Global Positioning System receiver.
  • .HBG.- LF radio receiver from HBG station in Prangins, Switzerland.
  • .INIT.- Peer association initialized.
  • .IRIG.- Inter Range Instrumentation Group time code.
  • .JJY.- LF radio receiver from JJY Station at Mount Otakadoya, near Fukushima or Mount Hagane on Kyushu Island, Japan.
  • .LFx.- Regular LF radio receiver.
  • .LOCL. - local clock of the host.
  • .LORC.- LF radio receiver from Long Range Navigation (LORAN-C).
  • .MCST.- NTP multicast server.
  • .MSF.- Anthorn Radio Station near Anthorn, Cumbria.
  • .NIST.-American National Institute of Standards and Technology.
  • .PPS.- clock Pulse per second.
  • .PTB.- Physikalisch-Technische Bundesanstalt from Brunswick and Berlin, Germany.
  • .RATE.- NTP poll threshold exceeded.
  • .STEP.- change the NTP step. Bias offset less than 1000 milliseconds, but more than 125 milliseconds.
  • .TDF.- LF radio receiver from TéléDiffusion de France station in Allouis, France.
  • .TIME.- NTP association timeout.
  • .USNO.- United States Naval Observatory.
  • .WWV.- HF radio receiver from the WWV station at Fort Collins, Colorado, United States.
  • .WWVB.- LF radio receiver from the WWVB station at Fort Collins, Colorado, United States.
  • .WWVH.- HF radio receiver from the WWVH station at Kekaha, on the island of Kauai in Hawaii, United States.

First, get rid of the thought of how to get time from stratum 1, they say they are closest to the exact time. They are closer to the most accurate time on the planet, only they themselves are overloaded and have high RTT delays for regular servers. Better find a normal one stratum 2 and don't worry about it. Do not forget that we are talking about microseconds and milliseconds, which in ordinary life is quite enough.

Second, remember that connecting to the nearest time server is not always ideal. More important is not territorial proximity, but the level of stratum. The NTP Pool project publishes a list of servers only at the level stratum 1 and stratum 2 and it is better to take up to 10 time servers from this list, which will be just fine.

Thirdly, if you are a simple home client user, then the servers recommended to you in your operating system will be an ideal option that does not require extra gestures.

For large offices, the best option would be to set up your own time server for work computers. This server will receive the exact time from Internet time servers and provide it local computers. On Debian and Ubuntu servers, just uncomment the line

Restrict 192.168.0.0 mask 255.255.0.0 nomodify notrap

in the ntpd daemon configuration file - /etc/ntp.conf

Users from the 192.168/16 network will be able to get the most accurate clock from your server. For internal servers on Linux-based, which are not time servers and do their own thing, instead of running the ntpd daemon in client mode, it is enough to specify in the /etc/cron.daily/syncntpd file. It is recommended that you read the differences between ntpdate and ntp and decide for yourself.
#!/bin/sh
/usr/sbin/ntpdate your server's IP address > /dev/null 2>&1
exit 0

and once a day, thanks to the ntpdate command, time synchronization will be performed. To avoid misunderstandings, do not be lazy before implementing a time server and synchronizing everything and everything via the NTP protocol - manually set the correct time on all servers and workstations available to you. If your unsynchronized time is too different from the correct one, then you can start a lot of unnecessary problems in the beginning.

Fourthly, NTP is not related in any way in which country and what time zones are used and how the transition to summer and winter time occurs and whether such a transition is made in this country. This responsibility lies with the operating system, which you need to update if there are changes in watchmaking in the country. On Debian and Ubuntu systems, the tzdata package is responsible for this and should be up to date.

Fifth, it is better not to raise your NTP server on a highly loaded system.

Network Time Protocol is a network protocol for synchronizing a computer's internal clock using variable latency networks based on packet switching.

While traditionally NTP uses UDP for its operation, it is also capable of operating over TCP. The NTP system is extremely robust to changes in media latency.

Time is represented in the NTP system as a 64-bit number consisting of a 32-bit second counter and a 32-bit fractional second counter, allowing time to be transmitted in the range of 2-32 seconds, with a theoretical accuracy of 2-32 seconds. Since the time scale in NTP repeats every 232 seconds (136 years), the recipient must at least roughly know the current time (with an accuracy of 68 years). Also keep in mind that the time is measured from midnight on January 1, 1900, and not from 1970, so almost 70 years (including leap years) must be subtracted from the NTP time in order to correctly align the time with Windows or Unix systems.

How it works

NTP servers operate in a hierarchical network, each level of the hierarchy is called a tier (stratum). Tier 0 is represented by the reference clock. Taken as a standard GPS signal(Global Positioning System) or ACTS (Automated Computer Time Service). At the zero tier, NTP servers do not work.

Tier 1 NTP servers receive time data from a reference clock. Tier 2 NTP servers are synchronized with Tier 1 servers. There can be up to 15 tiers in total.

NTP servers and NTP clients receive their time data from Tier 1 servers, although in practice NTP clients would be better off not doing this as thousands of individual client requests would be too much for Tier 1 servers. It is better to set up a local NTP server that your customers will use to get information about the time.

The hierarchical structure of the NTP protocol is fault tolerant and redundant. Let's look at an example of his work. Two Tier 2 NTP servers synchronize with six different Tier 1 servers, each on an independent link. Internal hosts are synchronized with internal NTP servers. The two Tier 2 NTP servers coordinate time with each other. If the link to the Tier 1 server or one of the Tier 2 servers fails, the redundant Tier 2 server takes over the synchronization process.

Similarly, Tier 3 hosts and devices can use any of the Tier 2 servers. More importantly, having a redundant network of NTP servers ensures that the time servers are always available. By synchronizing with multiple time servers, NTP uses data from all sources to calculate the most accurate time.

It is worth noting that the NTP protocol does not set the time in its purest form. It corrects the local clock using the time offset, the difference between the time on the NTP server and the local clock. NTP servers and clients adjust their clocks by synchronizing with current time gradually or all at once.