We have had a healthy obsession with clock synchronisation at Corvil since we were founded over 17 years now, or 5.36468E+17 nanoseconds to be more precise. As the rubber hits the road for MiFID implementations in Jan 2018 many firms have been figuring out the best way to implement the accurate time-stamping and traceability called for in RTS 25 (recently named as “Commission Delegated Regulation (EU) 2017/574”).
PTP has emerged as the heir to the now venerable NTP (Network Time Protocol) which has served the needs of aligning clocks for 30 years. While PTP offers hardware assistance to achieve superior accuracy it still lacks the broad support to be considered as a mainstream clock service. And many we have talked to have found, that high costs and hidden complexities continue to restrict the scope of deployment.
The problems often begin with the realisation that enabling servers with PTP is not always as straightforward as they hoped and sometimes not even possible.
By just installing a PTP software daemon, it will not necessarily achieve the accuracy demanded for compliance. This is because PTP was designed to use timestamping with hardware assistance, and without it jitter can be in the 100s of microseconds or even milliseconds. This level of variance blows the jitter budget for RTS-25 straight away. Instead, the server must have a NIC installed that offers PTP with hardware assistance and that often means retrofitting one.
However, hardware support for PTP becomes academic if the operating system itself doesn’t support PTP! Solaris only offers PTP support from version 11.2 and there are many systems out there still running 10.x. Similarly, Microsoft only introduced PTP support in Windows Server 2016.
Many customers we have spoken to have run into the problem above, facing expensive and disruptive upgrades to operating systems and aging hardware platforms. And of course, if you are reliant upon a 3rd party vendor, then all bets are off!
But the journey doesn’t stop there. You must then accurately distribute PTP from a time-synced grandmaster clock to each server, and that often involves further investment and complexity. Ethernet switches and even “low latency” switches (commonly found in trading environments) are generally not equipped with boundary clocks and PTP hardware assistance, that guarantee the accuracy of PTP for compliance.
It’s now well accepted that PTP enabled switches are what you need, but they obviously come with an associated price tag.
Even after making these investments, how do you know everything is working correctly? And are your timestamps traceable to UTC, within the tolerances stipulated by RTS-25?
Over the last couple of years, we’ve helped countless customers identify, diagnose and resolve issues with their PTP implementations ranging from software bugs in switches and grandmasters, to incorrectly deployed hardware and misconfigured switches. Often PTP will appear to be working, despite subtle deployment issues that impact accuracy causing non-compliance.
So, is there a better way of acquiring timestamped transactional data and assuring compliance?
We believe there is - acquire the data from the Network. It’s an approach we adopted years ago and it’s served our customers extremely well with numerous benefits: