4

I am currently trying to talk to a piece of hardware in userspace (underneath the hood, everything is using the spidev kernel driver, but that's a different story).

The hardware will tell me that a command has been completed by indicating so with a special value in a register, that I am reading from. The hardware also has a requirement to get back to me in a certain time, otherwise the command has failed. Different commands take different times.

As a result, I am implementing a way to set a timeout and then check for that timeout using clock_gettime(). In my "set" function, I take the current time and add the time interval I should wait for (usually this anywhere from a few ms to a couple of seconds). I then store this value for safe keeping later.

In my "check" function, I once again, get the current time and then compare it against the time I have saved. This seems to work as I had hoped.

Given my use case, should I be using CLOCK_MONOTONIC or CLOCK_MONOTONIC_RAW? I'm assuming CLOCK_MONOTONIC_RAW is better suited, since I have short intervals that I am checking. I am worried that such a short interval might represent a system-wide outlier, in which NTP was doing alot of adjusting. Note that my target system is only Linux kernels 4.4 and newer.

Thanks in advance for the help.

Edited to add: given my use case, I need "wall clock" time, not CPU time. That is, I am checking to see if the hardware has responded in some wall clock time interval.

References:

It'sPete
  • 5,083
  • 8
  • 39
  • 72
  • 1
    Use CLOCK_MONOTONIC and live happily ever after. It is highly unlikely that few extra machine ops per `gettime` are going to make any difference (as your stuff is user space and can be preempted at any time, even at high priority). – oakad Nov 17 '17 at 03:14
  • @oakad, are you saying that the NTP adjustments that can happen with CLOCK_MONOTONIC should not be a concern? – It'sPete Nov 17 '17 at 17:08
  • 1
    It's not about "concern", it's about a value you're trying to measure. Unless your system is using an expensive hardware clock generator, you can not be sure what tolerance your base clock has and how far off it's definition of "second" drifts off the true second duration. NTP, besides other things, maintains a software PLL to estimate the clock rate adjustments necessary for your system's "seconds" to always be roughly equal to true ones. – oakad Nov 20 '17 at 03:06
  • 2
    When available 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 when `CLOCK_MONOTONIC` is set (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:35
  • 1
    "On x86/x86_64 calling clock_gettime() with CLOCK_MONOTONIC_RAW is slower than using CLOCK_MONOTONIC" was (finally) fixed in the 5.3 kernel via [\[PATCH v7 00/25\] Unify vDSOs across more architectures](https://lore.kernel.org/linux-arm-kernel/20190621095252.32307-1-vincenzo.frascino@arm.com/). – Anon Oct 31 '19 at 05:57

0 Answers0