time.rs should consider using CLOCK_MONOTONIC_RAW instead of CLOCK_MONOTONIC on Linux

[marcust]

I have reproducible compiler crashes on arm64:

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

thread 'rustc' panicked at 'other was less than the current instant', /buildslave/rust-buildbot/slave/beta-dist-rustc-cross-host-linux/build/src/libstd/sys/unix/time.rs:276
note: Run with `RUST_BACKTRACE=1` for a backtrace.

I'm not really sure where that behavior originates but I suspect the rather old Kernel in combination with the (obscure) hardware I'm running. longsleep/linux-pine64#44 has some more details, basically I see CLOCK_MONOTONIC jumping backwards from time to time. Looking somehow further I see other people used to have the same issue (http://stackoverflow.com/questions/3657289/linux-clock-gettimeclock-monotonic-strange-non-monotonic-behavior)

My Linux Kernel docs say:

       CLOCK_MONOTONIC
              Clock that cannot be set and represents monotonic time since some unspecified starting point.  This clock is not affected by
              discontinuous jumps in the system time (e.g., if the system administrator manually changes the clock), but  is  affected  by
              the incremental adjustments performed by adjtime(3) and NTP.

       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 performed by adjtime(3).

I see this behavior even without OpenNTPd running (so I still suspect that there is a Kernel/HW-Issue), but it might be better to use the Linux specific RAW version of the monotonic clock in order to get strict monotonic increasing values.

I just saw #37137 but as this is on real hardware that might be more relevant. Even when I'm not running anything that obviously does clock adjustments I see this behavior, RAW seems to be very consistently monotonically increasing. As rust is the only thing that I saw complaining so far you maybe want to consider changing this call.

[sfackler]

We can't unconditionally use RAW since we support Linux all the way back to 2.6.18. We can probably use it when supported though.

[Amanieu]

This is definitely a kernel bug: CLOCK_MONOTONIC is definitely not supposed to jump backward. Have you tested CLOCK_MONOTONIC_RAW to see if it exhibits the same behavior on your hardware?

We probably don't want to use CLOCK_MONOTONIC_RAW for Instant since it is not guaranteed to follow real time (e.g. 1 second on CLOCK_MONOTONIC_RAW can be shorter/longer than 1 real second). CLOCK_MONOTONIC is sped up/slowed down by the kernel as necessary to match real time (through NTP).

[marcust]

Yes CLOCK_MONOTONIC_RAW is consistent, even under high loads in my environment.

[Mark-Simulacrum]

It seems that we want to use CLOCK_MONOTONIC and it's usage is intentional. As such, I'm going to close. I think utilizing CLOCK_MONOTONIC_RAW could work, but it'd need to be separately exposed... which isn't too big a problem but would probably look odd API wise, and is best maintained out of std, most likely.

[gnzlbg]

We can't unconditionally use RAW since we support Linux all the way back to 2.6.18.

Is this documented or tested anywhere ?