In my last blog post, I delved into some of the details of how time synchronisation works, looking at the mechanisms that network time protocols such as NTP and PTP use. In particular, I highlighted that a key difference between these two protocols is the hardware assistance that makes PTP capable of much higher precision time synchronization regular NTP can achieve.
This elicited a variety of responses from readers, from simple expressions of interest to additional commentary on the topic. Some commenters have created, or currently use, deployments of NTP that are hand-tuned to achieve much tighter synchronisation than typical of NTP; in some cases, these can synchronize large numbers of hosts to accuracies of the order of 10us, low enough to be competitive with PTP. Some folks disputed the summary of my previous post on the basis that there are NTP implementations that can leverage the same timestamping hardware in hosts that PTP uses, and so the hardware advantage is available to both protocols. This is a valid point, but is uncharacteristic of NTP in general, whose most widely used implementation is purely software-based.
There was, however, one response I hadn't anticipated and that I would like to address. Some commenters read my highlighting of PTP timestamping hardware as being purely self-interested, as Corvil's products are based on timestamping hardware. An extreme version of this view is that I was attempting to disparage agents and other software-based instrumentation approaches in favor of the appliances we sell. Actually, nothing could be further from the truth.
First, it is important to note that such a misunderstanding puts the cart before the horse: it is true that Corvil's solutions use hardware timestamped capture of network data as their fundamental source of data, and the reason for that is exactly the precision and accuracy of the timestamps we can assign to all captured events. The network is a natural place to capture all communication data in flight, and allows us to capture that data at scale without interrupting it or delaying it in any way. Furthermore, we can capture many logical stages in the lifecycle of transactions as they criss-cross the network from a single vantage point. However, we find accurate timestamping to be important enough that, without it, we would forgo all these other benefits of network data capture.
Secondly, we are not wedded to network-based instrumentation for the sake of it, as some commenters misunderstood. In fact, our interest in PTP is driven to a good degree by the fact that it can distribute accurate time-signals to not just our network appliances, but also to the many other systems from which we can draw data. Corvil can consume and analyze log data from software applications not only in standard syslog format, but also in many other formats. Such application logging is important enough to get right that we have created a framework for ultra-lightweight code instrumentation that several of our customers have integrated into low-latency applications to complement network-based timestamps with application-based ones.
An interesting illustration of a situation that calls for both network timestamps and software timestamps is the requirements imposed on trading firms under the MiFID II regulations in Europe. One important aspect of the regulations is that market participants must report on any events relating to eligible orders and trades. While ESMA has not ventured to give an exhaustive definition of what constitutes a reportable event, the Regulatory Technical Standards specify many concrete examples. In some cases, such as "the exact date and time of the receipt of the order" in RTS 6, these events are naturally network events (reception being a network function). In other cases, such as events recorded "using the business clocks used by trading venue matching engines" in RTS 24, these are software events. Full compliance with MiFID II reporting obligations might need to be met with a mixture of network and software timestamps.
In summary, we believe in using the right tool for the job: where network-based timestamps are the best option, as we have found to be the case in many environments, our hardware-based systems are equipped to take them. Where software events need to be accurately tracked, we have developed and continue to invest in novel ways to capture them accurately and scalably.