RFC: Time Server Device Worker: Presentation of time stamp during synchronization phase

The OpenCPI team recently resolved Issue #3566 (When using a PPS input the time service provides time that is neither monotonic or correctly phase aligned (#3566) · Issues · OpenCPI / OpenCPI · GitLab) pertaining to the time server providing a monotonic and correctly phased aligned time when using a PPS input. When a PPS signal is detected, the time server worker initiates a process to synchronize time to PPS. During the synchronization process, time is unstable with the fractional element jumping forwards and backwards while adjusting to acquire synchronization. A ‘pps_locked’ signal has been added to the worker to indicate when synchronization has been accomplished. To complete modification of the time server device worker, we are seeking concurrence regarding behavior of the presented time during synchronization. Here are a couple possible options that have arisen but were open to discussion and other suggestions. We’d like to close the topic within a couple weeks to make final modifications.

Option #1:
Use ‘pps_locked’ signal to set the time interface ‘valid’ signal high when the “using_PPS” property is set ‘true’. Time prior to initial PPS detected would be monotonic but free flowing with local clock. During alignment, time unstable but ‘valid’ is ‘false. Following time alignment with PPS, if the PPS is subsequently lost, time will continue using the last calculated fractional increment and remain monotonic. However, incrementation will occur based on the cycle of the local clock which may drift from PPS. When PPS is once again detected, the worker reinitiates the synchronization process which leads to time being temporarily non-monotonic, but ‘valid’ remains ‘false’ until PPS lock occurs. We are seeking responses as to whether or not this is sufficient for most use cases.

Option #2:
Another possible use-case and topic for discussion is a case for presenting monotonic time during the synchronization process when the ‘valid’ is set ‘false’. Whether initial PPS synchronization or re-synchronization following loss of PPS, is there a case where the free flow time using local clock should be presented to the time interface during synchronization? Once synchronization occurs, then the time interface would present the PPS aligned time. This would occur once PPS lock has been indicated but a jump forward or backwards in the fractional time may occur dependent on drift of local clock. It is our understanding that a jump backwards in some use-cases may not be acceptable.

I have consulted with my company OCPI team, and we would prefer Option #2

“We have minor resynch and major resynch algorithms. ‘Minor’ to handle small deviations of local time to 1PPS and ‘major’ to handle large deviations. As such, I believe that this can probably handle instability in PPS while the time server worker is synching to PPS. However, I think it would be less disruptive to simply continue with monotonic time until PPS synchronisation is achieved and then do a (probable) ‘major’ resynch. I do not believe there is an issue in jumping forwards or backwards in fractional time. Thus Option #2 is preferable.”

Prior to receiving your input, the decision was made to support option #1. When PPS is first or subsequently detected, the time service output will not be stable during the synchronization phase, however, the ‘valid’ indicator will be set false to notify application that time is not PPS locked. If it is of great concern, we could possibly readdress option #2 implementation. Regards