On Tue, Apr 24, 2012 at 6:38 AM, Victor Stinner <victor.stin...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
