Clock Accuracy and Traceability
How Do We Know When Clocks are Synchronized?
Clock synchronization software on an application server computer usually relies on time delivered over the network and so does not have enough information to know when it has accurate time. The best this software can do is estimate how well the system clock is tracking the information from the source. If the information or the estimate is wrong the time will be wrong. While TimeKeeper benefits from years of development and testing to make the estimate reliable and to cross check for and alert on sources of error, it’s not unusual for other software to get the estimate completely wrong (generally by being wildly over-optimistic). For example, the developers of one widely used sort-of-open-source clock sync program have only recently attempted to detect a common network configuration problem that cripples the protocol and makes even modest accuracy impossible; Yet this did not stop the software from claiming high accuracy in such situations. Our experience is that unfounded optimism is widespread in time client software. It is not unusual for customers testing TimeKeeper to complain that their legacy clock sync software “got a much better sync” – when what is really happening is that TimeKeeper is being more realistic.
Above is a graph of TimeKeeper monitoring 20 clock sources at the same time – none of them are that good. That gap between the higher and lower lines is a couple of milliseconds, and with just this information not even TimeKeeper could decide which is right. Single source time clients (most non-TimeKeeper time clients) will show one or the other time and possibly claim high accuracy, depending on which source is chosen. NTPd in multi-source mode will just average them together, assuring that it is wrong. TimeKeeper is able to determine all those clocks are generally operating at the same frequency and it is smart enough to filter out the short term changes in frequency. That’s good and useful information, but which group of clocks has the right offset (the right time)? Unless either you do some hardware testing (which TimeKeeper makes easy) or you know which clocks are reliable and close by on the network, there is no way to know. A lot of our work is helping customers use TimeKeeper analytics to debug and validate their timing network through tools like the multi-clock source graphs and the network map shown at the top of this document. The graph below shows the same situation with three sources, except the green source is a highly accurate GPS clock device, the orange is a PTP source from a server (and quite close) while the blue is a supposedly good source that is steady but with an incorrect offset. In this case, TimeKeeper can show the IT staff what to do, but there is no way to distinguish between these three without making use of the real-time comparison of source illustrated in this graph. How common are sources that differ by milliseconds or more in untuned networks? Very common.
You don’t need GPS clocks on every client to have reliable time – in fact, that would be impractical. But firms that need high quality clock sync should understand that when software clients claim accuracy of 1 microsecond they are, at best, indicating that they believe they can keep system time within 1 microsecond of the adjusted value of the time coming across the network. That adjusted value can easily be wrong. The graphing and data analysis and alerting and end-to-end cross checking in TimeKeeper provide IT managers with the tools they need to assure those numbers correspond to actual clock accuracy.
