Is Your Network Time Server ‟Reliable Enough?”
In recent articles, I’ve talked about ESMA’s MiFID II requirements and how this regulation – effective January 2018 – will require trading systems to time stamp key trading event records within an assured level of accuracy… and an assured level of granularity. If you think this only affects European financial markets, you may be surprised that MiFID II will have a global impact. Any investment firm transacting with European-based financial firms or exchanges must also comply with the new clock synchronization requirements. This will be a challenge for many firms.
As I’ve mentioned in a past post, the key technical elements of success include:
- An accurate and reliable source of UTC time
- Accurate and reliable delivery of UTC time from the source to the time stamping location
- A way to monitor time accuracy to prove compliance
I’d like to focus on the UTC time source reliability aspect in this conversation, because in this case more than ever, if the applications rely on good timekeeping, the timekeeping system itself must be reliable in multiple respects. This seems obvious, and with modern timekeeping equipment, it is engineered to be just that. Reliability must be defined in both the availability of the time and the design of the time server supplying it. Here’s what to look for in your UTC referenced network time server:
Timing reliability: Plan A – Simply put, this means time clients (i.e. the trading machines applying UTC accurate time stamps) must be able to obtain accurate UTC time stamps from the UTC time server on demand, every time for the purposes of synchronizing the local client clock. The time server needs to have the capacity to instantly respond to every time request. It should be able to crosscheck the time for accuracy and utilize multiple satellite constellations from which to derive UTC time (for example, maintaining simultaneous tracking of GPS and GLONASS satellites).
Timing reliability: Plan B – The wise network engineer always has a Plan B in the event Plan A fails. In timekeeping, a common Plan B is an atomic clock inside of the time server. Modern time servers rely on getting UTC time from satellites. If access to the satellite signals becomes unavailable for whatever reason, perhaps because of a lightning strike on/near the antenna that damages the antenna or cable, the time server must be able to continue to provide accurate time while the antenna issues are resolved. With a relatively low-cost Rubidium atomic clock installed, the antenna could be disconnected and the time server would remain accurate to the required 100 microseconds or less to UTC for several weeks. This buys the necessary time to resolve the problem and all the while remain compliant to MiFID II.
Design reliability – This is an obvious one, but with key nuances. You should get a time server that sports technology that is of higher quality components and features to ensure continuous operation. An easy reliability feature is a dual-corded, dual-power supply with load sharing and monitoring. Another tip off to a quality product is the operational temperature range. You might be thinking so what, the time server will reside in a data center, not outside. But in truth a wider temperature range means higher quality parts had to be used to meet the server operational specifications, like time accuracy. The same is true for shock and vibration specifications. These more robust environmental features ultimately improve the overall MTBF of the time server, even when it resides in a temperature controlled, non-moving data center.
You will arrive at the point where choosing a network time server with the accuracy and reliability needed to readily comply with stringent timekeeping regulations like MiFID II is a critical decision. You need to ask yourself, how capable and reliable is the UTC network time server for our trading network? Does it scale with our network? What happens if the GPS signal is lost? And perhaps most importantly, what are the ramifications or financial impact of non-compliance? This entry was written by Paul Skoog.
More Info: SyncServer S600