55

According to the Linux man page under Ubuntu

CLOCK_MONOTONIC
      Clock that cannot be set and  represents  monotonic  time  since
      some unspecified starting point.

CLOCK_MONOTONIC_RAW (since Linux 2.6.28; Linux-specific)
      Similar  to  CLOCK_MONOTONIC, but provides access to a raw hard‐
      ware-based time that is not subject to NTP adjustments.

According to the webster online dictionary Monotonic means:

2: having the property either of never increasing or of never decreasing as the values of the independent variable or the subscripts of the terms increase.

In other words, it won't jump backwards. I can see that this would be an important property if you were timing some code.

However, the difference between the normal and raw version isn't clear. Can someone shed some light into how NTP can still affect CLOCK_MONOTONIC?

hookenz
  • 36,432
  • 45
  • 177
  • 286

2 Answers2

48

CLOCK_MONOTONIC never experiences discontinuities due to NTP time adjustments, but it does change in frequency as NTP learns what error exists between the local oscillator and the upstream servers.

CLOCK_MONOTONIC_RAW is simply the local oscillator, not disciplined by NTP. This could be very useful if you want to implement some other time synchronization algorithm against a clock which is not fighting you due to NTP. While ntpd (the reference implementation of NTP protocol and the most widespread NTP daemon) is reputed to be "gentle" with time adjustments, it's more accurate to say it's gentle with the absolute time. It's willing to slew the clock by 500ppm which is pretty dramatic if you're in a position to measure your clock frequency against some other standard.

The utility of CLOCK_MONOTONIC_RAW is going to be limited until facilities like pthread_timedwait_monotonic offer an option to use that timebase.

ximaera
  • 2,348
  • 17
  • 18
Ben Jackson
  • 90,079
  • 9
  • 98
  • 150
  • This answer and the other seem to contradict each other in just how `CLOCK_MONOTONIC` is affected. It would be extremely nice if an authoritative source could be had clearing the difference up. – Dolda2000 Feb 13 '14 at 09:18
  • 2
    @Dolda2000 The answers look consistent to me. `CLOCK_MONOTONIC` is affected by clock *rate* changes (via `adjtimex`) but not jumps. The other answer only talks about the non-jump case. – Ben Jackson Feb 13 '14 at 09:35
  • The rate disciplining you speak of in your answer doesn't seem to me to be the same thing as the rate change cause by `adjtime`; with the former being an adjustment to the rate to match the real rate more properly, and the latter being an intentional aberration from the true rate in order to adjust the absolute time (which should only affect `CLOCK_REALTIME`, rather than `CLOCK_MONOTONIC`, no?). – Dolda2000 Feb 13 '14 at 09:40
  • 1
    @Dolda2000: That's an interesting idea, but that's not how it works. The kernel maintains `CLOCK_REALTIME` because that's a much more popular clock. When you ask for `CLOCK_MONOTONIC` it applies an offset (essentially the boot time). When the clock is stepped the equivalent anti-step is added to the offset so that the monotonic clock is not disrupted. When the clock is adjusted or slewed (the effects of which are blended together in the kernel) there is no corresponding counter-adjustment to the realtime offset, so its frequency changes. – Ben Jackson Feb 13 '14 at 17:11
  • There _was a bug_ that could cause those adjustments to make CLOCK_MONOTONIC jump backwards in time. See: https://stackoverflow.com/a/3657433/3005946 – breakpoint Jun 07 '17 at 00:34
  • What are NTP adjustments ? – Bionix1441 Jan 15 '18 at 09:24
  • 1
    @Bionix1441 Most clocks in computers are cheap and tick too fast/slow. NTP talks to another computer/device which has better time so it can correct for these problems on you local machine by either stepping time with big jumps or making time run faster/slower. See http://www.ntp.org/ntpfaq/NTP-s-algo.htm for details. – Anon Feb 15 '18 at 06:45
  • NB: On x86/x86_64 Linux (at least up to 4.15) the call to read the clock is actually slower with `CLOCK_MONOTONIC_RAW` (because it doesn't use the vDSO and makes a real syscall) in comparison to `CLOCK_MONOTONIC` (see https://stackoverflow.com/a/13096917/9109338 and http://btorpey.github.io/blog/2014/02/18/clock-sources-in-linux/ ). If the overhead of making the call matters to you then this is a platform+architecture specific thing to bear in mind... – Anon Feb 15 '18 at 06:47
  • FYI: On MacOS 14.0, running on M1, CLOCK_MONOTONIC takes about 20ns per call, CLOCK_MONOTONIC _RAW takes 16ns, CLOCK_MONOTONIC_RAW_APPROX about 6ns. CLOCK_MONOTONIC_RAW_APPROX can make about 5,000 calls within 33 microseconds returning the same result on every call. – gnasher729 Aug 08 '23 at 17:36
  • CLOCK_UPTIME_RAW and CLOCK_UPTIME_RAW_APPROX are about 1ns faster per call, but stop counting when the computer sleeps. Which is a good thing or a bad thing, depending on what you want. – gnasher729 Aug 08 '23 at 17:39
3

ntpd doesn't cause the time to jump if the difference is below a certain threshold. adjtime-like adjustment is used instead, affecting both CLOCK_MONOTONIC and CLOCK_REALTIME (but not CLOCK_MONOTONIC_RAW, apparently).

Anton Kovalenko
  • 20,999
  • 2
  • 37
  • 69
  • 1
    Again, embedded systems developers, who may have 2.6.x kernels, need to be aware of the exception to this: https://stackoverflow.com/a/3657433/3005946 – breakpoint Jun 07 '17 at 00:36