Savvy engineers use clock_gettime( CLOCK_MONOTONIC, &my_timspec_struct ) to get a continuously increasing epoch-style clock that is "unaffected" by changes to the system clock. (Where the epoch-start is not defined).
However, CLOCK_MONOTONIC is effected by NTP daemon time-changes known as clock "slewing".
By the definition of CLOCK_MONOTONIC, we know that it will never jump backwards. But how does it it mitigate changes by NTP? If the system-clock is suddenly set 5 hours in the past by NTP, does the monotonic clock run a bit slower until it catches up? Maybe it just stops "ticking" until the difference evens-out?
What really does happen? If it's system dependent, what happens on Linux?
I have some timing related code that's failing where the hardware clocks are very flaky. They're being re-adjusted to a GPS source every few minutes. And while this reads like it shouldn't effect CLOCK_MONOTONIC, sometimes (1 in 20) timing related code is just not working. I can't just change everything to CLOCK_MONOTONIC_RAW, because libraries (e.g.: Qt) still use non-raw (Ref: Qt 5.15 source).
It is system-dependent whether there even is a
CLOCK_MONOTONIC. The only clock that POSIX requires implementations to provide isCLOCK_REALTIME. So, what happens on Linux?The docs have this to say about
CLOCK_MONOTONIC:The docs for
adjtime()add:From that we can conclude that
CLOCK_MONOTONICmoves at the same speed as the system clock, which is why it is affected when NTP slews the clock oradjtime()is used, but that it is not updated when the system clock is set. It just keeps counting up, monotonically.