On 2025-09-05, Marc Gonzalez <marc.w.gonzalez@xxxxxxx> wrote: >>> Could you provide some insight as to why CLOCK_MONOTONIC is preferable? >> >> CLOCK_MONOTONIC is tracking in time units as defined by humans. >> CLOCK_MONOTONIC_RAW is tracking in time units defined by some hardware. > > I'm not sure I understand what that implies. > > Eventually, clock_gettime stores whatever it measured in struct timespec, > with tv_sec & tv_nsec, right? I would phrase it differently, but generally speaking, correct. > Are you saying that if I have 2 identical timespecs, > one from CLOCK_MONOTONIC, one from CLOCK_MONOTONIC_RAW, > they might not measure the same time interval? I assume you mean 2 _sets_ of timespecs (so that you have 2 intervals to compare). Correct. > Are you perhaps saying that NTP can (ever so slightly) tweak > a clock to bring its frequency closer to "reality", but if > CLOCK_MONOTONIC_RAW ignores such tweaks, it might count time > slightly too fast or too slow? Correct. This is also valid for other clocks. For example, the kernel logs (printk) and ftrace default to the CPU local clock. These timestamps cannot be compared to CLOCK_MONOTONIC timestamps... just as CLOCK_MONOTONIC_RAW timestamps cannot be compared to CLOCK_MONOTONIC timestamps. There are still reasons why CLOCK_MONOTONIC_RAW might be interesting. For example, if you want a very stable timesource to compare intervals, but do not care so much about the real world time lengths of those intervals (i.e. where is the greatest latency vs. what is the value of the greatest latency). Although even here, I doubt CLOCK_MONOTONIC_RAW has a practical advantage over CLOCK_MONOTONIC. John
