reconsider use of CLOCK_MONOTONIC_RAW

[clalancette]

This is a duplicate of ros2/rcl#110, and originally came from a discussion at ros/roscpp_core#55 (comment)

[clalancette]

From my understanding of the clocks, CLOCK_MONOTONIC start from some unspecified time, and is always monotonic (i.e. never goes backwards). However, it can be slewed based on adjtime() (basically NTP). CLOCK_MONOTONIC_RAW is the same, except it will never be slewed. The question we have to answer is what we want rcutils_steady_time_now() to represent. If we want it to represent "system time", plus or minus an offset, then we should use CLOCK_MONOTONIC. If we want it to always march forward at the same rate, we should use CLOCK_MONOTONIC_RAW. This article also has a decent explanation.

[wjwwood]

Hmm, it would be interesting to see what std::chrono and our Windows / macOS code are doing. Given that neither monotonic nor monotonic raw jump out at me as the obvious right behavior for steady (I would suppose it depends on the user's preference), I would lean towards consistency with std::chrono and/or the other platforms.

I will guess that Window's is more like monotonic raw as we have it implemented since it uses the performance ticks to calculate it (I think). It would be great if someone could summarize what the similar functions out there do for "steady".

[clalancette]

OK, here's a summary of what is going on (as far as I can tell):

rcutils_steady_time_now():

• Current implementation on Linux uses CLOCK_MONOTONIC_RAW, meaning it is a time interval based on processor counters (not subject to time adjustment via NTP) (https://stackoverflow.com/questions/14270300/what-is-the-difference-between-clock-monotonic-clock-monotonic-raw)
• Current implementation on Windows uses QueryPerformanceFrequency/QueryPerformanceCounter, which is based on processor counters (not subject to time adjustment) (https://msdn.microsoft.com/en-us/library/windows/desktop/dn553408(v=vs.85).aspx)
• Current implementation on MacOS uses host_get_clock_service(..., SYSTEM_CLOCK, ...), followed by clock_get_time(). I haven't yet found any good documentation on whether the SYSTEM_CLOCK is subject to slewing via NTP or not. For what it is worth, there is another way to do this using mach_absolute_time(), and that is what Python uses for its monotonic implementation (https://bugs.python.org/issue14104)

std::chrono:

• On Linux/GCC, std::chrono::steady_clock uses clock_gettime(CLOCK_MONTONIC), so our current rcutils implementation differs from that (https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/src/c%2B%2B11/chrono.cc#L90) (clang does the same on Linux)
• On Windows, std::chrono::steady_clock wraps the QueryPerformanceCounter API, so our current rcutils implementation mirrors that (https://msdn.microsoft.com/en-us/library/hh874790.aspx)
• On MacOS/clang, std::chrono::steady_clock uses clock_gettime(CLOCK_UPTIME_RAW) if it is available (apparently since MacOS 10.12), and falls back to mach_absolute_time() if not (https://github.com/llvm-project/llvm-project-20170507/blob/master/libcxx/src/chrono.cpp#L132)

There is one other thing to consider, which is time spent during suspend. For instance, on Linux, CLOCK_MONOTONIC does not "tick" during suspend (https://stackoverflow.com/questions/6360210/androidlinux-uptime-using-clock-monotonic), but I believe on Windows, QueryPerformanceCounter does (https://stackoverflow.com/questions/24330496/how-do-i-create-monotonic-clock-on-windows-which-doesnt-tick-during-suspend). Again, MacOS documentation is lacking, so it is hard to tell, but it seems like mach_absolute_time() does not "tick" during suspend. (I just found this PEP, which lays all of this out nicely: https://www.python.org/dev/peps/pep-0418/#monotonic-clocks)

So, with all of the background above, it is worth looking into the expectations of the current users of rcutils_steady_time_now().

1. rcl_get_steady_time()
   • Thin callback wrapper around rcutils_steady_time_now()
   • As far as I can tell, never called in current implementation (excepting tests)
2. rcl_timer_*()
   • Called by several functions in here
   • Timer is wrapped:
     • rclcpp (TimerBase)
       • In turn, used to implemente GenericTimer and WallTimer
     • rclpy (WallTimer)
3. logging_macros.h.em
   • In this case, the logging macros are looking to see if enough time has passed since the last print

So, given all the above, here are my conclusions/recommendations:

1. Using something like CLOCK_MONOTONIC (instead of CLOCK_MONOTONIC_RAW) is probably the correct thing. The reason for it is that local oscillators are not perfect, and do not always line up with the amount of time that has actually passed, and thus having a bit of an adjustment from the outside is probably a good thing.
2. Further, I think it behooves us to follow in the footsteps of std::chrono as @wjwwood points out, to keep expectations the same.
3. Thus, we should change the implementation on Linux to use CLOCK_MONOTONIC, and change the implementation on MacOS to use mach_absolute_time().

This is really long, so I'll quit there. Thoughts?

[wjwwood]

Thus, we should change the implementation on Linux to use CLOCK_MONOTONIC, and change the implementation on MacOS to use mach_absolute_time().

Sounds good to me, though it's a shame that Window's behavior and Linux's behavior might differ. Also I think it is a bit academic because we're unlikely to have many timers which run long enough to be significantly affected by the slewing or not slewing, e.g. a slew of a few microseconds is unlikely to affect a timer for many seconds or even minutes.

[mikaelarguedas]

@clalancette have all the action items of this issue been addressed ? if so should we close this ?

[wjwwood]

No, because we're still using monotonic raw in our linux implementation. Also, we've not updated our macOS code to look like libc++'s std::chrono implementation.

[mikaelarguedas]

Thanks for the summary 👍

[alsora]

Hi, any updates on this?
Is it still on the roadmap?

[clalancette]

It's not something I've had time to work on. Though I would definitely be willing to do a review if someone else can fix the Linux and macOS implementations.