7

If I get the time using clock_gettime(CLOCK_MONOTONIC,x), then call yield (e.g. sched_yield()), then get the CLOCK_MONOTONIC time again, will the difference in times include the time the program wasn't running (having yielded), or does CLOCK_MONOTONIC only track the time during which the program is executing? My tests seem to imply the latter, but I'd like to know for sure.

Also, if CLOCK_MONOTONIC doesn't include the time yielded, is there another monotonic timer (ie. one not subject to jumps caused by ntp) that does?

Benubird
  • 18,551
  • 27
  • 90
  • 141

2 Answers2

10

The answer Maxim and comments to that answered the second part of your question, I believe. To expand on the answer for the first part, POSIX 2008 states

If the Monotonic Clock option is supported, all implementations shall support a clock_id of CLOCK_MONOTONIC defined in <time.h>. This clock represents the monotonic clock for the system. For this clock, the value returned by clock_gettime() represents the amount of time (in seconds and nanoseconds) since an unspecified point in the past (for example, system start-up time, or the Epoch). This point does not change after system start-up time.

In particular, note "the monotonic clock for the system". That is, per-system and not per-process, it keeps ticking even though your process is not running. Also, "This point does not change after system start-up time.", which again implies that it keeps ticking regardless of whether a particular process is running or sleeping.

So, either you have found a bug in the Linux implementation, or more likely, in your test program.

janneb
  • 36,249
  • 2
  • 81
  • 97
4

The only difference between CLOCK_REALTIME and CLOCK_MONOTONIC is that the latter can not be set. These clocks are ticking even when your process is not running.

http://www.opengroup.org/onlinepubs/009604599/functions/clock_getres.html

Note that the absolute value of the monotonic clock is meaningless (because its origin is arbitrary), and thus there is no need to set it. Furthermore, realtime applications can rely on the fact that the value of this clock is never set and, therefore, that time intervals measured with this clock will not be affected by calls to clock_settime().

In Linux, surprisingly, CLOCK_MONOTONIC seems to be still affected by NTP adjustments, so that it could go backwards. Hence they added another clock CLOCK_MONOTONIC_RAW:

man clock_gettime

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

Maxim Egorushkin
  • 131,725
  • 17
  • 180
  • 271
  • 4
    I believe those NTP adjustments that are mentioned refer to the *rate* of the clock advancing, not to jumps (`CLOCK_MONOTONIC` won't skip backwards). Note though that `CLOCK_MONOTONIC` stops while the machine is suspended, if that matters. – caf Feb 09 '11 at 11:43
  • 4
    No, CLOCK_MONOTONIC does not go backwards on Linux. NTP adjusts time by a step change only if it's off by more than 1/2 seconds, the monotonic clock is not affected by this. For smaller adjustments, NTP adjusts the clock over time by slightly changing the clock tick rate, and CLOCK_MONOTONIC is affected by this. But, the tick rate will never be negative. – janneb Feb 09 '11 at 11:46
  • This doesn't quite answer my question- I know it stops while the machine is suspended, but does it stop when the _process_ is suspended? – Benubird Feb 09 '11 at 12:19
  • @janneb: thanks for that. Still, I expected CLOCK_MONOTONIC to be not affected by NTP adjustments. Because CLOCK_MONOTONIC start time is undetermined I normally would use this clock for interval (not absolute) timers, i.e. to make sure that the delay is 100ms regardless of NTP adjustments. – Maxim Egorushkin Feb 09 '11 at 12:48
  • 2
    @Maxim: I think the argument is that in most cases the adjusted time would still be preferred for interval measurements, as PC clocks aren't exactly particularly precise. My understanding is that the NTP clock rate adjustments are quite small, and the smaller the closer to the correct time it starts out with. – janneb Feb 09 '11 at 13:14
  • 1
    CLOCK_MONOTONIC is not supposed to go backwards, but apparently has been seen to do so on some systems. See http://stackoverflow.com/questions/3657289/linux-clock-gettimeclock-monotonic-strange-non-monotonic-behavior – Rob_before_edits Nov 19 '11 at 21:06