NTP time server - DTS 4138

SNTP (Simple Network Time Protocol) and NTP (Network Time Protocol) are describing exactly the same network package format, the differences can be found in the way how a system deals with the content of these packages in order to synchronize its time. They are basically two different ways of how to deal with time synchronization.

While a full featured NTP server or -client reaches a very high level of accuracy and avoids abrupt timestamps as much as possible by using different mathematical and statistical methods and smooth clock speed adjustments, SNTP can only be recommended for simple applications, where the requirements for accuracy and reliability are not too demanding.

By disregarding drift values and using simplified ways of system clock adjustment methods (often simple time stepping), SNTP achieves only a low quality time synchronization when compared with a full NTP implementation. SNTP version 4 is defined in RFC2030, where it reads:

“It is strongly recommended that SNTP be used only at the extremities of the synchronization subnet. SNTP clients should operate only at the leaves (highest stratum) of the subnet and in configurations where no NTP or SNTP client is dependent on another SNTP client for synchronization. SNTP servers should operate only at the root (stratum 1) of the subnet and then only in configurations where no other source of synchronization other than a reliable radio or modem time service is available. The full degree of reliability ordinarily expected of primary servers is possible only using the redundant sources, diverse subnet paths and crafted algorithms of a full NTP implementation.”

Therefore the term “NTP time server” or “NTP compatible client” can – by definition – describe a system with a fully implemented NTP as well as any other product which uses and understands the NTP protocol but achieves far worse levels of reliability, accuracy and security.

There are basically two ways to take the leap second into account in your own IT time system. The first solution (DTS4160, DTS4210) is that the leap second is automatically read in via the GPS receiver and the time server can implement this in the NTP time stamp that is output. The background to this device automatism is that the GPS satellite operators usually take the IERS specification into account accordingly, which is guaranteed by advance notice and the actual leap second itself. Only on the basis of both components can GPS receivers and time servers process the leap second correctly and at exactly the right time and also implement it in terms of system technology.

Some operators of critical infrastructures, on the other hand, prefer the manual procedure because there is a certain residual risk with regard to the secure reception of both of the above-mentioned components and the leap second usually has to be tracked separately for other IT systems anyway. Also, the definition of leap seconds is not a standard procedure, so that this may also speak for a conscious, then manual, process on the part of the user. With this alternative solution of manual setting, you can make a corresponding setting in good time with our DTS devices, for example via MOBA NMS or Telnet SSH, whereby the DTS time server then safely processes the leap second and implements it accordingly.

As a rule, NTP clients send a request packet every 64 seconds at most. With a device code of 100 “requests per second”, 6,400 NTP clients could already be synchronized in the network. For example, if you use the DTS 4160 time server with 10,000 “requests per second”, there are even 640,000 clients that could be synchronized with this type of time server in the network. Since more current NTP versions increase the polling interval by a factor of 16 with stable time synchronization, this results in an even greater number of possible NTP end devices. One should therefore take this fact into account when selecting the device specification that is really necessary for the specific need. For larger networks, it is also common that hierarchical time server structures – consisting of several network segments or levels, each with an assigned time server – are created. In this way, the time servers of the lower level always synchronize to the higher level right down to the central time server. This central time server typically has the highest performance features and is often redundant.

Possible troubleshooting may proceed as follows:

• Firewall or port filter is blocking NTP packages.
• Make sure that firewall settings in Windows enable UDP protocol in both ways (inbound/outbound) on port 123.
• Some w32time versions coming with Windows XP or Windows Server 2003 may be unable to query the time from NTP servers.
• A workaround for the recognized problem is to change the behaviour of the w32time.

If an internet connection is working properly then NTP can determine and account for the packet transmission delays quite reliable. However, if the internet connection is at its capacity limit, time synchronization can be significantly degraded due to high dispersion in packet transmission delays. Reasons for this may be hacker attacks, which must not address your own network, or new viruses causing a huge flood of emails, like it has already happened in the past. An own NTP server cannot easily be compromised out of the internet.