Choosing between PTP and NTP

June 28th 2012 · 8 min read

This article has been updated to reflect changes in the industry here.

Many people ask about the trade-offs between using the PTP (IEEE 1588) and the NTP protocols for time synchronization.  Since TimeKeeper supports both I thought it a good idea to highlight a few of the differences between the two and why to choose one over the other. (Another post provides a more business oriented analysis.)

First off, there is no intrinsic performance difference between the two protocols. That is, one is not necessarily going to provide significantly better time or has better accuracy than the other when implemented well. Unfortunately, it has become common wisdom that “NTP cannot deliver accuracy better than 1 ms” or “PTP accuracy is far superior to NTP” but neither of those are correct. There is no secret protocol magic in either.  Both protocols do the same thing and carry the same information. They do differ in how they operate, and depending on your environment one may be a better choice than the other. The difference in performance that you’re going to get on your network depends on the implementation of the NTP/PTP hardware and software and not the protocol itself.

The executive summary from this article is if you’re using a high quality implementation of NTP or PTP (such as TimeKeeper) they’re both equivalent and both can give you single digit microsecond accuracy or better. If you use low quality implementations, quality and accuracy can vary greatly.

You can run both NTP and PTP together - on the same network. With TimeKeeper you can serve both from the same device - giving out the same time. You can also track both on the same client at the same time with TimeKeeper. That allows you to compare the performance of the two directly, so there’s no guessing which is better.

Now let’s look at some of the significant differences in how the protocols operate.

Current (legacy) generation network time appliances

Many current network appliances qualify as being ‘legacy’ - because nearly all use a very poor implementation of NTP. Most also use a far more modern and careful implementation of PTP. The reason is that it’s much easier to get a copy of the reference implementation of NTP than it is to create a more accurate version. It has been available for years from the University of Delaware. The accuracy and performance of the University of Delaware ntpd is well known, and taking a free piece of software and putting it on an a time server appliance gives you that same level of accuracy.

With these older devices you’re going to see poor NTP performance but generally good PTP performance.  That’s just a result of the quality of the PTP and NTP implementations on those boxes.

TimeKeeper is a next-generation, top-notch implementation of NTP and PTP so server performance and accuracy shows the same quality - single digit microsecond or better. TimeKeeper was designed from the ground-up for the job of distributing time and acting as a time client in the world of high frequency trading where accuracy is paramount. Using TimeKeeper as a software appliance to serve time or using a time appliance built using the TimeKeeper software means you’re going to see next-generation performance from it.

Network traffic - scalability

NTP exchanges are initiated by the client - it sends a request to the server and the server responds. For every time update of a client there are 2 messages on the network. PTP time updates are done with two messages normally and are sent out by the master as broadcast messages. Slaves occasionally (sometimes every update) send a message to the master and receive a response in order to compute the one-way delay between the client and master. Generally, as the number of clients scales up you’ll see less traffic on the network using PTP compared to NTP.

Only in very large installations is the additive traffic a signficant concern, and even then, it’s rarely an issue. In most cases the difference in traffic won’t be noticed at all given the update frequency. Both NTP and PTP tend to peak at one update per second in most deployments.

NTP is also a unicast protocol in most cases. That’s a point-to-point UDP transaction. PTP defaults to a multicast protocol - so broadcast messages are sent across the network for every exchange. PTP can have a much heavier footprint since broadcast messages are going to be delivered everywhere.

With N clients on the network using NTP you can expect to see:

2*N packets per time update.

With N clients on the network using PTP you can expect to see:

2 + 2*N packets per time update.

Multicast headaches, network policy and ports

As mentioned above, PTP is multicast.  That can be a hassle to adminster because it can generate extra traffic and requires special rules to forward between network segments - especially between distant sites. NTP is unicast, requires no special routing rules, and only the sender and intended recipient have to see or handle those packets.

The UDP port used for NTP (port 123) is often already open and network administrators know what it is, as it’s been a standard on the internet for decades. PTP uses 2 UDP ports (it also has a raw ethernet mode, but we’re not concerned with that here) - port 319 and port 320.  They’re broadcast ports so they require rules for forwarding and multiple-hop connections. It’s another set of ports to open up that may be blocked on your network. PTP does have a unicast mode that can make it more NTP-like in behavior, though.

Hardware assist

Commodity network cards that can assist in time synchronization have started appearing on the market.  In fact - they’re sometimes built into the motherboards of computers as standard NICs.

