Five Minute Facts About Packet Timing
By Doug Arnold.
I get asked a lot of questions from customers about network timing technology. Some of them are challenging to answer. However, one that I get all the time that is easy to answer is this: “Do I want NTP or PTP?” It all comes down to accuracy. I simply ask them what time transfer accuracy do they need. Guilty, I’m answering a question with a question. Let me put it this way: Is the accuracy you need measured in microseconds or nanoseconds? If the answer is yes, you want PTP (IEEE 1588). If the answer is in milliseconds or seconds, then you want NTP.
I wrote earlier about why PTP is so accurate. And the answer is due to the fact that hardware timestamping is commonly implemented in PTP technology, but not in NTP. Hardware timestamping is allowed in the client and server devices which are running NTP, but not many devices out there implement this. Furthermore the biggest source of error in network timing is often due to the variations in queuing time in switches and routers. NTP does not have a solution for this, PTP does. The solution is to use special switches and routers called transparent clocks or boundary clocks. For a description of these clever devices see my earlier post: What Are All Of These IEEE 1588 Clock Types?. There is even ongoing standards work to use technology developed at CERN. (that’s right the people who discovered the Higgs Boson and invented the world wide web) to extend PTP to picoseconds.
If you’re thinking, I don’t need to coordinate measurements of high energy particles, I just want to set the clocks on my servers and routers to within a few ms, then you want NTP. But if PTP is more accurate why not use it for everything? Good question. The answer is:
- ease of implementation
- cost
- robustness.
NTP is easier to implement because free NTP clients are already included with just about any computer, server or router you buy. Just point each client to which address to ask for time and its good to go. You can also easily download and install free software that contains a list of know NTP servers and their addresses. Clink this link if you don’t believe me.
NTP is cheaper, because the clients are free, and no special switches are required. Most system integrators buy dedicated servers, since that saves them the trouble of integrating a GPS receiver (to get standard time) with an NTP server. But each server can keep thousands of clients happy and on time.
Both PTP and NTP have feature for fault tolerance, depicted in the diagrams below.
Redundant Grandmaster Clocks in a PTP network.
In the case of PTP a slave synchronizes to a master clock, which other masters listen in, so that they can take over if the active master goes away for any reason. That’s good, but NTP does one better. The client gets time from all of the servers and ignore one which seems to be too far off in time compared to the other servers.
Redundant servers in an NTP network
The bottom line is that NTP has been around several decades, and has become cheap easy and robust. The good news is that many of these properties are gradually being added to the world of IEEE 1588 so soon you will be able to have the ease and robustness of NTP with the accuracy of the Hadron Collider.
If you have any questions about PTP or NTP, don’t hesitate to send me an email at doug.arnold@meinberg-usa.com, or visit our website at www.meinbergglobal.com.
Thanks for the Blog! The information is quite useful.
Perfect and to the point.
The exact information that I was looking for.
Great Job.!! 🙂
Great article. I wish more people had the clarity of thought and expression to take a complex topic and make it nice and simple to understand.
Thanks!
J
I still don’t see the the unique advantages of PTP. I mean, NTP has been around for decades, it’s a free and open standard that is quite short and supported by most OSs. IEEE1588 (PTP) is less than ten years old, is non-free and several hundred pages long.
– Timestamping is not related to any of the protocols; Even Telnet could be timestamped – this is really just a question of the MAC used. We’ve implemented both protocols – precision is mainly a question if HW timestamping is used or not.
– Both protocols can be multicasted and unicasted. NTP supports authentication
– NTP is related to other IP based protocols, PTP stands isolated (this might change (AVB)).
– Boundary-Clocks: It’s just unusual for NTP to be implemented in switches/routers, but – again: That’s is not a question of the protocol used. Most PTP implementations I’ve seen run on top of UDP, so the complexity of running a boundary-clock in a switch/router supporting NTP shouldn’t be any higher than for PTP. If only PTP on Layer2 should be supported, PTP could be easier;
I’m open for input on this debate, but until now, it /seems/ to me that PTP is mostly an invention of the IEEE-related industry (read: non-IT-related) while not being aware of – or wanting to compete NTP.
It is true that NTP does not preclude hardware timestamping. However, the NTP standard mandates a message rate and client servo loop which is designed to achieve millisecond timing. You can, of course build a non-standard version of NTP which changes the message rates, and includes a different client servo algorithm. But anything which does have a standard behind it will not be allowed in many industries such as telecommunications and power utilities.
It would also be possible to turn switches and routers into non-zero stratum number NTP servers, to create on path support. That would make them like boundary clocks in PTP. However, no equipment manufacturers are doing this, so you would have to build and maintain your own switches and routers.
PTP also runs over bare Ethernet networks, Profinet, Devicenet, HSR, PRP. NTP does not do any of these non-IP network types. A version of PTP uses the special timing features of Wifi. NTP does not. A variant of PTP has been developed at CERN to achieve sub-ns timing. No such thing has been done with NTP.
The truth is that for reasons associated with history and standards body politics the world has adopted PTP for sub ms time transfer in networks, rather than developing a more precise NTP. Of course you don’t have to follow the herd, as long as you are willing to do it all yourself.
What are the security differences between the two protocols? NTP has the awkward requirement that autokey cannot traverse a NAT. Does PTP have such restrictions? Also, can PTP be used across the internet?
Unfortunately PTP does not yet a real built in security mechanism. There is an incomplete experimental security mechanism included as an appendix in IEEE 1588-2008, but almost no one has implemented even that. So for now PTP does not have security. This will probably be fixed in the next revision, but that won’t be out for a couple of years.
More bad news: if you try to run PTP over a Wide area network you will end up with about the same accuracies as NTP. PTP can maintain its precision through about 5 switches/routers unless these devices are also transparent clocks or boundary clocks. Even with this on path support there is a limit of a few dozen hops before network timing asymmetry builds up and ruins the accuracy of PTP. Practical uses of PTP generally focus on local distribution of time from a grandmaster. And different parts of the network are kept together by making sure that the grandmasters are using the same time, such as via a GPS receiver.
According to PTP V2(IEEE 1588-2008) standard, can master swap its status to slave or slave swap its status to master looking at the quality of clocks or higher priority(like if slave one syncs to GPS)? Can the state machine, which has slave status, decides that I have a better clock and I have to be master or can master decides that there is state machine that has a better clock on the network so I have to be its slave and change its status to slave and sync?
The short answer is yes. The Best Master Clock Algorithm allows masters to become slaves and slaves to become masters, if their clock quality or priority fields change.
However, this is not common in practice. Usually clocks designed to act as Grandmasters are master only clocks. So if they are not acting as the grandmaster of the network, then they go into a passive state, where they just listen to see if the acting grandmaster goes away and needs to be replaced. Also clocks designed to act as grandmasters generally have better clock properties then ordinary clocks which are designed primarily to be slaves. Some ordinary clocks are slave only, so if there is no master, then they just listen and wait for one to become available.
What would be the difference between a system based on a network entity whose primary function is not to distribute time signals, but has inbuilt PTP server with GPS receiver and a system built around a Unicat Grand Master with GPS receiver? Does the later achieve better accuracy? Can it server a higher number of slaves?
A device designed to be a PTP Grandmaster typically has the following properties which a server with bolted on PTP and GPS may not have:
1. A mechanism for the PTP timestamping counter to be set to the GPS receivers time with high precision, typically a few ns.
2. A high quality oscillator, for example an OCXO, which guarantees a good frequency stability of the PTP output and also provides much better holdover, when GPS is lost.
3. Some dedicated GMs have FPGA or ASIC acceleration for PTP which allows them to support very high PTP message rates.
4. A 1 PPS output which can be used to verify performance.
5. Other timing outputs such as serial time codes, 10 MHz low phase noise, and programmable rates.
Can anyway hep me out on below query:
Let us assume we had a simple PTP Grand Master with single network. No Boundary, Transparent clocks exist and with Software based PTP Timestamping. How this system is better than SNTP?
Somewhere I heard that SNTP accuracy is milliseconds and Software based PTP is microseconds and Hardware based timestamping is nanoseconds. Can any one explain how this is achieved
As both Uses UDP packets and both uses some algorithm to calculate the offset and synchronizes its local clock – I guess there should not be any reason why PTP is more accurate?
Hello Raghu,
there is no significant difference in accuracy if you use software timestamping either with NTP or PTP, since they both rely on the same components which influence timestamping (network stack, driver, service interrupt routine, network asymmetry, etc.) In general NTP applies time corrections gradually, whereas PTP makes time adjustments faster. In both cases by using software timestamping millisecond accuracy can be achieved.
However, with “real” PTP its hardware timestamping eliminates drawbacks of unpredicted behavior of the software. Therefore accuracies between few tens of nanosecond to sub microsecond (depending on a deployment) can be expected.
PTP can run both multicast or unicast, NTP is most commonly used in the unicast mode of operation.
Hi! I had the same questions, especially since the wikipedia entry for PTP claims that PTP in a LAN can achieve a precision of a few microseconds with software only.
Also this page claims the same thing: https://timemachinescorp.com/2020/04/09/3-differences-between-ptp-hardware-and-software/
Having looked at the how the NTP and the PTP protocol work and the messaging, it is still unclear to me why a software only implementation of PTP should be an order of magnitude more accurate than NTP.
What are your thoughts?
Thanks
In common use PTP is more precise than NTP because hardware timestamping is the norm, message rates are higher in PTP than NTP, and intervening switches and routers remove queuing noise for PTP (on path support).
It is possible to achieve time transfer precisions of a few microseconds using either PTP or NTP and only software. However, to do it with NTP you have to replace the standard algorithms, and use much higher message rates than the standard NTP algorithms call for. At this point you are using only the packet structure and the general client-server messaging paradigm from the NTP standard and ignoring the rest. You can’t use ntpd unless you have a trivial network and a client computers doing nothing else.
To get this kind of precision with either NTP or PTP also requires that certain tricks with the OS kernel, such as using a high resolution counter on the processor as a clock rather than kernel calls to system time. This has been done in Linux and FreeBSD. I doubt anyone has gotten this to work on Windows, but I could be wrong. Most people who are using standard hardware take advantage of the fact that many Ethernet PHYs in Intel architecture servers are now capable of hardware timestamping, and that can get you below a microsecond in a small, lightly loaded network for NTP or PTP, or a network with on path support for PTP.
Simple & superb.. Thanks very much… 🙂
Trying to understand your fault tolerance scenario.
If there are multiple GMs , say there are 3..Does that mean one of them is sending Announce messages and the other two are simply receiving them? So in other words all of their ports are in a SLAVE state?
Secondly, are Announce messages propagated throughout the network through master ports?
Hello Michael,
You are correct. Only the best master sends announce messages. Master capable devices which are not the best master can either act as slaves or simply be in the passive state. Usually when a device is configured to act as a grandmaster it goes passive when not the best master.
Boundary clocks will receive announce messages on one (slave) port from either the grandmaster, or another BC. All of the other ports of the BC will be either in the master state or passive (if needed to break timing loops). The BC will receive announce messages, but not pass them on. Instead it creates its own announce messages and sends them out all of its ports which are in the master state. The announce message from the BC will contain some information about the GM of the network, but it is not the same announce message which the GM sends.
Doug
Hello.
I am going to apply a time sync solution on my LAN network system.
I want time accuracy under 100 microseconds using PTP.
so, I am going to apply one grand master server in the network and run PTP client software in computers needed time sync.
there are no ptp support switches and NICs.
Is it possible configuration?
what does network delay effect on Accuracy in ptp
The network delay with either PTP or NTP does not affect the accuracy as long as the delay from the master/server to the slave/client is the same as the delay in the reverse direction. Both PTP and NTP assume this to be true. As a result any difference in the the forward and reverse network delays results in an error in estimating the clock offset at the slave or client. Message queuing in switches and routers is a problem because it is common for the queuing duration to be different going from port A to port B, than from port B to port A.
Thanks for the great article.
I’m trying to find out more about resiliency and fault tolerance of NTP vs PTP.
In the case of a single network, I understand there can be active and passive GM. However, I also read that failure of active GM are not easily detected unless there is actual and complete communications link loss. Can I ask how I can reconcile this information with the BMCA that “selects” the best master based on timing accuracy, etc.?
Additionally, if I have slaves that are connected to 2 separate GM via 2 different network switches in a dual redundant network configuration, does this help to improve the resiliency of PTP? How would the slave know which timing info to accept from 2 different GM?
Like NTP, PTP is fault tolerant and has redundancy. However, NTP takes it a step further with what is called “false ticker identification.” What this means is that NTP clients and higher stratum servers can get time from several servers and run a voting algorithm to detect if a server is sending bad time, or the network path is so congested that the time is bad by the time it is received. That is allowed in PTP but rarely implemented. With NTP it is standard practice.
I came here after after watching a Linus Tech Tips video on PTP.
I liked the article, but I liked the comment even more.
Thanks Douglas!
If this thread is still alive. What are your thoughts on PTP Grandmaster resilience from a reference source, hardware, and software perspective? RFC 8633 recommended diverse hardware and software implementations for NTP to eliminate the risks of an entire pool reporting bad time due to bugs or clock design problems. Of course that RFC is quite dated now and I don’t see any similar guidance for PTP from the standards community or the various clock manufacturers like Meinberg.
The RFC might be old, but the principle of hardware and software diversity is still a valid one, and probably always will be. What I see in practice however, is that most network operators pick a vendor, and usually one product from that vendor and try to achieve resilience with redundant hardware, and possibly redundant time sources (e.g. GPS + Galileo + Cs oscillator) but no redundancy in the the hardware and software design. I believe that the main reason for this is that one vendor, and especially one vendor + one product family is much easier to deploy and manage. There are fewer instructions to create for the network operations staff, and fewer types of management interface to integrate into the overall management scheme of the network.