Good afternoon, guests and regular readers. I am gradually moving from the basics to a more in-depth study of Linux. Today I want to consider operation of the ntp protocol, as well as setting time server on Linux(ntp server). So let's start with the theory.
NTP protocol
Network Time Protocol (NTP)- a network protocol for synchronizing a computer’s internal clock using networks with variable latency (read “channel width”/quality).
NTP is used for its work UDP protocol and port 123.
Current protocol version - NTP 4. NTP uses a hierarchical system "hourly levels"(they are also called Stratum). Level 0 (or Stratum 0)- these are usually devices that are atomic clocks (molecular, quantum), GPS clocks or radio clocks. These devices are usually not published on the World Wide Web, but are connected directly to Level 1 time servers via the RS-232 protocol (indicated by yellow arrows in the illustration). Level 1 synchronized with high-precision clock level 0, usually work as sources for servers level 2. Level 2 synchronized with one of the machines level 1, and synchronization with servers of your level is also possible. Level 3 works similarly to the second one. Typically, servers of levels two and below are published on the network. NTP protocol supports up to 256 levels. I would also like to note that servers of levels 1 and 2, and sometimes 3, are not always open to public access. Sometimes, in order to synchronize with them, you need to send a request by mail to domain administrators.
Why is there a restriction on access to servers? With the transition to each level, the error relative to the primary server increases slightly, but the total number of servers increases and therefore .
Assigning an NTP server on the local network
Why might we need an NTP server? For example, there are services in operating systems that may depend on synchronized time. The most prominent example of such services is the Kerberos authentication protocol. For it to work, it is necessary that on computers accessed using this protocol, the system time differs by no more than 5 minutes. In addition, accurate time on all computers greatly facilitates the analysis of security logs when investigating incidents on the local network.
NTP server/client operating modes
Client/server
This mode is by far the most commonly used on the Internet. The work scheme is classic. The client sends a request, to which the server sends a response within some time. The client is configured using the server directive in the configuration file, where the DNS name of the time server is specified.
Symmetrical active/passive mode
This mode is used if time synchronization is performed between a large number of peer machines. In addition to the fact that each machine synchronizes with an external source, it also synchronizes with its neighbors (peers), acting as a client and time server for them. So even if a machine "loses" an external source, it will still be able to obtain accurate time from its neighbors. Neighbors can work in two modes – active and passive. Working in active mode, the machine itself transmits its time to all neighboring machines listed in the peers section of the ntp.conf configuration file. If neighbors are not indicated in this section, then the machine is considered to be operating in passive mode. To prevent an attacker from compromising other machines by posing as an active source, authentication must be used.
Broadcast mode
This mode is recommended for use in cases where a small number of servers serve a large number of clients. When operating in this mode, the server periodically sends packets using the subnet's broadcast address. A client configured to synchronize in this manner receives the server's broadcast packet and synchronizes with the server. A feature of this mode is that time is delivered within one subnet (limiting broadcast packets). In addition, authentication must be used to protect against attackers.
Multicast mode
This mode is in many ways similar to broadcast. The difference is that multicast addresses of class D networks of the IP address space are used to deliver packets. For clients and servers, the address of the multicast group is specified, which they use for time synchronization. This makes it possible to synchronize groups of machines located in different subnets, provided that the routers connecting them support the IGMP protocol and are configured to transmit multicast traffic.
Manycast mode
This mode is an innovation in the fourth version of the NTP protocol. It involves the client searching for manycast servers among its network neighbors, receiving time samples from each of them (using cryptography) and, based on this data, selecting the three “best” manycast servers with which the client will synchronize. If one of the servers fails, the client automatically updates its list.
To transmit time samples, clients and servers operating in multicast mode use multicast group addresses (class D networks). Clients and servers using the same address form the same association. The number of associations is determined by the number of multicast addresses used.
Time in Linux
I’ll briefly tell you what time exists in Linux and how to set it. In Linux, as in other OS, there are 2 times. The first - hardware , sometimes called Real Time Clock, abbreviated ( RTC) (aka BIOS clock) they are usually associated with an oscillating quartz crystal that is accurate to a few seconds per day. Accuracy depends on various fluctuations, such as ambient temperature. The second clock is internal program clock , which occur continuously, including during interruptions in system operation. They are subject to variations due to heavy system load and interrupt latency. However, the system typically reads the hardware clock at boot and then uses the system clock.
Operating system date and time set at boot based on value hardware clock, and time zone settings. Time zone settings are taken from the file /etc/localtime. This file is a link (but more often a copy) of one of the files in the directory structure /usr/share/zoneinfo/.
Linux hardware clocks can store time in the format UTC(analogous to GMT), or the current territorial time. The general recommendation on what time to set (?) is the following: if several operating systems are installed on the computer and one of them is Windows, then you need to use the current time (since Windows takes the time from the BIOS/CMOS and considers it local). If only UNIX family operating systems are used, then it is advisable to store the time in the BIOS in UTC format.
Once the operating system boots, the operating system clock and BIOS clock are completely independent. The system kernel synchronizes the system clock with the hardware clock every 11 seconds.
After some time, there may be a difference of several seconds between the hardware and software clocks. Which clocks keep the correct time? Neither one nor the other until we set it up time synchronization.
Note:
The Linux kernel always stores and calculates time as the number of seconds since midnight 1st January 1970 of the year, regardless of whether your clock is set to local or universal time. Conversion to local time is done during the request process.
Since the number of seconds since January 1, 1970 UTC is stored as a signed 32-bit integer (this is true on Linux/Intel systems), your clock will stop working sometime in 2038. Linux doesn't have a year 2000 problem, but it does have a year 2038 problem. Fortunately, by then all Linux systems will be running on 64-bit systems. A 64-bit integer will contain our clock until approximately the 292271-millionth year.
NTP Server Linux
Introduction
There are many implementations for time synchronization for Linux OS. The most famous are Xntpd (NTP version 3), ntpd (NTP version 4), Crony and ClockSpeed. In our example we will use the ntpd server.
The ntpd daemon is both a time server and a client, depending on the settings of the configuration file /etc/ntpd.conf (sometimes /etc/ntp.conf), the daemon can “receive” time from remote servers and “distribute” time to other hosts.
General time synchronization circuit on the local network is as follows: you need to have 1 or 2 servers with access to the global network, which will receive time from the Internet. All computers on the local network are synchronized with the specified servers that receive time from the Internet.
Installing ntpd
Actually, installing the daemon boils down to installing the following packages: ntp(package including the daemon itself), ntpdate(the utility for manual time synchronization is outdated), ntp-doc(package documentation), in some distributions you will need to install the same ntp-utils(diagnostic utilities), in some they are included in the ntp package. I described how to install programs on Linux in. After installing the package, in most distributions, the daemon will already be configured as an ntp client (for example, this was the case in Debian). Accordingly, the main configuration files were automatically created: /etc/ntp.conf and /var/lib/ntp/ntp.drift and the daemon was automatically launched.
Before setting up the daemon to synchronize with the outside world, I would recommend setting the current system date to a value as close to real time as possible. Setting the date in Linux produced by the command: date MMDDhhmmCCYY.ss, where MM - month, DD - day of the month, hh - hours, mm - minutes, CCYY - 4 digits of the year, ss - seconds. At the same time, the values CCYY.ss it is not necessary to indicate.
As you can see, the specified command will set the current date and time to December 27, 2010, 20:06:30. date command without parameters, display the current system time. This command has a bunch of parameters, which can be found in man date.
It is also necessary to correctly configure the hardware clock and time zone. As mentioned above, the time zone is configured by copying the required zone file from the directory /usr/share/zoneinfo/ to file
/etc/localtime:
Ntp-server:~# cp /usr/share/zoneinfo/Europe/Moscow /etc/localtime
Hardware I set the clock to UTC:
# cat /etc/sysconfig/clock | grep UTC # UTC=true indicates that the clock is set to UTC; UTC=true ntp2-server:~# cat /etc/default/rcS | grep UTC UTC=yes
The first example specifies a configuration file that defines the use of UTC for RH, the second for Deb distributions.
In addition to setting the settings to use UTC time, you must specify hardware time. (in most cases this is not necessary, because the specified system time is inevitably synchronized with the hardware, by the kernel). But still, if you have the desire to do it... hwclock command reads and sets the hardware clock based on the parameters passed to it. The available options are described in the command's manual page. Here are some examples of using hwclock:
Ntp-server# hwclock # reads time from hardware clock ntp-server# hwclock --systohc --utc # sets hardware clock time to # UTC based on system time ntp-server# hwclock --systohc # sets hardware clock time # to local time based on system time ntp-server# hwclock --set --date "22 Mar 2002 13:17" # sets the hardware clock time # to the specified string
Another option for changing the time in the hardware clock is to access the BIOS when the system boots. Since OS time is independent of the hardware clock, any changes to the BIOS will be taken into account the next time you boot.
Now that we have everything prepared and installed, let's proceed to at a construction site.
Managing the ntpd daemon
Control ntpd daemon no different from controlling any other demons. Start or restart the ntpd service:
#/etc/init.d/ntp start #/etc/init.d/ntp restart
Stop:
#/etc/init.d/ntp stop
#/bin/kill `cat /var/run/ntpd.pid`
The daemon has the following launch parameters:
P - PID file,
-g - allow transition to big time jump
-c - config file
-q - force manual synchronization
Setting up the ntpd server
First of all, I advise you to change the daemon launch parameters in the following configuration file:
Ntp-server:~# cat /etc/default/ntp NTPD_OPTS="-g"
# cat /etc/sysconfig/ntpd # Parameters for NTP daemon. # See ntpd(8) for more details. .... # Specifies additional parameters for ntpd. NTPD_ARGS="-g"
This parameter will allow you to synchronize the clock, even if there is a very large time difference.
So, as I said, the configuration information ntpd daemon is in the file /etc/ntp.conf. The file syntax is standard, as in many other configs: empty lines and lines starting with the "#" character are ignored. Here's a simple example:
Ntp-server:~# cat /etc/ntp.conf server ntplocal.example.com prefer server timeserver.example.org server ntp2a.example.net driftfile /var/db/ntp.drift
Parameter server specifies which servers will be used for synchronization, one on each line. If server is given with argument prefer, How ntplocal.example.com, then this server is given preference over the others. The response from the preferred server will be discarded if it differs significantly from the responses of other servers, otherwise it will be used without regard to other responses. Argument prefer Typically used for NTP servers that are known to be very accurate, such as those that use dedicated precision time equipment.
Parameter driftfile specifies the file that is used to store the system clock offset. As far as I understand, this file permanently stores some value, which is formed based on the analysis of past time adjustments, and if external time sources become unavailable, then the time adjustment occurs according to the value from the file drift. It must not be modified by any other processes. And before specifying this file in the configuration, the file must be created.
By default, the NTP server will be accessible to all hosts on the Internet. Parameter restrict in file /etc/ntp.conf allows you to control which machines can access your server. If you want to prevent all machines from accessing your NTP server, add the following line to the file /etc/ntp.conf:
restrict default ignore
If you want to allow sync your clock with your server only machines on your network, But prohibit them configure the server or be equal participants in time synchronization, then instead of the above, add the line:
restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap
where 192.168.1.0 is the IP address of your network, and 255.255.255.0 is its netmask. /etc/ntp.conf may contain several restrict directives.
For correct and more accurate operation of the daemon, it is advisable to select servers of the level - from stratum 2 (you can, of course, stratum1, but you will have to waste time searching for such a server) and from the selected stratum 2 those to which there is a minimum “distance”. Typically, such servers may be provided by your ISP. The number of selected servers is desirable - more than 2 to 3, the more the better, but within reasonable limits. If you are too lazy to choose the best servers, then you can take the list of open second-level servers from here: http://support.ntp.org/bin/view/Servers/StratumTwoTimeServers.
Selecting a list of reference NTP servers
We go to the specified address (http://support.ntp.org/bin/view/Servers/StratumTwoTimeServers) and select a list of initial servers. From this list we select servers that meet our requirements by analyzing the command output ntpdate. When executing the command, the following syntax is used:
ntpdate parameters servers_separated by_space
To ensure that our query does not make changes to the system, we must use the -q parameter, which specifies the use of the query without making changes. It is also possible to use the -d switch, indicating that the command will be executed in debug mode, with the output of additional information, without making real changes (with this switch, a bunch of other garbage is displayed :), which we do not need at the moment). Other parameters can be found in man 8 ntpdate. From the specified link, I selected all Open Access servers located in Russia (RU) + the one provided by the provider and ran the command, it turned out something like this:
Ntp-server:~# ntpdate -q ntp2.ntp-servers.net ntp1.vniiftri.ru ntp2.vniiftri.ru ntp4.vniiftri.ru ntp0.ntp-servers.net ntp1.ntp-servers.net ntp3.vniiftri.ru ntp.corbina.net server 88.147.255.85, stratum 1, offset 0.006494, delay 0.09918 server 62.117.76.142, stratum 1, offset 0.002552, delay 0.06920 server 62.117.76.141, stratum 1, offset 0.0031 47, delay 0.06918 server 62.117.76.140, stratum 1, offset 0.004823, delay 0.07350 server 88.147.254.228, stratum 1, offset -0.002355, delay 0.12030 server 88.147.254.229, stratum 1, offset -0.000922, delay 0.10577 server 62.117.76.13 8, stratum 1, offset 0.005331, delay 0.07401 server 195.14 .40.141, stratum 2, offset 0.002846, delay 0.07188 13 Jan 19:14:09 ntpdate: adjust time server 62.117.76.141 offset 0.003147 sec
In the example, our servers successfully issued the stratum1 level, which is good news (except for the provider’s server), offset is the time difference with this server in seconds, delay is the synchronization delay in seconds. Usually, b ABOUT Greater accuracy is obtained when using servers that have low latency in transmitting packets over the network. To identify this, you can use . Accordingly, first selecting those with shorter response times, and of these, those with fewer hops to reach. In order not to waste time, I will use all the specified servers and enter them into the configuration file. In total, knowing all of the above, I will describe my resulting file /etc/ntp.conf:
Ntp-server:~# cat /etc/ntp.conf # Local network servers (commented out, not used - there is one server on the network) #server 192.168.0.2 #server 192.168.0.5 # Internet servers server ntp2.ntp-servers.net server ntp1.vniiftri.ru server ntp2.vniiftri.ru server ntp4.vniiftri.ru server ntp0.ntp-servers.net server ntp1.ntp-servers.net server ntp3.vniiftri.ru server ntp.corbina.net # Server files driftfile /var/lib/ntp/ntp.drift logfile /var/log/ntpstats # restricting access to the server: # by default we ignore everything restrict default ignore # localhost without parameters - that means everything is allowed. The parameters only apply to prohibitions. restrict 127.0.0.1 # The following describes the servers with which we synchronize on the local network. # We allow them everything except traps and requests to us restrict 192.168.0.2 noquery notrap restrict 192.168.0.5 noquery notrap # for local we also allow everything except traps and modifications restrict 192.168.0.1 mask 255.255.255.0 nomodify notrap nopeer # allow external time sources access: restrict ntp2.ntp-servers.net restrict ntp1.vniiftri.ru restrict ntp2.vniiftri.ru restrict ntp4.vniiftri.ru restrict ntp0.ntp-servers.net restrict ntp1.ntp-servers.net restrict ntp3.vniiftri.ru restrict ntp.corbina.net # and this is a hack that sets the trust level of the server (strata) to itself equal to 3 # in a nutshell, the higher the level, the lower the number. 0 is the atomic clock, #1 is synchronized with it, 2 is with the first one, and so on. server 127.127.1.1 fudge 127.127.1.1 stratum 3
For a more in-depth understanding and configuration of the server, I will describe some ntpd configuration parameters that I did not mention::
- enable/disable auth/monitor/pll/pps/stats - Turn on, turn off operating mode:
- auth- communicate with unmentioned neighbors only in authentication mode;
- monitor- allow monitoring of requests;
- pll- allow setting the local clock frequency via NTP;
- stats- allow statistics collection;
- statisticsloopstats- with each modification of the local clock, writes a line to a file loopstats;
- statisticspeerstats- every communication with a neighbor is recorded in a log stored in a file peerstats;
- statisticsclockstats- every message from the local clock driver is written to a log stored in a file clockstats;
- statsdir(catalog_name_with_statistics)- specifies the name of the directory in which files with server statistics will be located;
- filegen
- defines an algorithm for generating file names, which consist of:
- prefix- constant part of the file name, set either during compilation or by special configuration commands;
- file name- added to the prefix without a slash, two dots are prohibited, can be changed with the file key;
- suffix- generated depending on typename;
- restrictnumeric-address- sets access restrictions: packets are sorted and masked, the source address is taken and compared sequentially, a flag is taken from the last successful comparison
access:
- no flags- give access;
- ignore- ignore all packets;
- noquery- ignore NTP 6 and 7 packets (request and state modification);
- nomodify- ignore NTP 6 and 7 packets (state modification);
- limited- serve only a limited number of clients from a given network;
- nopeer- serve the host, but not synchronize with it;
- clientlimitlimit- for the flag limited determines the maximum number of clients served (by default 3);
So, we got ntpd-server, which synchronizes with the outside world, allows you to receive time for clients from the local network 192.168.0.1 with a mask of 255.255.255.0, and can also be synchronized with the local server (if you uncomment a few lines). All we have to do is set up clients and learn how to monitor our server.
Monitoring the ntpd server and synchronization
Once you have everything set up. NTP will keep the time in sync. This process can be observed using the NTP Query (ntpq) command:
Ntp-server:~# ntpq -p remote refid st t when poll reach delay offset jitter =============================== ============================================================= -n3. time1.d6.hsd.PPS. 1 u 34 64 177 70.162 2.375 8.618 +ntp1.vniiftri.r .PPS. 1 u 33 64 177 43.479 -0.020 10.198 *ntp2.vniiftri.r .PPS. 1 u 6 64 177 43.616 -0.192 0.688 +ntp4.vniiftri.r .PPS. 1 u 4 64 177 43.623 0.440 0.546 -n1.time1.d6.hsd .PPS. 1 u 53 64 77 92.865 -11.358 38.346 -ns1.hsdn.org .GPS. 1 u 40 64 177 78.057 -3.292 35.083 -ntp3.vniiftri.r .PPS. 1 u 44 64 77 47.667 2.292 2.611 -scylla-l0.msk.c 192.43.244.18 2 u 62 64 77 41.565 -1.564 28.914
This command with the -p switch prints to standard output a list of time sources with their characteristics (the remaining command parameters are in man ntpq). The meaning of each column is as follows:
The name of the remote NTP server. If you specify the -n switch, you will get server IP addresses instead of names.
Indicates where each server is currently getting its time from. This could be a hostname or something like .GPS., indicating the source of the Global Positioning System.
Stratum (level) is a number from 1 to 16 indicating the accuracy of the server. One means maximum accuracy, 16 means the server is unavailable. Your level will be equal to the level of the least accurate remote server plus 1.
Interval between polls (in seconds). The value will change between the minimum and maximum polling rates. At the beginning, the interval will be small so that synchronization occurs quickly. Once the clocks are synchronized, the interval begins to increase to reduce traffic and load on popular time servers.
An octal representation of an 8-bit array reflecting the results of the last eight attempts to connect to the server. The bit is set if the remote server responded.
The amount of time (in seconds) required to receive an answer to the query “what time is it?”
The most important field. Difference between local and remote server time. As synchronization progresses, this value should decrease (closer to zero), indicating that the local machine's clock is becoming more accurate.
Dispersion (Jitter) is a measure of statistical deviations from the offset value (offset field) over several successful request-response pairs. A lower dispersion value is preferable because it allows for more accurate time synchronization.
Meaning of characters before server names
x - fake source according to the intersection algorithm;
. - excluded from the list of candidates due to long distance;
- - removed from the list of candidates by the clustering algorithm;
+ - included in the final list of candidates;
# - selected for synchronization, but there are 6 best candidates;
* - selected for synchronization;
o - selected for synchronization, but PPS is used;
space - too large a level, a loop or an obvious error;
ntpd service“smart” and itself weeds out sources of time that are too outside the bounds of reason. Some time after starting, ntpd will select the most reliable data sources and will synchronize with them. The list of reference NTP servers we present is regularly reviewed by the service.
You can check the possibility of synchronization locally on the server with the command:
Ntp-server:~# ntpdate -q localhost server 127.0.0.1, stratum 2, offset -0.000053, delay 0.02573 server::1, stratum 2, offset -0.000048, delay 0.02571 14 Jan 14:49:57 ntpdate: adjust time server ::1 offset -0.000048 sec
From the command output it is clear that our server has already reached stratum 2 level. It will take some time to reach this level. Perhaps in the first 10-15 minutes the server level will be higher.
The correct operation of the ntp server can also be judged from the logs of the ntpd daemon:
Ntp-server:~# cat /var/log/ntpstats/ntp 13 Jan 20:13:16 ntpd: Listening on interface #5 eth0, fe80::a00:27ff:fec1:8059#123 Enabled 13 Jan 20:13: 16 ntpd: Listening on interface #6 eth0, 192.168.0.8#123 Enabled 14 Jan 14:31:00 ntpd: synchronized to 62.117.76.142, stratum 1 14 Jan 14:31:10 ntpd: time reset +10.291312 s 14 Jan 14 :31:10 ntpd: kernel time sync status change 0001 14 Jan 14:34:31 ntpd: synchronized to 88.147.255.85, stratum 1 14 Jan 14:36:04 ntpd: synchronized to 62.117.76.141, stratum 1 14 Jan 15: 04:36 ntpd: synchronized to 62.117.76.142, stratum 1 14 Jan 15:10:58 ntpd: synchronized to 62.117.76.140, stratum 1 14 Jan 15:17:54 ntpd: no servers reachable 14 Jan 15:31:49 ntpd : synchronized to 62.117.76.140, stratum 1 14 Jan 15:32:14 ntpd: time reset +13.139105 s
Setting up netfilter (iptables) for an NTP server
Having configured the server, it would be a good idea to protect it. We know that the server runs on port 123/udp, and requests are also sent from port 123/udp. After reading the article and familiarizing yourself with the practical ones, you can create rules for filtering network traffic:
Ntp ~ # iptables-save # typical iptables rules for DNS *filter:INPUT DROP :FORWARD DROP :OUTPUT DROP -A INPUT -i lo -j ACCEPT -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -m conntrack --ctstate INVALID -j DROP # allow local network access to the NTP server: -A INPUT -s 192.168.1.1/24 -d 192.168.1.1/32 -p udp -m udp --dport 123 -m conntrack - -ctstate NEW -j ACCEPT -A OUTPUT -o lo -j ACCEPT -A OUTPUT -p icmp -j ACCEPT -A OUTPUT -p udp -m udp --sport 32768:61000 -j ACCEPT -A OUTPUT -p tcp -m tcp --sport 32768:61000 -j ACCEPT -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT # allow NTP server access to make outgoing requests -A OUTPUT -p udp -m udp --sport 123 --dport 123 -m conntrack --ctstate NEW -j ACCEPT COMMIT
This is a typical example! To set iptables rules to suit your tasks and network configuration, you need to understand how netfilter works in Linux by reading the above articles.
Setting up client machines
To synchronize time on UNIX machines local network, it is advisable to use the ntpdate utility, running it several times a day, for example, every hour. To do this, you need to add the following line:
0 * * * * /usr/sbin/ntpdate -s
The -s switch directs the output of the command. If client machines have a couple of extra megabytes of RAM, then you can run the ntpd daemon, just like on the server with the following config:
Server
I think everything is clear in this config: the time source (server) is a local ntpd server, deny access to everyone, allow only the local ntpd server.
Also, on clients it is necessary to correctly specify in which format to store time and select the correct time zone.
To configure the Windows NTP client, you need to run the following commands in the console:
C:\>net time /setsntp:
Conclusion
Well, that's it! The volume of the article turned out to be enormous... I didn’t even expect it. Let me summarize the above. In this article, I hope it became clear to us what is and how an NTP server works. We learned how to configure a server and clients on UNIX and Windows machines. In a few words, the structure of time synchronization in a local network is as follows: There are 1,2 or more time servers in the local network, they synchronize their time with external sources in the global network. Server and client settings are based on the files /etc/ntp.conf (the main configuration file of the ntpd daemon), /etc/localtime (the current time zone file), as well as /etc/sysconfig/ntp (for RH) and /etc/default /ntp (for Deb) - daemon launch parameter files. For a local ntp server, the configuration file specifies external servers for obtaining time and allows access for these servers using the restrict parameter, as well as for local network computers; for clients, the time source is specified - local servers on the local network, and access is also denied for all , except for the time source on the local network. All. Thank you all for your attention! I will be glad to comments!
- (article archive) describes how to connect GPS to the server to organize your own Stratum1 level exact time server.
- describes how to configure authorization on an ntp server.
Good afternoon, dear readers and guests of the blog site, how much people talk about time, that it passes quickly or slowly, and everyone understands that it is priceless and important. So in the Active Directory infrastructure, it is one of the most important factors for the proper functioning of the domain. Everyone in the domain trusts each other, and having logged in once and received all the tickets from Kerberos, the user can go anywhere, limited only by his available rights. So, if you do not have the exact time on your workstations to the domain controller, then you can assume that you are starting to have serious problems, which we will talk about below and look at how to fix them using NTP server settings in Windows.
Time synchronization in Active Directory
The following time synchronization scheme operates among computers participating in Active Directory.
- The root domain controller in the AD forest, which owns the FSMO role of the PDC emulator (let's call it the root PDC), is the time source for all other controllers in this domain.
- Child domain controllers synchronize time with domain controllers that are higher in the AD topology.
- Ordinary domain members (servers and workstations) synchronize their time with the nearest available domain controller, respecting the AD topology.
The root PDC can synchronize its time both with an external source and with itself, the latter is set by default configuration and is absurd, as errors in the system log periodically hint at.
Synchronization of clients of the root PDC can be carried out both from its internal clock and from an external source. In the first case, the root PDC time server declares itself as “reliable”.
Next, I will give the optimal configuration for the root PDC time server, from my point of view, in which the root PDC itself periodically synchronizes its time from a reliable source on the Internet, and the time of clients accessing it synchronizes with its internal clock.
Enter netdom query fsmo. In my example, the role of PDC and NTP server belongs to the dc7 controller
NTP server configuration on root PDC
Configuring a time server in Windows (NTP server) can be done either using a command line utility w32tm, and through the registry. Where possible, I will present both options. But first, look at your settings on your computer in full, this is done with the command:
w32tm /query /configuration
EventLogFlags: 2 (Local)
AnnounceFlags: 10 (Local)
TimeJumpAuditOffset: 28800 (Local)
MinPollInterval: 6 (Local)
MaxPollInterval: 10 (Local)
MaxNegPhaseCorrection: 172800 (Local)
MaxPosPhaseCorrection: 172800 (Local)
MaxAllowedPhaseOffset: 300 (Local)FrequencyCorrectRate: 4 (Local)
PollAdjustFactor: 5 (Local)
LargePhaseOffset: 50000000 (Local)
SpikeWatchPeriod: 900 (Local)
LocalClockDispersion: 10 (Local)
HoldPeriod: 5 (Local)
PhaseCorrectRate: 7 (Local)
UpdateInterval: 100 (Local)NtpClient (Local)
Enabled: 1 (Local)
InputProvider: 1 (Local)
CrossSiteSyncFlags: 2 (Local)
ResolvePeerBackoffMinutes: 15 (Local)
ResolvePeerBackoffMaxTimes: 7 (Local)
CompatibilityFlags: 2147483648 (Local)
EventLogFlags: 1 (Local)
LargeSampleSkew: 3 (Local)
SpecialPollInterval: 3600 (Local)
Type: NT5DS (Local)NtpServer (Local)
DllName: C:\Windows\system32\w32time.dll (Local)
Enabled: 1 (Local)
InputProvider: 0 (Local)
AllowNonstandardModeCombinations: 1 (Local)VMICTimeProvider (Local)
DllName: C:\Windows\System32\vmictimeprovider.dll (Local)
Enabled: 1 (Local)
InputProvider: 1 (Local)
Enable synchronization of the internal clock with an external source
Enabling the NTP server
The NTP server is enabled by default on all domain controllers, but it can also be enabled on member servers.
Specifying a list of external sources for synchronization
The 0x8 flag at the end means that synchronization should occur in NTP client mode, at the time intervals suggested by this server. In order to set your own synchronization interval, you must use the 0x1 flag.
Setting the synchronization interval with an external source
Time in seconds between polling the synchronization source, default 900s = 15min. Works only for sources marked with the 0x1 flag.
"SpecialPollInterval"=dword:00000384
Setting the minimum positive and negative correction
The maximum positive and negative time correction (the difference between the internal clock and the synchronization source) in seconds, above which synchronization does not occur. I recommend the value 0xFFFFFFFF, at which correction can always be made.
"MaxPosPhaseCorrection"=dword:FFFFFFFF
"MaxNegPhaseCorrection"=dword:FFFFFFFF
Everything you need in one line
w32tm.exe /config /manualpeerlist:"time.nist.gov,0x8 ntp1.imvp.ru,0x8 ntp2.imvp.ru,0x8 time.windows.com,0x8 pool.ntp.org,0x8" /syncfromflags:manual / reliable:yes /update
Useful commands
- Applying changes made to the time service configuration
w32tm /config /update - Force synchronization from source
w32tm /resync /rediscover - Displaying the synchronization status of domain controllers in a domain
w32tm/monitor - Displays current sync sources and their status
w32tm /query /peers
Configuring NTP server and client using Group Policy
Since we have an Active Directory domain, it would be stupid not to use group policies for mass configuration of servers and workstations; I will show you how to configure your NTP server in Windows and the client. Open the “Group Policy Editor” snap-in. Before setting up our NTP server in Windows, we need to create a WMI filter that will apply the policy only to the PDC master server.
Enter the request name, namespace, the value will be “root\CIMv2” and the request “Select * from Win32_ComputerSystem where DomainRole = 5”. Let's save it.
Then you create a policy on the Domain Controllers container.
At the very bottom of the policy, apply your created WMI filter.
Go to the branch: Computer Configuration > Policies > Administrative Templates > System > Windows Time Service > Time Providers.
Here we open the “Configure Windows NTP client” policy. Set the parameters
- NtpServer: 0.ru.pool.ntp.org.0x1, 1.ru.pool.ntp.org.0x1, 2.ru.pool.ntp.org.0x1, 3.ru.pool.ntp.org.0x1
- Type: NTP
- CrossSiteSyncFlags: 2. Two means if this parameter is 2 (All), any synchronization participant can be used. This value is ignored unless NT5DS is specified. Default value: 2 (decimal) (0x02 (hex))
- ResolvePeerBackoffMinutes: 15. This value, expressed in minutes, determines how long the W32time service waits before attempting to resolve a DNS name if it fails. Default value: 15 minutes
- Resolve Peer BAckoffMaxTimes: 7. This value determines the number of DNS name resolution attempts that the W32time service makes before restarting the discovery process. Each time a DNS name resolution fails, the wait time before the next attempt is doubled. Default value: seven attempts.
- SpecilalPoolInterval: 3600 This NTP client parameter value, expressed in seconds, determines how often it polls a manually configured time source that uses a specific polling interval. If the NTPServer parameter is set to the SpecialInterval flag, the client uses the value specified as SpecialPollInterval instead of the MinPollInterval and MaxPollInterval values to determine how often to poll the time source. Default value: 3600 seconds (1 hour).
- EventLogFlags: 0
We create a separate group policy for client work machines, with these parameters.
- NtpServer: The address of your domain controller with the PDC role.
- Type: NT5DS
- CrossSiteSyncFlags: 2
- ResolvePeerBackoffMinutes: 15
- Resolve Peer BAckoffMaxTimes: 7
- SpecilalPoolInterval: 3600
- EventLogFlags: 0
Setting up an NTP server in Windows
Since Windows 2000, all Windows operating systems have included a time service W32Time. This service is designed to synchronize time within an organization. W32Time is responsible for the operation of both the client and server parts of the time service, and the same computer can simultaneously be both a client and an NTP (Network Time Protocol) server.
By default, the Windows time service is configured as follows:
When you install the operating system, Windows starts the NTP client and synchronizes with an external time source;
When you add a computer to a domain, the synchronization type changes. All client computers and member servers in the domain use a domain controller to synchronize time, which verifies their authenticity;
When a member server is promoted to a domain controller, an NTP server is launched on it, which uses a controller with the PDC emulator role as a time source;
The PDC emulator, located in the forest root domain, is the primary time server for the entire organization. At the same time, it itself is also synchronized with an external time source.
This scheme works in most cases and does not require intervention. However, the structure of the time service in Windows does not need to follow a domain hierarchy, and any computer can be designated as a reliable time source. As an example, I will describe setting up an NTP server in Windows Server 2008 R2, although the procedure has not changed much since Windows 2000.
Starting the NTP server
I should immediately note that the time service in Windows Server (from 2000 to 2012) does not have a graphical interface and is configured either from the command line or by directly editing the system registry. Personally, I prefer the second method, so let's go to the registry.
So, the first thing we need to do is start the NTP server. Open the registry branch
HKLM\System\CurrentControlSet\services\W32Time\TimeProviders\NtpServer.
Here to enable NTP server parameter Enabled need to set the value 1
.
Then we restart the time service with the command net stop w32time && net start w32time
After restarting the NTP service, the server is already active and can serve clients. You can verify this using the w32tm /query /configuration command. This command displays a complete list of service parameters. If section NtpServer contains the string Enabled:1, then everything is fine, the time server is running.
In order for the NTP server to serve clients, do not forget to open UDP port 123 on the firewall for incoming and outgoing traffic.
Basic NTP server settings
The NTP server has been enabled, now we need to configure it. Open the registry branch HKLM\System\CurrentControlSet\services\W32Time\Parameters. Here we are primarily interested in the parameter Type, which specifies the type of synchronization. It can take the following values:
NoSync - The NTP server is not synchronized with any external time source. It uses a clock built into the CMOS chip of the server itself;
NTP - The NTP server is synchronized with external time servers that are specified in the registry setting NtpServer;
NT5DS - The NTP server synchronizes according to the domain hierarchy;
AllSync - The NTP server uses all available sources for synchronization.
The default value for a computer that is part of a domain is NT5DS, for a stand-alone computer - NTP.
And parameter NtpServer, which specifies the NTP servers with which this server will synchronize time. By default, this parameter contains the Microsoft NTP server (time.windows.com, 0x1); if necessary, you can add several more NTP servers by entering their DNS names or IP addresses separated by a space. You can see a list of available time servers, for example.
You can add a flag at the end of each name (eg. ,0x1) which defines the mode for synchronizing with the time server. The following values are allowed:
0x1– SpecialInterval, use of a special polling interval;
0x2– UseAsFallbackOnly mode;
0x4– SymmetricActive, symmetrical active mode;
0x8– Client, sending a request in client mode.
When using the SpecialInterval flag, the interval value must be set in the key SpecialPollInterval. When the UseAsFallbackOnly flag is set, the time service is informed that this server will be used as a backup and before synchronizing with it, calls will be made to other servers in the list. Symmetric active mode is used by NTP servers by default, and client mode can be used in case of synchronization problems. You can see more about synchronization modes, or don’t bother and just install it everywhere ,0x1(as Microsoft advises).
Another important parameter AnnounceFlags located in the registry key HKLM\System\CurrentControlSet\services\W32Time\Config. It is responsible for how the NTP server announces itself and can take the following values:
0x0 ( Not a time server) - the server does not advertise itself via NetLogon as a time source. It can respond to NTP requests, but neighbors will not be able to recognize it as a time source;
0x1(Always time server) - the server will always announce itself, regardless of its status;
0x2(Automatic time server) - the server will announce itself only if it receives a reliable time from another neighbor (NTP or NT5DS);
0x4(Always reliable time server) - the server will always declare itself as a reliable time source;
0x8(Automatic reliable time server) - the domain controller is automatically declared reliable if it is a PDC emulator of the forest root domain. This flag allows the forest's master PDC to assert itself as the authorized time source for the entire forest, even in the absence of communication with upstream NTP servers. No other controller or member server (which has the default flag 0x2) cannot establish itself as a reliable time source if it cannot find a time source for itself.
Meaning AnnounceFlags is the sum of its constituent flags, for example:
10=2+8 - The NTP server declares itself as a reliable time source, provided that it itself receives time from a reliable source or is the PDC of the root domain. Flag 10 is set by default for both domain members and stand-alone servers.
5=1+4 - The NTP server always declares itself as a reliable time source. For example, to declare a member server (not a domain controller) as a reliable time source, flag 5 is needed.
Well, let's set the interval between updates. The key already mentioned above is responsible for it SpecialPollInterval, located in the registry branch HKLM\System\CurrentControlSet\services\W32Time\TimeProviders\NtpClient. It is specified in seconds and by default its value is 604800, which is 1 week. This is a lot, so it is worth reducing the SpecialPollInterval value to a reasonable value, say 1 hour (3600).
After configuration, you need to update the service configuration. This can be done with the w32tm /config /update command. And a few more commands for configuring, monitoring and diagnosing the time service:
w32tm /monitor - using this option you can find out how the system time of this computer differs from the time on the domain controller or other computers. For example: w32tm/monitor/computers:time.nist.gov
w32tm /resync - using this command you can force the computer to synchronize with the time server it uses.
w32tm /stripchart – shows the time difference between the current and remote computer, and can display the result in graphical form. For example, the command w32tm /stripchart /computer:time.nist.gov /samples:5 /dataonly will make 5 comparisons with the specified source and display the result in text form.
w32tm /config is the main command used to configure the NTP service. With its help, you can set the list of time servers used, the type of synchronization and much more. For example, you can override the default values and set up time synchronization with an external source using the command w32tm /config /syncfromflags:manual /manualpeerlist:time.nist.gov /update
w32tm /query - shows the current service settings. For example, the command w32tm /query /source will show the current time source, and w32tm /query /configuration will display all service parameters.
Well, as a last resort :)
w32tm /unregister - removes the time service from the computer.
w32tm /register – registers the time service on the computer. In this case, the entire branch of parameters in the registry is created anew.
The exact time server is designed to synchronize time-frequency indicators. The device generates frequency and precise 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 widespread NTP protocol and the PTP protocol, which is just gaining popularity. Receiving signals from satellites of the global positioning systems GPS and GLONASS, the server transmits them to client devices and synchronizes time parameters.
Description of SSV-1G
The frequency and precise time server “SSV-1G” is a stand-alone device with a height of 1.5 U, installed in a 19” telecommunications rack, designed to generate frequency and precise 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 has significantly reduced its cost, increased reliability, and eliminated dependence on the manufacturer of the operating system and server platform .
The exact time server is synchronized from signals from satellite radio navigation systems (SRNS) of both Russian GLONASS and GPS, which increases the accuracy of time determination and reduces the risk of operator 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 sources of master oscillator synchronization.
The RS232 input of the COMB module via TOD and Sirf protocols can be used as backup sources of time scale synchronization.
The SSV-1G is powered via two inputs (Main / Reserve) from independent sources AC 220 V 50 Hz / DC 48 V. A delivery option with two DC 48 V power inputs and an additional external AC 220 V 50 Hz - DC 48 V converter is possible, which allows power the SSV-1G through one input AC 220 V 50 Hz, and through the other DC 48 V. Energy 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.
Technical characteristics of SSV-1G
| Characteristic | Meaning |
| Are common | |
| Internal generator type | Piezoelectric thermostated ultra-precision |
| External clock inputs | GLONASS, GPS, Galileo, 1 PPS, E1/2.048 MHz, 5 MHz, 10 MHz |
| External time synchronization inputs | GLONASS, GPS, Galileo, ToD, SIRF |
| Sync outputs | NTP server, PTP master, 1 PPS, E1/2.048 MHz, SIRF, IRIG-B, 5 MHz, 10 MHz, current loop |
| Control | |
| Autonomous | built-in keyboard and display |
| Local | USB port and Maintenance software |
| Network | Ethernet and Maintenance Software, SNMP v2C (RFC 1158) |
| Network interface | 10/100 Base-T Ethernet |
| Supported protocols | |
| transport layer | TCP, UDP |
| IP protocol | IP v4 IP v6 (optional) |
| automatic configuration | DHCP (RFC 2131) NetBios Name Service (NBNS) |
| NTP (Network Time Protocol) protocol | NTP v2 (RFC 1119), NTP v3 (RFC 1305), NTP v4 (RFC 5905), SNTP v3 (RFC 1769), SNTP v4 (RFC 2030) |
| PTP (Precision Time Protocol) protocol | PTP v2 (IEEE Std 1588-2008) |
| SNMP protocol | SNMPv2c (RFC 1158) |
| RS-232 protocol | SIRF TOD |
| Interface 1PPS (1Hz) | |
| output level | 5V (TTL compatible) |
| pulse duration | 5 µs (IEEE Std 1344 - 1995) |
| pulse polarity | positive/negative |
| line resistance | 50 ohm |
| 5 MHz and 10 MHz clock signals | |
| waveform | nominally rectangular |
| output signal level at 50 ohm load | 1 V |
| Clock 2.048 MHz (G.703/10) | |
| waveform | nominally rectangular |
| 1.5 V | |
| 1.9 V | |
| Clock 2.048 Mbps (G.703/6) | |
| waveform | bipolar |
| output signal level at 75 Ohm load (coaxial pair) | 1.5 V |
| output signal level at 120 Ohm load (balanced pair) | 1.9 V |
| Metrological characteristics | |
| limits of permissible relative frequency error in synchronization mode using GNSS GLONASS/GPS signals | ±5.0×10 -11 |
| limits of the permissible root mean square relative deviation of the random component of the measurement error of the output signal frequency over a measurement time interval of 100 s | ±5.0×10 -11 |
| limits of permissible absolute error in binding the leading edge of the output pulse with a frequency of 1 Hz to the UTC time scale in synchronization mode using GNSS GLONASS/GPS signals | ±110 ns |
| limits of permissible absolute error in binding the leading edge of the output pulse with a frequency of 1 Hz to the UTC time scale in autonomous operation mode per day | ±20 µs |
| limits of permissible absolute error of time scale binding relative to the UTC(SU) time scale via the NTP protocol via the Ethernet interface | ±10 µs |
| Number of expansion modules | up to 8 pieces |
| Performance | |
| NTP server performance per port 10/100 Base-T Ethernet, requests per second, no less | 123 000 |
| Power supply | |
| number of power inputs |
2 |
| power supply voltage (depending on type of execution) |
═ 60 V (from 36 to 72) V ~ 220 V (198 to 242) 50 Hz |
| Power consumption | no more than 50 W in “operating” mode no more than 60 W in “warm-up” mode |
| dimensions | 483×255×65 mm |
| Weight | no more than 6 kg |
| Operating mode | 24/7 |
| average service life | at least 20 years |
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 class of equipment. This is achieved by two technological solutions.
Firstly, SSV-1G is built on the basis of a hardware platform of our own production. In addition, the SSV-1G device does not contain licensed software from third-party manufacturers.
Secondly, instead of expensive high-precision rubidium generators that have a short service life, quartz resonators with double thermostatting are used, which ensures a constant temperature level necessary to ensure a stable operating mode. This solution is similar in accuracy to rubidium generators, but 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 hard state machine.
This solution provides the highest performance and, as a result:
- High accuracy of transmission of time stamps due to the absence of internal delays that affect the asymmetry of the channel for receiving and transmitting NTP packets.
- 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.
- Impossibility of disrupting the functioning of the NTP server due to unauthorized access to resources via the Ethernet port. The NTP time server provides only functionality and does not respond to any other IP packets.
Modular design
The basic chassis of the SSV-1G source is a 19-inch case with installed control modules, an SRNS signal receiver, a thermally stabilized quartz oscillator with a phase-locked loop system, as well as a backplane for installing functional expansion modules.
The modular design allows you to create up to 16 NTP servers on physically separated networks on the basis of one device.
Expansion modules are installed according to the required input/output signal configuration based on the specification specified when ordering.
When changing the configuration, there is no need to buy a new device; it is enough to install the additional required number of expansion modules.
In total, up to 8 expansion modules can be installed.
Frequency and time source modules SSV-1G
Module "MLAN"
- Simple Network Time Protocol (RFC 1769, RFC 2030);
- Time Protocol (RFC 868);
- Daytime Protocol (RFC 867).
Module "MLANP"
The module is designed to receive requests from clients and generate a package with the exact current time according to the 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 a combination of the following parameters in any combination:
| Transmit protocol | Ethernet, UDP |
| Addressing mode | Unicast, Multicast, Mixed |
| Two steps | Yes, No |
When using Network Time Protocol (NTP), it is possible to send packets to a specified IP address (including Broadcast), with a 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.
Module "MGLAN" (NTP/PTP)
The module is designed to receive requests from clients and generate a package with the exact current time according to the 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).
Module "MPPS"
The module is designed to receive a PPS signal (1Hz) and generate a signal, the shape of which is specified in the configuration; it has two identical channels, each of which can operate in receive or transmit mode.
Module "MSYNC 120", "MSYNC 75"
The module is designed for receiving and generating signals of 2.048 MHz (G.703/10) or 2.048 Mbit/s (G.703/6) and has two identical channels, each of which can operate in signal reception or transmission mode.
Module "MCOMB"
The MCOMB module is designed to receive/transmit the exact current time in the specified format via the RS-232 interface, as well as 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 signal reception or transmission mode.
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.
Module "MIRIG"
The MIRIG module is designed to generate a signal in accordance with the IRIG STANDARD 200-04 protocol specification.
Module "M422"
The “M422” module 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
Monitoring and management of the operation of synchronization devices installed on the operator’s network can be provided by specialized network software “Maintenance” developed by JSC “KOMSET-service”.
Troubleshooting Management
- collecting messages from connected devices about accidents, malfunctions and events that require attention;
- obtaining a list of accidents;
- filtering accidents and assigning them a degree of severity;
- display of accidents and malfunctions, as well as their characteristics;
- monitoring the availability of a control device (the presence of a communication channel between the device and the control system);
- generation of reports on accidents and events.
Security Management
- protecting 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 user with read-only rights;
- monitoring the actions of operators to handle faults.
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 operating modes, parameters that determine the operation of the device;
- automatic recognition of device serial numbers (inventory function).
Performance Management
- display of current device characteristics in real time.
Output and user interface
- data on the status of network elements is displayed in tabular form with the ability to print them;
- the system has a convenient user interface that allows you to easily view:
- a list of devices, their current status and status 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 antenna visible at the installation point;
- and much more.
- The “Maintenance” software has developed means for visualizing and analyzing fault signals with the ability to provide sound notifications of various tones, easily customizable by the system user.
The SSV-1G time server is a proprietary development of the KOMSET-service company. It has an independent hardware platform, high accuracy of timing data transmission, a user-friendly interface and two power sources: 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 NTP time server used?
The scope of application of the equipment is quite wide. NTP servers are used at all facilities where it is extremely important to regulate time parameters:
- Mobile operator and telecommunications companies.
- Internet providers.
- Airports, railway and bus stations.
- In commercial automated accounting systems.