NTP(Network Time Protocol) is a network protocol for synchronizing a computer's internal clock using networks with variable latency. The protocol was developed by David L. Mills, a professor at the University of Delaware, in 1985. The version for 2015 is NTPv4.

NTP, based on the Marzullo algorithm, uses the UDP protocol to operate and takes into account transmission time. The NTP system is extremely resistant to changes in transmission media latency. In version 4 it is capable of achieving an accuracy of 10 ms (1/100 s) when working over the Internet, and up to 0.2 ms (1/5000 s) and better within local networks.

The NTP protocol is most widely used for synchronizing time servers. To achieve maximum accuracy, it is preferable to always run the NTP software in system service mode. In the Microsoft Windows family of operating systems this is the W32Time service, Linux - the Ntpd service.

A simpler implementation of this algorithm is known as SNTP - Simple Network Time Protocol. Used in embedded systems and devices that do not require high precision, as well as in custom time programs.

Package structure

The packet structure is described in RFC 5905. The packet consists of an integer number of 32-bit words.

The header information will differ for different operating modes. For example, a client in the fields hour layer, source id, start time And time of receipt must write zeros.

Heading

NTP header

Indentation	Octet	0								1								2								3
Octet	Bit	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	0	IR		Version			Mode			Hour layer								Polling interval								Accuracy
4	32	Delay
8	64	Dispersion
12	96	Source ID
16	128	Update time
20	160
24	192	Start time
28	224
32	256	Time of receipt
36	288
40	320	Dispatch time
44	352

Correction indicator

Example of time synchronization using NTP

Length - 2 bits, from Leap Indicator. An integer indicating the leap second warning.

Version number

Length - 3 bits, from Version Number. An integer representing the protocol version.

Mode

Length - 3 bits, from Mode. An integer representing the mode. The values ​​are presented in the table below.

Hour layer

Length - 8 bits, from Stratum. An integer representing the hour layer.

Polling interval

Length - 8 bits, from Poll. A signed integer representing the maximum interval between consecutive messages. The value is equal to the binary logarithm of seconds. The default suggested limits for minimum and maximum surveys are 6 and 10, respectively.

Accuracy

Length - 8 bits, from Precision. A signed integer that represents the accuracy of the system clock. The value is equal to the binary logarithm of seconds. For example, a value of -18 will correspond to an accuracy of about 1 µs.

Delay

Length - 32 bits, from Root Delay. The total time of signal propagation in both directions in short NTP format.

Dispersion

Length - 32 bits, from Root Dispersion. Total variance for a time source in short NTP format.

Source ID

Length - 32 bits, from Reference ID. Synchronization source code. Depends on the value in the Hour layer field. For layer 0- These four ASCII characters, called "kiss code", are used for debugging and monitoring. See below for layer 1 is four octets of ASCII characters, padded on the left with zeros, assigned to the time reference. The table below shows the list maintained by IANA.

ID	Source
GOES	Geostationary satellite for environmental monitoring and surveillance system
GPS	Global Positioning System
GAL	Galileo positioning system
P.P.S.	General radio signal with a pulse duration of 1 second
IRIG	Telemetry Standardization Group, USA
WWVB	Low Frequency Radio Transmitter, 60 kHz, Fort Collins, Colorado, USA
DCF	Low frequency radio transmitter, 77.5 kHz, DCF77, Mainflingen, Germany
HBG	Low frequency radio transmitter, 75 kHz, Prangins, Switzerland
MSF	Low frequency radio transmitter, 60 kHz, Anthorn, UK
JJY	Low frequency radio transmitter, 40 kHz, Fukushima, 60 kHz, Saga, Japan
LORC	Mid-frequency radio transmitter, 100 kHz, radio navigation, LORAN-C
TDF	Medium frequency radio transmitter, 162 kHz, Allouis, France
CHU	High Frequency Radio Transmitter, Ottawa, Ontario, Canada
WWV	High Frequency Radio Transmitter, Fort Collins, Colorado, USA
WWVH	High frequency radio transmitter, Kauai, Hawaii, USA
NIST
ACTS	NIST telephone modem
USNO	US National Observatory telephone modem
PTB	Telephone modem of the National Metrological Institute of Germany

