Determine durations with monotonic clocks if available

Re:Determine durations with monotonic clocks if available by thxg on Monday January 30, 2023 @08:58AM (#34579619)

> Ah yes, portability.

On Linux it can be argued that CLOCK_MONOTONIC_RAW should be used for durations. From the Linux man page:

       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 or the incremental adjustments per‐
              formed by adjtime(3).  This clock  does  not  count
              time that the system is suspended.

There is also CLOCK_BOOTTIME to keep counting time while suspended:

       CLOCK_BOOTTIME (since Linux 2.6.39; Linux-specific)
              A  nonsettable  system-wide clock that is identical
              to CLOCK_MONOTONIC, except that  it  also  includes
              any time that the system is suspended.  This allows
              applications to get a suspend-aware monotonic clock
              without  having  to  deal with the complications of
              CLOCK_REALTIME, which may have  discontinuities  if
              the  time is changed using settimeofday(2) or simi‐
              lar.

[ Parent | on HN ]

Re:Determine durations with monotonic clocks if available by AnIdiotOnTheNet on Monday January 30, 2023 @09:32AM (#34579999)

Almost every discussion I've ever seen regarding the use of CLOCK_MONOTONIC_RAW vs CLOCK_MONOTONIC has come down on the side of using CLOCK_MONOTONIC.

As I understanding it, when you're measuring real actual time you want the adjustments because otherwise you'll end up less accurate.

CLOCK_MONOTONIC_RAW is useful if you expect to use some other synchronization.

[ Parent | on HN ]

Re:Determine durations with monotonic clocks if available by touisteur on Monday January 30, 2023 @01:18PM (#34584028)

Beware, while CLOCK_MONOTONIC_RAW has its uses (avoiding clock skew due to NTP when you're synchronising to an external clock) wasn't vDSO'd yet and was slow AF (and causing a syscall...). It's been optimized on later kernels but I was on some RH or LTS branch I was badly bitten by this.

[ Parent | on HN ]