[Python-Dev] (time) PEP 418 glossary V2

[Jim Jewett]

On Tue, Apr 24, 2012 at 6:38 AM, Victor Stinner
<victor.stinner at gmail.com> wrote:
>> Monotonic
>> ---------

>> This is a particularly tricky term, as there are several subtly
>> incompatible definitions in use.

> Is it a definition for the glossary?

One use case for a PEP is that someone who does *not* have a
background in the area wants to start learning about it.  Even
excluding the general service of education, these people can be
valuable contributors, because they have a fresh perspective.  They
will almost certainly waste some time retracing dead ends, but I would
prefer it be out of a need to prove things to themselves, instead of
just because they misunderstood.

Given the amount of noise we already went through arguing over what
"Monotonic" should mean, I think we have an obligation to provide
these people with a heads-up, even if we don't end up using the term
ourselves.  And I think we *will* use the terms ourselves, if only as
some of the raw os_clock_* choices.

>>  C++ followed the mathematical definition
>>  ... a monotonic clock only promises not to go backwards.
>> ... additional guarantees, some ... required by the POSIX

Confession:

I based the above statements strictly on posts to python-dev, from
people who seemed to have some experience caring about clock details.

I did not find the relevant portions of either specification.[1]
Every time I started to search, I got pulled back to other tasks, and
the update was just delayed even longer.  I still felt it was worth
consolidating the state of the discussion.  Anyone who feels confident
in this domain is welcome to correct me, and encouraged to send
replacement text.

[1]  Can I assume that Victor's links here are the relevant ones, or
is someone aware of additional/more complete references for these
specifications?
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3128.html#time.clock.monotonic
http://pubs.opengroup.org/onlinepubs/000095399/basedefs/time.h.html

>>  The tradeoffs often include lack of a defined Epoch_
>> or mapping to `Civil Time`_,

> I don't know any monotonic with a defined epoch or
> mappable to the civil time.

The very basic "seconds (not even milliseconds) since the beginning of
1970" fits that definition, but doesn't seem to fit what most people
mean by "Monotonic Clock".

I'm still a little fuzzy on *why* it shouldn't count as a monotonic
clock.  Is it technically valid, but a lousy implementation because of
insufficient precision or resolution?  Is it because the functions
used in practice (on a modern OS) to retrieve timestamps don't
guarantee to ignore changes to the system clock?

>> and being more expensive (in `Latency`_, power usage, or duration spent
>> within calls to the clock itself) to use.

> CLOCK_MONOTONIC and CLOCK_REALTIME have the same performances on Linux
> and FreeBSD. Why would a monotonic clock be more expensive?

>>  For example, the clock may
>> represent (a constant multiplied by) ticks of a specific quartz timer
>> on a specific CPU core, and calls would therefore require
>> synchronization between cores.

> I don't think that synchronizing a counter between CPU cores is
> something expensive. See the following tables for details:
> http://www.python.org/dev/peps/pep-0418/#performance

Synchronization is always relatively expensive.  How expensive depends
on a lot of things decides before python was installed.

Looking at the first table there (Linux 3.3 with Intel Core i7-2600 at
3.40GHz (8 cores)), CLOCK_MONOTONIC can be hundreds of times slower
than time(), and over 50 times slower than CLOCK_MONOTONIC_COARSE.  I
would assume that CLOCK_MONOTONIC_COARSE meets the technical
requirements for a monotonic clock, but does less well at meeting the
actual expectations for some combination of
(precision/stability/resolution).


> CLOCK_MONOTONIC and CLOCK_REALTIME use the same hardware clocksource
> and so have the same latency depending on the hardware.

Is this a rule of thumb or a requirement of some standard?

Does that fact that Windows, Mac OS X, and GNU/Hurd don't support
CLOCK_MONOTONIC indicate that there is a (perhaps informal?)
specification that none of their clocks meet, or does it only indicate
that they didn't like the name?

-jJ