The “Network Time Protocol” is a worldwide standard (see RFC 958) for packet-based synchronization of industrial clocks and time systems. It belongs to the Internet protocol family (see TCP / IP reference model) and typically uses the UDP, sometimes also the TCP transport layer. The runtime differences are compensated for using special algorithms in order to implement reliable time information in networks with variable packet runtime. A distinction is made between NTP servers (control devices) and NTP clients (end devices).

This is a simplified form of the NTP and is described in RFC 2030. The main difference is that SNTP relies on simpler algorithms and you have to use a time server.

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 timesteps 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 archieves 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 archieves far worse levels of reliability, accuracy and security.

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 can not easily be compromised out of the internet.

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 behavior of the w32time.

PTP is the "Precision Time Protocol", which is defined in IEEE 1588. In contrast to NTP, this is a network protocol, which is characterized by significantly higher accuracies (down to the nanosecond range) and is usually used in locally limited networks (e.g. measurement / control / regulation technology, automation technology, etc.) . In the foreground is not the absolutely correct time information, but rather the high-precision “clocking” of interconnected devices in such industrial or computer networks. In connection with the PTP network organization and clock types, one speaks initially of Grandmaster Clocks (best possible reference device) and Boundary Clocks (devices with master and slave function), whose role distribution is determined using the Best Master Clock algorithm. On the other hand, clearly defined roles are assigned to the ordinary clocks (either as master or clients), so-called transparent clocks then only forward the PTP time stamp when corrected. The runtime correction is ensured using complex computing algorithms. So it is not the case that one procedure is to be replaced by the other: NTP and PTP have different functional focuses, which is why both will continue to have authorization in the future and can also be used in parallel in computer networks if necessary. The runtime correction is ensured using complex calculation algorithms. So it is not the case that one procedure is to be replaced by the other: NTP and PTP have different functional focuses, which is why both will continue to have authorization in the future and can also be used in parallel in computer networks if necessary. The runtime correction is ensured using complex calculation algorithms. So it is not the case that one procedure is to be replaced by the other: NTP and PTP have different functional focuses, which is why both will continue to have authorization in the future and can also be used in parallel in computer networks if necessary.

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 DTS4160 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.

Such considerations are important for hierarchically structured time server structures. The stratum level “0” always refers to the time server on the top level, which functions as the reference time source of the overall system, for example, by means of exact DCF / GPS synchronization. The level below, along with the time servers located there - which in turn synchronize themselves to level "0" - is given the stratum level "1" accordingly. Levels further below therefore add up the stratum level “n + 1”. As a rule, a maximum of 16 stratum levels are defined.

With a redundant structure, the DTS devices are equipped to communicate with each other and to carry out a permanent time comparison. This adjustment is necessary in order to compensate for technically unavoidable differences in the quartz drift of the two devices by means of software trimming. If one did not carry out this adjustment, the theoretically possible failure of the DCF / GPS synchronization and “free running mode” (in practice not perceived in part immediately) would run the risk of a defect in the first time server and the subsequent switchover A corresponding time jump occurs on DTS time server No. 2 in the network. However, such leaps in time are generally undesirable in IT networks, since they cause an undefined state and instability. In order not to be dependent on the IT network itself,

Most of the time zones in the world are based on “Coordinated Universal Time” (UTC, international time standard). However, the earth's rotation is not as regular and is minimally smaller than was defined when this time standard was defined. For this reason, so-called "leap seconds" are inserted into the UTC time scale from time to time. Since the natural rotation of the earth is not perfectly constant, the insertion of leap seconds is done as needed and according to no fixed pattern. Leap seconds are determined in such a case by the International Earth Rotation and Reference Service (IERS). However, the responsible state institution is usually responsible for the official time of a particular country.

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.

