[Python-Dev] PEP 418: Add monotonic clock

[Guido van Rossum]

On Wed, Mar 28, 2012 at 7:36 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Wed, Mar 28, 2012 at 6:40 PM, Victor Stinner
> <victor.stinner at gmail.com> wrote:
>>> If we're simplifying the idea to only promising a monotonic
>>> clock (i.e. will never go backwards within a given process, but may
>>> produce the same value for an indefinite period, and may jump forwards
>>> by arbitrarily large amounts),
>>
>> I don't know any monotonic clock jumping "forwards by arbitrarily
>> large amounts". Linux can change CLOCK_MONOTONIC speed, but NTP
>> doesn't "jump".
>
> If I understood Glyph's explanation correctly, then if your
> application is running in a VM and the VM is getting its clock data
> from the underlying hypervisor, then suspending and resuming the VM
> may result in forward jumping of the monotonic clocks in the guest OS.
> I believe suspending and hibernating may cause similar problems for
> even a non-virtualised OS that is getting its time data from a
> real-time clock chip that keeps running even when the main CPU goes to
> sleep. (If I *misunderstood* Glyph's explanation, then he may have
> only been talking about the latter case)
>
> Monotonicity is fairly easy to guarantee - you just remember the last
> value you returned and ensure you never return a lower value than that
> for the lifetime of the process. The only complication is thread
> synchronisation, and the GIL (or a dedicated lock for
> Jython/IronPython) can deal with that. Steadiness, on the other hand,
> requires a real world time reference and is thus really the domain of
> specialised hardware like atomic clocks and GPS units rather than
> software that can be suspended and resumed later without changing its
> internal state. There's a reason comms station operators pay
> substantial chunks of money for time & frequency reference devices
> [1].
>
> This is why I now think we only need one new clock function:
> time.monotonic(). It will be the system monotonic clock if one is
> available, otherwise it will be our own equivalent wrapper around
> time.time() that just caches the last value returned to ensure the
> result never goes backwards.

As I said, I think the caching idea is bad. We may have to settle for
semantics that are less than perfect -- presumably if you are doing
benchmarking you just have to throw away a bad result that happened to
be affected by a clock anomaly, and if you are using timeouts, retries
are already part of life.

> With time.monotonic() guaranteed to always be available, there's no
> need for a separate function that falls back to an unconditioned
> time.time() result.

I would love to have only one new clock function in 3.3.

> Regards,
> Nick.
>
> [1] For example:
> http://www.symmetricom.com/products/gps-solutions/gps-time-frequency-receivers/XLi/

-- 
--Guido van Rossum (python.org/~guido)