Application examples

To synchronize time, NetPing devices use the NTP protocol. Using this protocol, all devices on the network adjust their time according to the specified server. NetPing devices connected to the Internet can use a public NTP server, as recommended in article. If there is no access to the Internet, then you can set up a local NTP server. Such a server can be any Windows computer with a configured service W32Time (« Windows Time Service "). This service does not have a graphical interface and is configured either through the command line or by editing registry keys.

Instructions for setting up an NTP server on Windows 7/8/2008/2012

Consider setting up a time service through editing the registry. The setup is the same for versions of Windows 7/8, Windows Server 2008, Windows Server 2012.

For this setting, you must have Windows administrator rights.

Open the registry editor either through the dialog box " Run” triggered by the key combination “ Win» + « R", or through the search form, where we type " regedit».

In the editor that opens, in the left tree menu, open the "branch" " HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time\TimeProviders\NtpServer", where we are looking for a key with the name " enable". Right-click and select "Edit". Change key value from 0 on 1 .

By changing this parameter, we indicated that this computer acts as an NTP server. The computer simultaneously remains a client and can synchronize its time with other servers on the Internet or a local network. If you want the internal hardware clock to act as a data source, then change the value of the key parameterAnnounce Flags on 5 in the thread " HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config».

For the changes to take effect, we need to restart the service. Services are accessed via Control Panel» from the menu « Start» -> « Control Panel» -> « Administration» -> « Services". It is also in the search form when you enter " services.msc". In the list of services that appears, we find the one we are interested in " Windows Time Service"and through the menu called by the right mouse button, select the item" Restart».

There are many services in operating systems whose normal functioning 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, on a 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 accurate time, 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 the event of connection failures with the upstream servers, the 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 best known and most widely used time synchronization tool is the ntpd daemon. Depending on the settings specified in the configuration file (this will be discussed below), it can act both as a server and as a client (i.e. 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 complete, open the /etc/ntp.conf file in a text editor. 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) 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 198 25 6 37 0.621 -216.90 257.037 +85.21.78.8 193.11.166.20 2 u 193 256 37 32.028 - 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.

The exact time server is designed to synchronize time-frequency indicators. The device generates frequency and time signals with high accuracy and synchronizes these parameters at remote sites.

The time synchronization server can operate using various signals and protocols, including the common NTP protocol and the more popular PTP protocol. Receiving signals from satellites of global positioning systems GPS and GLONASS, the server transmits them to client devices and synchronizes time parameters.

Description of SSV-1G

Frequency and time server "SSV-1G" is a stand-alone device 1.5 U high, installed in a 19" telecommunication rack, designed to generate frequency and time signals.

Unlike many other products on the market, the SSV-1G time server is not based on industrial servers, but uses its own hardware platform, which significantly reduces its cost, increases reliability, and eliminates dependence on the manufacturer of the operating system and server platform .

Synchronization of the exact time server is carried out from the signals of satellite radio navigation systems (SRNS) of both the Russian GLONASS and GPS, which increases the accuracy of time determination and reduces the risks of the operator's dependence on foreign navigation systems.

The 1PPS signal input, the E1/2.048 MHz input, or the 5 (10) MHz input can be used as backup clock sources for the master oscillator.

The RS232 input of the COMB module can be used as a backup source of time scale synchronization using the TOD, Sirf protocols.

The SSV-1G is powered by two inputs (Main / Backup) from independent sources AC 220 V 50Hz / DC 48 V. A delivery option is available with two DC 48 V power inputs and an additional external converter AC 220 V 50Hz - DC 48 V, which allows to supply power to the SSV-1G through one input AC 220 V 50 Hz, and through the other input DC 48 V. Power consumption depends on the configuration and does not exceed 40 W.

Maintenance of the device is simplified as much as possible. Operating personnel can receive information and control the device using the Maintenance System software, or using the control tools built into the device - a graphic indicator and a keyboard.

Specifications SSV-1G

Advantages of the SSV-1G time source

• Optimal price-quality ratio

The SSV-1G source has one of the best price-quality ratios in its equipment class. This is achieved by two technological solutions.

Firstly, the SSV-1G is built on the basis of a hardware platform of its own production. In addition, there is no third-party licensed software in the SSV-1G device.

Secondly, instead of expensive high-precision rubidium oscillators with a short service life, quartz oscillators are used with double temperature control, which ensures a constant temperature level necessary to ensure a stable operating mode. This solution is similar in accuracy to rubidium generators, but it costs significantly less and is more reliable.

• Information Security

All SSV-1G expansion modules, including the NTP-server module, have a hardware implementation built on the basis of a rigid automaton.

This solution provides the highest performance and as a result:

1. High accuracy of time stamp transmission due to the absence of internal delays that affect the asymmetry of the NTP packets transmission and reception channel.
2. The impossibility of disrupting the functioning of the NTP server due to DDOS attacks. The speed of the local NTP server is higher than the speed of the Ethernet channel.
3. The impossibility of disrupting the functioning of the NTP server due to unauthorized access to resources through the Ethernet port. The NTP time server only provides functionality and does not respond to any other IP packets.

Modular design

The base chassis of the SSV-1G source is a 19-inch case with installed control modules, a SRNS signal receiver, a thermally stabilized quartz oscillator with a phase-locked loop, and a backplane for installing functional expansion modules.

The modular design allows you to create up to 16 NTP servers on the basis of one device in physically separated networks.

Expansion modules are installed in accordance with the required configuration of input / output signals based on the specification determined at the time of order.

When changing the configuration, there is no need to buy a new device, it is enough to install an additional required number of expansion modules.

In total, up to 8 expansion modules can be installed.

Frequency and time source modules SSV-1G

MLAN module

• Simple Network Time Protocol (RFC 1769, RFC 2030);
• Time Protocol (RFC 868);
• Daytime Protocol (RFC 867).

MLANP module

The module is designed to receive requests from clients and generate a packet with the exact current time according to the following protocols:

• Network Time Protocol (RFC 1119, RFC 1305, RFC 5905);

The Precision Time Protocol (PTP) is designed for a single client connection. The operating mode is determined by any combination of the following parameters:

When using the Network Time Protocol (NTP), it is possible to send packets to the specified IP address (including broadcast Broadcast), with the specified frequency.

The module has two independent channels with identical functionality and the same set of configuration parameters. Channels are configured individually. The load capacity of each channel is about 123,000 packets per second.

MGLAN module (NTP/PTP)

The module is designed to receive requests from clients and generate a packet with the exact current time according to the following protocols:

• Precision Time Protocol V2 (IEEE Std 1588-2008);
• Network Time Protocol (RFC 1119, RFC 1305, RFC 5905);
• Simple Network Time Protocol (RFC 1769, RFC 2030).

MPPS module

The module is designed to receive a PPS signal (1Hz) and form a signal, the shape of which is set in the configuration, has two identical channels, each of which can operate in the receive or transmit mode.

Module "MSYNC 120", "MSYNC 75"

The module is designed to receive and generate 2.048 MHz (G.703/10) or 2.048 Mbps (G.703/6) signals and has two identical channels, each of which can operate in the signal reception or transmission mode.

MCOMB module

The MCOMB module is designed to receive/transmit the exact current time in the specified format via the RS-232 interface, as well as to receive and generate a 1 PPS time stamp pulse.

Supported RS-232 interface protocols: TOD; Sirf, TimeString, NMEA.

Module "M10M"

The module is designed to receive and generate 5 MHz or 10 MHz signals and has two identical channels, each of which can operate in the mode of receiving or transmitting a signal.

Module "MTP" (Current Loop)

The module is designed to generate a time stamp pulse via the "Current loop" or "Dry contact" interface and has two independent, galvanically isolated channels.

MIRIG module

The MIRIG module is designed to generate a signal according to the IRIG STANDARD 200-04 protocol specification.

Module "M422"

Module "M422" is designed to receive/transmit the exact current time in the specified format via the RS-422/485 interface, as well as receive and generate a time stamp pulse via the RS-422/485 interface.

Supported RS-422/485 interface protocols: TOD, Sirf, TimeString, NMEA.

Centralized Management

Control and management of the operation of synchronization devices installed on the operator's network can be provided by specialized network software "Maintenance", developed by CJSC "COMSET-service".

Troubleshooting Management

• collection of messages about accidents, malfunctions and events requiring attention from connected devices;
• getting a list of accidents;
• filtration of accidents with assignment of severity degree to them;
• display of accidents and malfunctions, as well as their characteristics;
• control of the accessibility of the control device (the presence of a communication channel between the device and the control system);
• generation of reports on accidents and events.

Security management

• protection of access to the system using a username and password;
• user authorization in the control system;
• four levels of user rights from administrator (with full rights) to a user with read-only rights;
• control of actions of operators on processing of malfunctions.

Configuration management

• adding a new device;
• for each supported device remote display of information about the device: information on the inputs/outputs used, device configuration, device operation modes, parameters that determine the operation of the device;
• automatic recognition of device serial numbers (inventory function).

Performance management

• displaying the current characteristics of devices in real time.

Output and User Interface

• data on the state of network elements are displayed in a tabular form with the possibility of printing them;
• the system has a user-friendly interface that makes it easy to view:
  • a list of devices, their current state and state information elements;
  • list of users, access rights granted to users;
  • current state of all device modules;
  • the state of the satellite signal receiver, the state of the satellite constellation visible at the installation point;
  • and much more.
• “Maintenance” software has advanced tools for visualization and analysis of fault signals with the possibility of sound notification of various tones, easily customizable by the user of the system.

The time server "SSV-1G" is a proprietary development of the KOMSET-service company. It has an independent hardware platform, high timing accuracy, user-friendly interface and two power supplies: main and backup. You can buy a time synchronization server in Moscow from us in a standard or extended version. It is also possible to supply the device throughout Russia. You can get prices for equipment by submitting a request for a commercial offer from the company.

Where is the NTP time server used?

The scope of the equipment is quite wide. NTP servers are used at all facilities where it is extremely important to regulate time parameters:

• Companies of mobile operators and telecommunications.
• Internet providers.
• Airports, railway and bus stations.
• In commercial automated accounting systems.

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

Although 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. Because the NTP time scale repeats every 232 seconds (136 years), the recipient must at least roughly know the current time (to within 68 years). Also keep in mind that the time is counted 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. The GPS signal (Global Positioning System) or ACTS (Automated Computer Time Service) is taken as a reference. 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 the current time gradually or all at once.

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, a clock difference of more 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 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 NTP Pool project 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 1 024 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 accurate time signals. If drawn O, 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 user-client, then the servers recommended for 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 correct time from Internet time servers 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 get the most accurate clock from your server. For internal Linux-based servers that 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 connected 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.