I'm using linux api clock_gettime(realtime) to print current time. Check log index ending with 649 and 917.
The real clock time was 1646948676.999081502(at index 649) ,but after 10 secs it suddenly jumped more than >24 hours back and was 1646860487.614595043(index 917).
Main thing i wanna know is what is VuC offset? Will VucOffset affect this realtime? and
Could you please explain what is the reason for time jump? and how can we avoid this?
221649 2022/03/10 02:44:37.000000 PF_CLOCK_SYNC CLOCK_MONOTONIC_RAW=35.228995663 s CLOCK_MONOTONIC=35.228996808 s CLOCK_REALTIME=1646948676.999081502 s
230583 2022/03/10 02:44:46.000000 receiveTMPData data received !!
230584 2022/03/10 02:44:46.000000 TMP::Data received is: -56563019
230585 2022/03/10 02:44:46.000000 TMP:TM_OUTPUT_VUC_OFFSET IS SET!!
231917 2022/03/10 02:44:47.000000 PF_CLOCK_SYNC CLOCK_MONOTONIC_RAW=45.230177586 s CLOCK_MONOTONIC=45.230296214 s CLOCK_REALTIME=1646860487.614595043 s
CLOCK_REALTIME is your classic "wall clock", similar in spirit to what is returned by the older gettimeofday() function call. In particular, it is non-monotonic, which means that it can be expected under some circumstances to 'jump' forward or backwards by an arbitrary amount.
Generally "some circumstances" will be limited to "immediately after the local user calls settimeofday() or by some other mechanism changes his computer's clock setting"; but it is also possible for an automated clock-synchronization (like ntpd or ptpd) to automatically adjust the clock forwards or backwards if it feels the need to do so. (I wouldn't expect either of those to adjust the clock by 24 hours unless they decided that the computer's existing clock-value was 24 hours off from the clock they are trying to synchronize it to, of course).