[Python-Dev] PEP 418: Add monotonic clock

[Scott Dial]

On 3/28/2012 4:48 AM, Victor Stinner wrote:
>>> Scott> monotonic_clock = always goes forward but can be adjusted
>>> Scott> steady_clock = always goes forward and cannot be adjusted
>>>
>>> I don't know if the monotonic clock should be called time.monotonic() or
>>> time.steady(). The clock speed can be adjusted by NTP, at least on Linux
>>> < 2.6.28. (...)
>>
>> You are right that CLOCK_MONOTONIC can be adjusted, so the Boost
>> implementation is wrong. I'm not sure that CLOCK_MONOTONIC_RAW is right
>> either due to suspend -- there doesn't appear to be a POSIX or Linux
>> clock that is defined that meets the "steady" definition.
> 
> The term "adjusted" should be clarified. A clock can be adjusted by
> setting its counter (e.g. setting the system date and time) or by
> changing temporary its frequency (to go faster or slower). Linux only
> adjusts CLOCK_MONOTONIC frequency but the clock is monotonic because
> it always goes forward. The monotonic property can be described as:
> 
> t1=time.monotonic()
> t2=time.monotonic()
> assert t2 >= t1

I agree. The point I was making is that implication of "steady" is that
(t2-t1) is the same (given that t2 and t1 occur in time at the same
relative moments), which is a guarantee that I don't see any platform
providing currently. Any clock that can be "adjusted" in any manner is
not going to meet the "steady" criterion.

>> In that case, I don't think time.try_monotonic() is really needed
>> because we can emulate "time.monotonic()" in software if the platform is
>> deficient.
> 
> As I wrote, I don't think that Python should workaround OS bugs. If
> the OS monotonic clock is not monotonic, the OS should be fixed.

I sympathize with this, but if the idea is that the Python stdlib should
use time.monotonic() for scheduling, then it needs to always be
available. Otherwise, we are not going to use it ourselves, and what
sort of example is that to set?

>> I can't imagine a scenario where you would ask for a
>> monotonic clock and would rather have an error than have Python fill in
>> the gap with an emulation.
> 
> Sorry, I don't understand what you mean with "fill in the gap with an
> emulation". You would like to implement a monotonic clock based on the
> system clock?

If "time.monotonic()" is only sometimes available, then I don't see the
added clock being anything more than an amusement. (In this case, I'd
rather just use clock_gettime() and friends directly, because I have to
be platform aware anyways.) What developers want is a timer that is
useful for scheduling things to happen after predictable interval in the
future, so we should give them that to the best of our ability.

-- 
Scott Dial
scott at scottdial.com