Some cards know what PTP is and can only assist with PTP packets. Other can assist in timestamping any packet, whether it is PTP, NTP, or any packet you like.

Some current generation 1G Intel cards (82580 chips) can timestamp any packet - and TimeKeeper takes advantage of that. The 10G Intel cards support hardware timestamps in the silicon but as of this writing no Linux driver exists to take advantage of that. That means you can get hardware assistance with both NTP and PTP - so there’s no tradeoff.

The latest (as of this writing) Solarflare and Mellanox cards include hardware timestamps for PTP packets only.

The assistance from NICs can increase the synchronization accuracy a great deal - an order of magnitude sometimes depending on the software implementation. It can bring accuracy down to well below 1 microsecond. Our tests across the hardware timestamping NICs available (both NTP and PTP) show about 250 nanosecond to 500 nanosecond accuracy.

Quiet network vs. busy network

PTP performs best when run on a quiet network - perhaps even a subnet dedicated to time synchronization only. The reason is that PTP clients may only query the round-trip time of a packet on the network occasionally and assumes that this value does not change very much or very often.

With the PTP protocol, a slave must explicitly request round-trip timing from the master in a special message and wait for the response. In the NTP protocol the client is able to calculate the round-trip delay on every every message since each exchange reliably provides all of the information. This means that NTP is able to use that round-trip delay to correctly compute the current time when a message is received. It can also determine if an NTP query has run into a delay and might be inaccurate.  Having access to this information as part of the protocol means NTP can discard bad values very easily.  PTP clients, on the other hand, may rely on possibly old and inaccurate estimates of the travel time of the master’s sync message to compute the current time. For that reason PTP might not be the best choice on a shared network with a great deal of traffic that could delay time synchronization messages.

A particular implementation of PTP can choose to request a response from the server on every single time update and emulate NTP’s behavior. That makes detecting and correcting for errors more feasible but it is not required by the protocol itself.  TimeKeeper does operate in this way but not all implementations do.


PTP has a built-in mechanism for handling failure of a server and using another.  How that’s done is defined in the PTP “Best Master Clock Algorithm” (BMC or BMCA). This algorithm allows multiple servers to broadcast time on the same network, but all clients will eventually select and use the same server.  If the client implementation obeys the PTP protocol fully, when one server fails or self-reported accuracy is reduced the clients will begin using another. This also assumes the server can correctly identify its own accuracy.

While the BMCA is helpful, it can be insufficient in practice. A specific failover scenario may be desired, but the BMCA may behave differently based on the state of any existing grandmasters at the time of failure.  Failover between PTP domains and specific Ethernet channels is also outside the domain of the algorithm.

NTP has no builtin (protocol) method for failover or selecting a new source based on accuracy. The University of Delaware version allows you to specify multiple servers that all contribute to determining the time.  When one fails the remaining ones are used but that’s often not what’s needed in environments that require a highly accurate sync.

TimeKeeper allows for failing over from a NTP source based on accuracy and the health of the time source.  In this case the implementation makes up for some of the limits of the protocol - and even allows failing over between multiple NTP and PTP sources. It will also use the BMCA when it can.

Here’s an example of how to handle failover with TimeKeeper:

SOURCE2() { NTPSERVER=internalhost1; }
SOURCE3() { NTPSERVER=internalhost2; IFACE=eth7; }

Here TimeKeeper will track PTP on domain 30 via the default route, and use the BMC algorithm to identify the best grandmaster. If that fails, due to the grandmasters going offline or an Ethernet failure, it will fail over to SOURCE1, which is PTP on a specific Ethernet interface on a separate domain. Should that fail, there are two backup NTP servers.  (TimeKeeper can also cross check these sources and reject even the primary PTP source if it appears to be behaving strangely, even if the BMCA has identified a specific server.)

Comparing with real numbers

No matter the implementation - you need real performance numbers to be sure which is better for your configuration. It’s always best to run NTP and PTP alongside one another at the same time, under the same network load, even through the same network interface, to compare the performance of each.  Any implementation that doesn’t allow you to test like that is deficient and hampers you quite a bit in making an informed decision.

Similar to the above example, a validation of PTP and NTP at the same time can be set up easily:

SOURCE1() { NTPSERVER=internalhost1; IFACE=eth7; }

This will cause TimeKeeper to track both sources and provide accuracy information about how they both behave, at the same time, on the same Ethernet link, under the same load. Analysis of the resulting sync data makes the decision easy.

If you’ve got questions, or need more details on selecting the best fit for your environment, contact us at