For layer 2 and above is the server identifier and can be used to capture time loops. If IPv4 is used, the identifier is four octets of the IP address. If IPv6 is used, then these are the first four octets of the MD5 hash of the address. It is worth noting that when using IPv6 addresses for a server with NTPv4 and a client with NTPv3, the identifier may take a random value, which is why time loops may not be recorded.

Update time

Length - 64 bits, from Reference Timestamp. The time when the system last set or adjusted the time. NTP format.

Start time

Length - 64 bits, from Origin Timestamp. The client time when the request is sent to the server. NTP format.

Time of receipt

Length - 64 bits, from Receive Timestamp. Server time when the request comes from the client. NTP format.

Dispatch time

Length - 64 bits, from Transmit Timestamp. The server time when the request is sent to the client. NTP format.

NTP message "Kiss-o"-Death"

For layer 0, which is considered undefined or invalid, field Source ID can be used to deliver messages that serve as system state information and access control. Such messages are called "Kiss-o"-Death" (KoD), and the ASCII data they deliver are called "kiss codes". A list of currently accepted "help" codes is presented in the table below.

Recipients of KoD messages are required to check them and perform the following actions:

• When receiving code combinations DENY And RSTR the client is obliged to break virtual connections with this time server and stop sending messages to this server.
• Upon receiving the code combination RATE the client must immediately reduce its polling interval for this server and continue to reduce it each time it receives this code combination.
• When receiving a code combination starting with an ASCII character X, intended for experimental research and subsequent improvements, it should be ignored if it is not recognized.
• All other code combinations and KoD messages not defined by this protocol are destroyed after they are verified.

Help codes

Code	Description
ACST	Virtual connection established by unicast server
AUTH	Server authentication failed
AUTO	Autokey sequence is incorrect
BCST	Virtual connection established by broadcast server
CRYP	Cryptographic authentication or identification failed
DENY	The remote server denied access
DROP	Loss of a remote time server in symmetric mode
RSTR	Access denied due to local security policy
INIT	The virtual connection was not established the first time
MCST	Virtual synchronization connection established by dynamically discovered server
NKEY	The key was not found (either it has never been loaded before, or it is unreliable)
RATE	The speed is exceeded. The server has temporarily denied access because the client has exceeded the speed threshold
RMOT	Changing the virtual connection from a remote IP host using the NTP protocol directly
STEP	An iteration has occurred to change the system time, the virtual synchronization connection is not established

Hour layers

Yellow arrows indicate hardware connection; red arrows indicate network connection.

NTP uses a hierarchical network where each level has its own number, called a layer. Layer 1- primary servers that directly synchronize with national time services via satellite, radio or telephone modem. Layer 2- secondary servers, synchronized with primary servers, etc. Typically, NTP clients and servers with a relatively small number of clients are not synchronized with the primary servers. There are several hundred public secondary servers running on higher layers. They are the preferred choice.

Time format

Time is represented in the NTP system as a 64-bit number (8 bytes), 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 2 32 seconds (136 years), the recipient must at least approximately know the current time (with an accuracy of 68 years). Also note that time is measured from midnight on January 1, 1900, not 1970, so almost 70 years (including leap years) must be subtracted from NTP time to correctly match the time with Windows or Unix systems.

Regular time format

Bit	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	Seconds
4	Fractional seconds

Date format

Bit	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	Era number
4	Era indentation
8	Shares
16

MSK-IX NTP Server is a public time server supported by MSK-IX. The exact time server is designed to synchronize the internal clocks of computers and network equipment (servers, routers, smartphones, etc.) with the reference source using the NTP protocol.

MSK-IX NTP server belongs to the highest level of accuracy (Stratum One Time Servers) in the hierarchical system of time levels. The signal from the global satellite navigation systems GLONASS (priority) and GPS is used as a reference time signal.