MiFID has been the relevant directive within the European Union since November 2007 when it comes to regulating the financial sector. The ESMA (European Securities and Markets Authority, see www.esma.europa.eu) responsible as authority. Initially established as MiFID I, the relevant regulations have been continuously developed and are now finally being used as MiFID II - after lengthy debates and adjustments - since January 2018. This affects, for example, financial trading centers, investment companies and other financial market players as well as banks, of course (seehttps://www.esma.europa.eu/policy-rules/mifid-ii-and-mifir).

One component of these new MiFID II directives is that, among other things, the technical standards This also includes very specific regulations, which under Chapter RTS 25 focus on the "Level of Accuracy of Business Clocks", i.e. the time synchronization and the nature of the necessary time stamps in the IT system (see http://eur-lex.europa.eu/legal-content/EN/TXT/ uri=uriserv:OJ.L_.2017.087.01.0148.01.ENG&toc=OJ:L:2017:087:TOC).

Summarized in broad terms, there are elementary changes to the previous status quo. As previously, “Coordinated Universal Time” (UTC) should continue to serve as a timestamp reference time for “Business Clocks used by Operators” - this would probably be understood to mean the financial IT infrastructures in simple terms in practice. In contrast to the past, only a deviation of 100 µs is allowed, which concerns the accuracy compared to UTC at the application level. The requirements regarding the resolution of the time stamp, which can often only be 1 µs, have also been tightened. Details can be found in Tables 1 and 2 of the above-mentioned standard RTS 25.

Concretely related to the use of time server devices, it follows that conventional NTP servers are no longer sufficient for the precise time synchronization of such financial systems and their process run times. The fact that PTP time servers according to IEEE 1588 have to be used to implement the above MiFID II requirements is now accepted as universally accepted by experts. By the way, further details on UTC, NTP and PTP are oursFAQs refer to.

In the practical implementation of these business-specific watch regulations, however, there is often a need for clarification in financial companies. What exactly is meant by "business clocks" in a specific case, which IT infrastructure needs to be synchronized, how and where do relevant runtimes arise? How can you measure these runtimes sensibly and verifiably, which process runtime is created in the standard software, how do you make the "trading machine" (hardware and software) really MiFID II-compliant? In addition, how does one comply with the legal requirement to check the “compatibility of the traceability system” annually?

It is unlikely that it will be possible to offer only  one standardized and uniform system and device solution for all applications. Because not only the pure product specification of the PTP time server - with us this would be the DTS 4160.grandmaster - is important for this, but also a wealth of project-specific issues. We are happy to assist you as a specialized project partner.

For the calculation of the heat dissipation you need the power dissipation (Pd) of the device. Unfortunately this value is usually not available in the technical data of the devices. But you can calculate an approximate value when you have the max. power consumption of the device.
Of course, the power dissipation is always lower than the max. power consumption of the device, but the calculated value is on the secure side.

As MOBATIME devices have a small power consumption, the difference is not too big.

Example of calculation with DTS 4138 device:
From technical data in manual: DC power supply: 24 VDC, 10 W

P = 10 W => simplification: Pd = 10 W

Pd (W) = Heat energy per time => (Wh / h) (heat load)

1 Wh / h = 3.6 kJ / h (heat dissipation)

Heat dissipation formula = Pd (W) * 3.6 kJ / h

Our example:
Heat dissipation DTS 4138 = 10 W * 3.6 = 36 kJ / h

Result:
Heat dissipation < 36 kJ / h

NTP is working with UDP packets.
The size of one packet is less than 128 Bytes, approx. 100 Bytes.
The traffic is defined from how often the clients are requesting the time from a server.

Unicast Mode:
NTP clocks are usually configured to request the time from server every 10s.
This means the following traffic:
1 NTP request packet and 1 NTP answer packet, every 10s, each with approx. 100 Bytes.
==> 200 Byte per 10s or in average 20 Bytes / sec or 160 Bits / sec.
So for e.g. 1000 clocks, it is in average approx. 160 kBit / sec.

In masterclocks you define with the poll interval, how often the time is requested from a server. The min poll interval value is usually 3, means every 8s (2 * 2 * 2 = 8).
So the traffic is almost the same as for slave clocks.

Mainly the bandwidth for NTP is minor, compared with other network traffic.

Typically it is < 1ms, when the network and the number of client requests per second is not taken into consideration.
The network delay can differ very much, depending on the traffic load. That's why NTP packets contain two time stamps (packet output and packet input). So the response time can be calculated and compensated.

Conclusion:
For standard NTP, the network delay (response time) is not relevant for the presicion of the client synchronization.
Except, when the delay should be very high, then the reachability of the NTP server could be degraded.