When executing clock_gettime() with CLOCK_MONOTONIC parameter inside a VM on P550, the code returns time without nano-second accuracy (see last 3 digits in the value in below output are 000). Has anyone faced a similar issue? Any fix?
CLOCK_MONOTONIC - "Represents monotonic time”:
precision: 1ns
value : 0000064606.831054000
When we test it on the host OS on P550, we see nano-seconds (see last 3 digits in the value are 884):
CLOCK_MONOTONIC - "Represents monotonic time”:
precision: 1ns
value : 0000148581.249423884
Actually there’s no nano-second accuracy timer on the host. The mswi-mtimer (CPU timer) frequency is 1Mhz:
The reason you see the illusion of nanosecond accuracy is probably due to your have some time synchronization (NTP) daemon running like the default systemd-timesyncd. When NTP time sync is active, the daemon will call ntp_adjtime, and kernel will internally apply some linear equation to the clock in order to compensate for frequency drift, because the clock can’t be precisely 1Mhz, but often something like 0.997Mhz, and can constantly drift up and down (0.998Mhz then 0.996Mhz). The NTP daemon calls kernel to update the parameters of the linear equation constantly, and that’s now you can get usable time, otherwise if you blindly use the clock as 1Mhz, you’ll accumulate errors.
From man page, The CLOCK_MONOTONIC clock is not affected by discontinuous jumps in the system time (e.g., if the system administrator manually changes the clock), but is affected by the incremen‐ tal adjustments performed by [adjtime(3)](https://www.man7.org/linux/man-pages/man3/adjtime.3.html) and NTP.
If you use CLOCK_MONOTONIC_RAW, then you should observe the accuracy is indeed 1us, not 1ns, on the host. Or if you disable systemd-timesyncd or other NTP daemons and reboot, you should see the ns digits (last 3 digits) of CLOCK_MONOTONIC as 0. Equivalently, if you enable NTP daemon in the VM, you’ll start to see the ns digits showing not 0. They are not actually ns accuracy, though, as said above.