MSK-IX NTP Server is implemented as a grouping of servers located in Moscow, St. Petersburg, Yekaterinburg and Novosibirsk. The use of anycast network technology ensures high reliability and fast response of the system throughout the country.

MSK-IX servers are also included in the international pool of NTP servers POOL.NTP.ORG, widely used in operating system settings.

How to start using the NTP Server service?

Use the following parameters when configuring your hardware:

Server name	ntp.msk-ix.ru
IPv4 address	194.190.168.1
IPv6 address	2001:6d0:ffd4::1

How to establish peering with the MSK-IX NTP server network?

To shorten the network route to the MSK-IX NTP server, use the Route Server service or establish direct peering with the MSK-IX DNS Cloud network. Peer-to-peer interaction is established upon an additional application within the framework of the contract for connection to MSK-IX without additional payment.

Answers on questions

26.09.2018

It is difficult to imagine the modern world without precise time. In many areas of life, it is necessary to have very accurate clocks, and the accuracy must often be much higher than the accuracy of the clocks people use in everyday life. For example, the accuracy requirements for clocks in air traffic control towers, spacecraft control systems, or military systems are at the highest level. Also, high-precision clocks are also needed in systems with simpler functions - in billing and tariff systems of cellular operators and Internet providers, in banking transaction systems, in exchange systems, in industrial and scientific complexes. On local networks, the Kerberos user authentication protocol also uses a comparison of the domain controller's time with the clock of user workstations. In computer networks, synchronization is usually performed with exact time servers using the protocol NTP or its “light” version - SNTP. In this article we will look at the features, differences and examples of application of these protocols.

NTP(English) Network Time Protocol– Network Time Protocol) – a network protocol for synchronizing a computer’s internal clock using networks with variable bandwidth. Provides high accuracy of time synchronization thanks to a special algorithm that allows you to select the most accurate sources to estimate the exact time. This algorithm allows you to minimize the impact of data from obviously incorrectly configured NTP servers on the overall system. The NTP protocol provides synchronization mechanisms with nanosecond precision, and contains facilities for characterizing and estimating errors of the local clock and the time server that performs the synchronization. The NTP protocol uses a hierarchical system of levels, or stratums. An NTP server is at the highest level (stratum 1) if it receives data directly from an accurate time source. Servers that synchronize their clocks with the stratum 1 server are on the level below (stratum 2), etc.

SNTP(English) Simple Network Time Protocol– simple network time protocol) – a protocol for synchronizing time over a computer network. It is a simplified implementation of the NTP protocol; it lacks the complexity of the NTP algorithm. SNTP is used for network hosts that do not require full NTP functionality. It is common practice to synchronize the clocks of several nodes on a local network with other NTP nodes over the Internet and use these nodes to time synchronize services provided to other clients over the local network. This use case does not require high precision time synchronization. The SNTP protocol provides synchronization mechanisms with an accuracy of 1 to 50 ms

An example of using the NTP protocol: Bank N provides its clients with a client-server application for exchange trading. Servers that process information about stock quotes must have a clock with high precision synchronization with the universal time scale. In this case, each exchange trading server of bank N is synchronized with the most accurate of the exact time servers (“stratum 1”), which receives data directly from the exact time source. The most accurate server is selected using an algorithm built into the NTP protocol. An approximate architecture of such a solution is shown in the diagram below:

A classic example of using SNTP is time synchronization within a domain. The domain controller receives time from the global Internet from the public servers of Stratum 1 or Stratum 2. The remaining clients of the domain synchronize their clocks with the time on the domain controller. An approximate architecture is shown in the diagram.

First, let's decide why we need to synchronize time on equipment such as switches, routers, firewalls, and so on.

This is done primarily in order to track using logs when this or that event occurred. And you can imagine what use the logs will have if the time is not synchronized... that's right - none.

Protocol NTP works based on protocol UDP, through 123 port.

This protocol has a certain hierarchy for synchronizing systems, in other words levels.

Level 1 is assigned to a system that is synchronized with a high-precision clock, such as GPS.

A system that will synchronize from Level 1 will have Level 2, and so on.

Thus, we can determine how accurate the time of the station with which we are synchronized is.

