Stream: general

Topic: CLOCK_MONOTONIC(_RAW)


RalfJ (Aug 03 2019 at 12:24, on Zulip):

I just heard that CLOCK_MONOTONIC_RAW is the "new better" CLOCK_MONOTONIC (for Linux). it looks like the difference is that _RAW excludes even "gentle" adjustment by NTP (source: https://stackoverflow.com/questions/14270300/what-is-the-difference-between-clock-monotonic-clock-monotonic-raw). libstd seems to use CLOCK_MONOTONIC. should it use _RAW instead?
Cc @gnzlbg

RalfJ (Aug 03 2019 at 12:27, on Zulip):

oh, turns out this was already discussed at https://github.com/rust-lang/rust/issues/37902

RalfJ (Aug 03 2019 at 12:28, on Zulip):

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).

RalfJ (Aug 03 2019 at 12:28, on Zulip):

but OTOH, if you are unlucky enough to use CLOCK_MONOTONIC during NTP adjustment, you might see non-real-time because of the ongoing adjustment...

simulacrum (Aug 03 2019 at 12:33, on Zulip):

We currently have some mutexes and such to make sure that Instant is in fact monotonic anyway, so you won't see non-monotonic behavior no matter what I believe, though definitely possible to see jumpiness

simulacrum (Aug 03 2019 at 12:33, on Zulip):

(just forward, though)

RalfJ (Aug 03 2019 at 13:16, on Zulip):

CLOCK_MONOTONIC is monotonic even during an "adjustment"

RalfJ (Aug 03 2019 at 13:16, on Zulip):

it just slows down / speeds up to make the clock "catch up"

RalfJ (Aug 03 2019 at 13:17, on Zulip):

(also AFAIK use of those mutexes is predicated on actually_monotonic(), which is true for x86 Linux, so they are not used there)

simulacrum (Aug 03 2019 at 13:20, on Zulip):

hm, yeah, might be true for linux

nagisa (Aug 03 2019 at 14:24, on Zulip):

monotonicity problems mostly are an issue on Windows.

nagisa (Aug 03 2019 at 14:27, on Zulip):

Think of CLOCK_MONOTONIC_RAW as pretty much the rdtsc instruction which is not calibrated against a real clock in any way. CLOCK_MONOTONIC will at very least be somewhat calibrated.

RalfJ (Aug 03 2019 at 15:02, on Zulip):

@nagisa I see. I am basically just relaying Keith Packard from this talk where he says that _RAW is the better monotonic precisely because it does not get cllibrated, because calibration introduces its own artifacts

nagisa (Aug 03 2019 at 15:02, on Zulip):

Amusing.

RalfJ (Aug 03 2019 at 15:03, on Zulip):

timestamp: https://youtu.be/MYbm6cFqP80?t=939

Tom Phinney (Aug 03 2019 at 15:36, on Zulip):

Embedded applications that implement control loops will need CLOCK_MONOTONIC_RAW. Consider the problem of a control loop such as PID (proportional-integral-derivative) with a non-zero differential term (rate * △x/△t) . Virtually all implementations require fixed-period sampling and output, with computation during the input-to-output interval. The underlying finite-difference mathematics can't cope with unequally-spaced sample/output intervals; instead a more complex , higher-computation-load, slower-acting Kalman filter usually must be used. In other words, use of CLOCK_MONOTONIC could cause billions of control loops worldwide to screw up during such intervals of adjustment.

RalfJ (Aug 03 2019 at 15:48, on Zulip):

but would a PID loop in Rust use the libstd Instant or something else? Instant is mostly for measuring time, looks like a PID loop actually needs something that triggers it in a constant interval and then if that works properly it does not have to measure anything

nagisa (Aug 03 2019 at 16:35, on Zulip):

embedded applications would indeed use an interrupt fired off some sort of crystal/timer peripheral

gnzlbg (Aug 03 2019 at 16:36, on Zulip):

which linux kernel / glibc version added support for it ?

gnzlbg (Aug 03 2019 at 16:38, on Zulip):

Linux 2.6.28

gnzlbg (Aug 03 2019 at 16:39, on Zulip):

so from the pov of the oldest linux kernel / glibc version that we support we should be able to use it

Tom Phinney (Aug 03 2019 at 16:53, on Zulip):

Since all clocks are imprecise and drift relative to a reference clock, there is always a need for rate adjustment in the local device. The hazard in embedded control applications, as had been demonstrated repeatedly since the advent of computerized control, occurs when the timing is abruptly "corrected" rather than gradually moved from its local view to where it is synchronized to some degree with the reference clock. When such adjustments are gradual, the remaining consideration is the interval over which the correction occurs vs. the gain coefficient of the derivative term in the control loop. Clearly it is useful to know the maximum local-clock adjustment rate when configuring such control loop coefficients.

RalfJ (Aug 03 2019 at 18:40, on Zulip):

so from the pov of the oldest linux kernel / glibc version that we support we should be able to use it

so has it been bumped since the thread I quoted above? up there someone said our oldest supported Linux does not have it

gnzlbg (Aug 05 2019 at 08:22, on Zulip):

You'll have to ask @sfackler , from what I know, we only test against the oldest Ubuntu LTS version, which has something like kernel 4.x right now IIRC. The libc crate supports kernel > 4.x on all linux platforms, and > 5.x on most.

gnzlbg (Aug 05 2019 at 08:22, on Zulip):

I don't know if we have a build job anywhere using Linux 2.6.x, I can't find it.

gnzlbg (Aug 05 2019 at 08:22, on Zulip):

if its not tested anywhere, chances are we are probably incompatible with it in subtle ways already

gnzlbg (Aug 05 2019 at 08:26, on Zulip):

I can't find the minimum supported Linux version documented anywhere, nor do we have any way to support multiple linux versions - AFAICT the minimum supported Linux version "is the oldest one that works"

RalfJ (Aug 05 2019 at 09:30, on Zulip):

According to https://forge.rust-lang.org/platform-support.html we support 2.6.18+

RalfJ (Aug 05 2019 at 09:31, on Zulip):

and IIRC we had a RHEL CI job that tests this?

Pietro Albini (Aug 05 2019 at 09:32, on Zulip):

I don't know if we have a build job anywhere using Linux 2.6.x, I can't find it.

all our dist builders are on centos 5, with linux 2.6.18

RalfJ (Aug 05 2019 at 09:33, on Zulip):

ah right, Centos, no RHEL.
https://github.com/rust-lang/rust/blob/master/src/ci/docker/dist-x86_64-linux/Dockerfile

Last update: Nov 20 2019 at 12:10UTC