TimeKeeper
I used TimeKeeper version 2.12 was used for these tests. TimeKeeper does not save calibration data between runs so there was no calibration data to delete before these tests to get a "cold" start.
Figure 8 shows a 24-hour run of TimeKeeper synchronizing to the GPS and PPS signal.
TimeKeeper very quickly begins to adjust the offset and asymptotically approaching 0. Within 2 minutes the TimeKeeper has adjust the offset from 0.5 seconds to 10 milliseconds and within 3 minutes to below 1 millisecond. Figure 9 shows a detailed view of the correction that TimeKeeper applies on startup and gives a good view of how quickly and predictably TimeKeeper corrects offsets.
Figure 10 shows the last hour of the TimeKeeper server running. Offset from the PPS signal is staying below 1 microsecond.
TimeKeeper Client
Figure 11 shows a TimeKeeper client offset for 24 hours.
Figure 12 shows the offset for the last hour of a 24-hour run. The client system time offset from the PPS is staying below 1 microsecond.
The offset is so small it is difficult to see so Figure 13 shows the last data points for more detail. The measured offset from the PPS on the client is within a few microseconds of 0. This is very near the precision of the server itself shown in the previous section.
There are no abrupt jumps or discontinuities in this graph that would show if TimeKeeper were applying instantaneous corrections to the clock as NTP did in the NTP client graphs. Figure 14 shows how TimeKeeper applies correction on the client. Offset from the correct time asymptotically approaches 0 just as on the server and within a few minutes is below a millisecond with a very predictable curve.
Analysis
Our tests show that TimeKeeper keeps clients synchronized to a server and an optional external time reference to within a few microseconds. It also does not create large time jumps that may create inconsistent application behavior.
Our tests suggest that the NTP server provides current system time to clients rather than its best estimate of correct time. During startup this means clients are chasing a moving target during synchronization rather than a stable source time that is available to the server. This is not the case in the TimeKeeper server which provides a common time reference to clients that it attempts to synchronize with. This means a much faster startup and that there is no moving target during initialization.
NTP uses Linux system calls to adjust and to provide time to applications. It is limited by the flexibility and capability of Linux. TimeKeeper replaces the family of time query system calls (gettimeofday() for example) in Linux with its own so a separate software clock can be maintained rather than relying on Linux to maintain and correct time accurately. For example, Linux will use the APIC clock, HPET clock or other low-resolution devices for timekeeping. TimeKeeper uses the processor-clock frequency TSC instead and overcomes problems with the TSC that normally prohibits software from using it. It does this by monitoring and controlling processor C-state transitions and accounting for clock-speed changes on each CPU core independently and correcting for them internally rather than assuming and requiring that all processors maintain synchronized clocks though hardware.
Imagine a scenario where a server and client are rebooted by an administrator on a Monday morning after an upgrade or crash from the weekend. The system needs to be up and reliable by the time the trading or business day begins since the applications being used require very accurate system time for regulatory compliance, customer service agreements and correct functioning. NTP would not work in this scenario but TimeKeeper would by providing consistent, stable and quick time synchronization.