In our situation, we have a machine on the network with precise time, I have it configured based on FreeBSD, from this machine, the main network device will take time (synchronize), and thereby become the main one for other network devices (in the cisco ideology it will be ntp master).

I would like to note the fact that time is transmitted via NTP only in the format UTC (Greenwich), each time zone is configured directly on the hardware.

Let's look at an example of a simple NTP setup.

First, let's synchronize the time on our main router (which will be distributed to other network devices). To do this, go into global configuration mode:

ntp server 10.0.100.254

where, 10.0.100.254 in our case is a FreeBSD machine that has an exact time.

This is enough for minimal setup.

Now let’s check if we were able to connect to the time server and get time from it, to do this we use the command:

you should see something like this:

The asterisk opposite the ip of our ntp server tells us that everything is fine, the connection is at least established.

Now let's see if the time is synchronized?

If everything is synchronized, then we should see the following:

The time has been received, now you need to set the time zone you need there. We also do the following in global configuration mode:

clock timezone MSK/MSD 3

Now let's check the time:

Everything is great.

Let's move on to setting up our router in master mode.

For this setup, we need to make this router a master and indicate the level (in Cisco it is called stratum number), the same one that I talked about at the beginning, I will indicate level five.

Now let’s try to configure ntp on another setter device so that it synchronizes with our main router; this is done in the same way as we set up synchronization with the FreeBSD server above.

ntp server 10.0.100.1 prefer

where 10.0.100.1 is our head router.

prefer this is a keyword that indicates that this ntp server is a priority (that is, you can specify that you can synchronize not from one server, but from several, this is done so that if one is unavailable, or the time is too different from others, which indicates which - problems, the device can switch to another time server, and prefer makes this server more preferable than others.)

We also indicate the timezone we need.

clock timezone MSK/MSD 3

We check:

Everything is great, everything works.

Now let's look at the issue of security.

To begin with, let's look at the issue of restricting using ACLs, who can synchronize and who cannot.

Everything is quite standard and transparent.

On the time server we create the corresponding ACL:

access-list 20 remark ACCESS to NTP Syncaccess-list 20 permit 10.0.100.3

Now let's bind this access list to ntp.

ntp access-group serve-only 20

If everything is configured correctly, then communication with the ntp server will be established and synchronization will be successful.

You can also additionally register an access list on clients. Which time servers can be accessed. This is done in a similar way:

access-list 20 remark ACCESS SYNC to NTP Servaccess-list 20 permit 10.0.100.1

Link the access list to NTP

ntp access-group peer 20

Now let's look at authentication-based security.

Everything is also quite transparent.

It is enough to add the following to the ntp configuration:

ntp authentication-key 1 md5 15060E1F10243F34 7ntp authenticatentp trusted-key 1

With the first command we set the authentication key, with the second we enable authentication, and with the third we indicate that authentication should be carried out using the first key. We configure this on each side (server - client). That's actually all. The result is a short introductory course on setting up NTP on Cisco devices. For debugging we use:

ASW-M#debug ntp ?adjust NTP clock adjustmentsauthentication NTP authenticationevents NTP eventsloopfilter NTP loop filterpackets NTP packetsparams NTP clock parametersrefclock NTP reference clockselect NTP clock selectionsync NTP clock synchronizationvalidity NTP peer clock validityASW-M#debug ntp

We turn on everything that is interesting to us, for example events, sync, auth and see what happens. If we log into the device via ssh/telnet, do not forget ter mon :)

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

Hourly levels. Strata.

To understand the NTP device you need to 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 basis that they have some way of maintaining highly accurate timekeeping. You can, of course, use an ordinary quartz watch, 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 stratum 1. Since there are always delays due to signal transmission and costs for setting the 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 a completely acceptable deviation.

The next level of computers taking time over the network from stratum 1- this is... drum roll... intrigue... stratum 2! Again due to various delays (network delays for sure), stratum 2 a little behind stratum 1 and certainly from stratum 0. In practice, this is a difference from several microseconds (1 μs = 10 -6 s) to several milliseconds (1 ms = 10 -3 s). Many people want to sync with the layer no further stratum 2.

