use more precise clocks in precise_time_ns when available

[doy]

Recent versions of Linux include CLOCK_MONOTONIC_RAW, which is more
accurate than CLOCK_MONOTONIC when something like NTP is running. Also,
recent versions of FreeBSD include CLOCK_MONOTONIC_PRECISE, which
produces a more accurate result, according to the man page.

[mstewartgallus]

Personally, I'd prefer to define a MOST_PRECISE_CLOCK definition outside of the rust_precise_time_ns but the code looks okay regardless.

CLOCK_MONOTONIC_RAW has been supported since Linux version 2.6.28 which I think is early enough to support. Do we have a lowest supported version written down somewhere on the wiki?

[thestinger]

Using CLOCK_MONOTONIC_RAW is not necessarily a good idea. It doesn't have as strong a correspondence to the actual passage of time since the hardware counters are not always very accurate. If you need to perform an action every second, using CLOCK_MONOTONIC can result in a more steady rate. If you need to perform an action as close to every 250 nanoseconds as possible, then CLOCK_MONOTONIC_RAW might be a better choice. There's a trade between accuracy and precision.

[doy]

Wouldn't it still be more accurate on the order of seconds, since ntp only checks for the time every few minutes? Or do you mean that the hardware clock tends to be inaccurate enough that the adjusted time is more accurate? I just figured that precise_time_ns would more likely be used for shorter things, where a more stable count would be preferable.

[thestinger]

The adjustments by NTP seen by CLOCK_MONOTONIC are clock skew. It speeds up or slows down the rate seconds elapse to match the passage of time rather than making jumps (it will never go backwards). So a clock adjustment by NTP will be spread out over many minutes, hours or even days.

[doy]

Right, that's what I mean - if NTP notices that the clock is wrong, it adjusts the clock incrementally, even if the cause wasn't due to an inaccurate clock timer (my laptop has the tendency to lose a few seconds when I accidentally let the battery die, for instance). In cases like this, the clock skew would be making the length of a second less accurate, rather than more.

[cpeterso]

For comparison, the OS X and Windows implementations of precise_time_ns call APIs that do not use adjusted time (mach_absolute_time and QueryPerformanceCounter, respectively).

Python PEP 418 has some relevant investigation: http://www.python.org/dev/peps/pep-0418/#operating-system-time-functions

[thestinger]

http://lxr.free-electrons.com/source/arch/x86/vdso/vclock_gettime.c#L236

Another point in favour of CLOCK_MONOTONIC is that doesn't require a system call while CLOCK_MONOTONIC_RAW does. You can verify this with strace.

[cpeterso]

@doy: your FreeBSD CLOCK_MONOTONIC_PRECISE change seems less controversial than the Linux change. If you split your FreeBSD change into its own PR, you can probably get it merged sooner. :)

[alexcrichton]

From the discussion here, it sounds like CLOCK_MONOTONIC is certainly not a bad choice, and it's a little unclear what the benefits are for moving to a different clock (for the general use case).

It also sounds like (from the man page), that CLOCK_MONOTONIC_PRECISE has an expense of the amount of time it takes in order to acquire a more accurate time.

These all are certainly different clocks, and I don't think that there's "one right answer" here. We may want to expand the extra::time api to expose the flavor of clock that you're using (and make a "best attempt" on all platforms), but for now I'm going to close this because it sounds like picking favorites here and there across platforms may not be the best route to take.