As is clear from the diagram, stratum 4 takes time from a superior stratum 3. stratum 5 at stratum 4 and so on. stratum 16 is considered the lowest layer and time is counted there unsynchronized.

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

Time client.

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

How much to add? Please keep in mind:

• If you have only one server (one line server), then if this server starts to lie, 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 them both 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 identified 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 a project called NTP Pool at which address pool.ntp.org/zone/ru/ you can find time servers recommended for Russian users.

server 0.ru.pool.ntp.org
server 1.ru.pool.ntp.org
server 2.ru.pool.ntp.org
server 3.ru.pool.ntp.org

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

server 0.debian.pool.ntp.org
server 1.debian.pool.ntp.org
server 2.debian.pool.ntp.org
server3.debian.pool.ntp.org

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

If you run the command ntpq -pn on your Linux computer that uses NTP

Remote refid st 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 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 to us). Ideal - 2.
• t- connection type. " u" - unicast or manycast, " b" - broadcast or multicast, " l" local reference clock, " s" - symmetrical knot, " A" - manycast server, " B" - broadcast server, " M" - multicast server.
• when- time when the server last responded to us. The parameter displays the number in seconds, but may display in minutes if the number is with m or in hours if h.
• poll- polling frequency. Minimum 16 seconds, maximum 32 hours. The number must be 2n. Typically, this parameter displays either 64 seconds or 1024.
• reach- 8 bits of an octet indicating the status of communication with a remote time server: successful or failed. If the bits are set, then it is successful, otherwise it is a 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- the offset in milliseconds between you and the time servers. Can be a positive or negative number.
• jitter- the absolute value in milliseconds indicating the standard deviation of your offset.

There is a symbol before the IP address of the NTP server - 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 rank and does not serve people like you.
• "x"- rejected 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.
• "." - discarded due to table overflow.
• "-" - discarded by the cluster algorithm. The clustering algorithm sorts the list of candidates by layer and synchronization distance codes.
• "+" - the server is turned on by the “combine algorithm”. This server is an excellent candidate if your current time server starts to fail you.
• "#" - the server is an excellent 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 watch.
• "o"- Pulse per second (PPS) server. This usually means that the time server in question uses time sources such as GPS satellites and other precise time signals. If drawn O, then other types of tally code will no longer be displayed.

In field refid can have 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 station CHU 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 in Mount Otakadoya, near Fukushima or Mount Hagane on Kyushu Island, Japan.
• .LFx.- Regular LF radio receiver.
• .LOCL. - local host clock.
• .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.- Pulse per second clock.
• .PTB.- Physikalisch-Technische Bundesanstalt from Brunswick and Berlin, Germany.
• .RATE. - NTP polling 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 WWV station in Fort Collins, Colorado, United States.
• .WWVB.- LF radio receiver from WWVB station in Fort Collins, Colorado, United States.
• .WWVH.- HF radio receiver from the WWVH station in Kekaha, on the island of Kauai on Hawaii, United States.

First, get rid of the idea 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, but 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. Don't forget that we are talking about microseconds and milliseconds, which is quite enough in ordinary life.

Secondly, remember that connecting to the nearest time server is not always ideal. What is more important is not the territorial proximity, but the level of stratum. The NTP Pool project publishes a list of tier-only servers stratum 1 And stratum 2 and it’s better to take up to 10 time servers from this list, which will be just great.

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

For large offices, the best option would be to set up their own time server for work computers. This server will receive accurate time from time servers on the Internet and provide it to 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 take accurate clock readings from your server. For internal Linux-based servers that are not time servers and are engaged in their own tasks, instead of running the ntpd daemon in client mode, it is quite enough to specify it 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 IP.address.of.your.server > /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 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 create a lot of unnecessary problems in the beginning.

Fourthly, NTP has nothing to do with which country and which time zones are used and how the transition to summer and winter time occurs and whether such a transition is made in a given 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 must be up to date.

Fifthly, it is better not to run your NTP server on a highly loaded system.