(time) PEP 418 glossary V2
Glossary ======== Absolute Time ------------- A measurement of time since a specific Epoch_, typically far in the past. Civil Time is the most common example. Typically contrasted with a `Duration`_, as (now - epoch) is generally much larger than any duration that can be appropriately measured with the clock in question. Accuracy -------- The amount of deviation of measurements by a given instrument from true values. See also the wikipedia article on `Accuracy and precision <http://en.wikipedia.org/wiki/Accuracy_and_precision>`_. Inaccuracy in clocks may be caused by lack of `Precision`_, by `Drift`_, or by an incorrect initial setting of the clock (e.g., timing of threads is inherently inaccurate because perfect synchronization in resetting counters is quite difficult). Adjusted -------- Resetting a clock, presumably to the correct time. This may be done either with a `Step`_ or with `Slew`_. Adjusting a clock normally makes it more accurate with respect to the `Absolute Time`_. The cost is that any durations currently being measured will show a `Bias`_. (17 ticks is not the same Duration_ as 17 ticks plus an adjustment.) Bias ---- Lack of accuracy that is systematically in one direction, as opposed to random errors. When a clock is `Adjusted`_, durations overlapping the adjustment will show a Bias. Civil Time ---------- Time of day; external to the system. 10:45:13am is a Civil time; A Duration_ like "45 seconds" is not a Civil time. Provided by existing functions ``time.localtime()`` and ``time.gmtime()``, which are not changed by this PEP. Clock ----- An instrument for measuring time. Different clocks have different characteristics; for example, a clock with nanosecond Precision_ may start to Drift_ after a few minutes, while a less precise clock remained accurate for days. This PEP is primarily concerned with clocks which use a unit of seconds, rather than years, or arbitrary units such as a Tick_. Counter ------- A clock which increments each time a certain event occurs. A counter is strictly monotonic in the mathematical sense, but does not meet the typical definitions of Monotonic_ when used of a computer clock. It can be used to generate a unique (and ordered) timestamp, but these timestamps cannot be mapped to `Civil Time`_; Tick_ creation may well be bursty, with several advances in the same millisecond followed by several days without any advance. CPU Time -------- A measure of how much CPU effort has been spent on a certain task. CPU seconds are often normalized (so that a variable number can occur in the same actual second). CPU seconds can be important when profiling, but they do not map directly to user response time, nor are they directly comparable to (real time) seconds. Drift ----- The accumulated error against "true" time, as defined externally to the system. Drift may be due to imprecision, or to a difference between the average rate at which clock time advances and that of real time. Drift does not include intentional adjustments, but clocks providing `Absolute Time`_ will eventually have to be Adjusted_ to compensate for drift. Duration -------- Elapsed time. The difference between the starting and ending times. Also called Relative Time. Normally contrasted with `Absolute Time`_. While a defined Epoch_ technically creates an implicit duration, this duration is normally too large to be of practical use. Computers can often supply a clock with better Precision_ or higher Resolution_ if they do not have to guarantee meaningful comparisons to any times not generated by the clock itself. Epoch ----- The reference point of a clock. For clocks providing `Civil Time`_, this is often midnight as the day (and year) rolled over to January 1, 1970. A Monotonic_ clock will typically have an undefined epoch (represented as None). Latency ------- Delay. By the time a call to a clock function returns, `Real Time`_ has advanced, possibly by more than the precision of the clock. Monotonic --------- This is a particularly tricky term, as there are several subtly incompatible definitions in use. C++ followed the mathematical definition, so that a monotonic clock only promises not to go backwards. In practice, that is not sufficient to be useful, and no Operating System provides such a weak guarantee. Most discussions of a "Monotonic *Clock*" will also assume several additional guarantees, some of which are explicitly required by the POSIX specification. Within this PEP (and Python), the intended meaning is closer to "the characteristics expected of a monotonic clock in practice". In addition to not moving backward, a Monotonic Clock should also be Steady_, and should be convertible to a unit of seconds. The tradeoffs often include lack of a defined Epoch_ or mapping to `Civil Time`_, and being more expensive (in `Latency`_, power usage, or duration spent within calls to the clock itself) to use. 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. Precision --------- This is another tricky term, as there are several different meanings which are relevant. This PEP (and python) uses the most common meaning from natural sciences: "The amount of deviation among measurements of the same physical value by a single instrument." Imprecision in clocks may be caused by a fluctuation of the rate at which clock time advances relative to `Real Time`_, including intentional clock adjustments by slewing. Note that this is different from the typical computer language meaning of how many digits to show (perhaps better called resolution). Note that this is also different from at least one time-related meaning of precision used in at least some sources. That usage assumes that a clock is an oscillator with a given frequency, and measures the precision with which that oscillator tracks its target frequency, irrespective of how precisely the computer can read the resulting time. Note that "precision" as reported by the clock itself may use yet another definition, and may differ between clocks. Process Time ------------ Time elapsed since the process began. It is typically measured in `CPU time`_ rather than `Real Time`_, and typically does not advance while the process is suspended. Real Time --------- Time in the real world. This differs from `Civil time`_ in that it is not `Adjusted`_, but they should otherwise advance in lockstep. It is not related to the "real time" of "Real Time [Operating] Systems". It is sometimes called "wall clock time" to avoid that ambiguity; unfortunately, that introduces different ambiguities. Resolution ---------- The smallest difference between two physical values that results in a different measurement by a given instrument. Note that the above is in the ideal case; computer clocks in particular are often prone to reporting more resolution than they can actually distinguish. Slew ---- A slight change to a clock's speed, usually intended to correct Drift_ with respect to an external authority. In other words, the Precision_ is (temporarily) intentionally reduced by some `Bias`_, and short Duration_ measurements become less comparable, in return for providing a more accurate `Absolute Time`_. Stability --------- Persistence of accuracy. A measure of expected `Drift`_. Steady ------ A clock with high Stability_ and relatively high Accuracy_ and `Precision`_. In practice, it is often used to indicate a Monotonic_ clock. In theory, "steady" places greater emphasis on the consistency of the duration between subsequent ticks; in practice it may simply indicate more familiarity with C++ than with Posix. Step ---- An instantaneous change in the represented time. Instead of speeding or slowing the clock (`Slew`_), a single offset is permanently added. System Time ----------- Time as represented by the Operating System. Thread Time ----------- Time elapsed since the thread began. It is typically measured in `CPU time`_ rather than `Real Time`_, and typically does not advance while the thread is idle. Tick ---- A single increment of a `Counter`_. Generally used to indicate what the raw hardware provides, before multiplying by a constant to get seconds. Wallclock --------- Also Wall Clock, Wall Time. What the clock on the wall says. This is typically used as a synonym for `Real Time`_; unfortunately, wall time is itself ambiguous, particularly (but not only) between Real Time and `Civil Time`_.
I like the updated glossary - very good summary of the relevant terminology and common points of confusion. One minor gripe below (and it *is* minor, despite the amount of text explaining my point of view...) On Tue, Apr 24, 2012 at 11:58 AM, Jim Jewett <jimjjewett@gmail.com> wrote:
"Not related" is simply not true, as this is the exact meaning of "Real Time" in the term "Real Time Operating System". In the PEP's terms, a Real Time OS is simply an operating system specifically designed to allow developers to meet deadlines expressed as the maximum permitted Real Time Duration between an event occurring and the system responding to that event. The power an RTOS gives you over an ordinary OS is sufficiently low level control over the scheduler (if there's even an entity worth of the name "scheduler" at all) such that you can *demonstrably* meet hard real time deadlines (down to a certain lower limit, generally constrained by hardware). It's a pain to program that way though (and adequately demonstrating correctness gets harder as the code gets more complicated), so you often want to use a dedicated processor for the RTOS bits and a separate processor (with an ordinary OS) for everything else. (There's a good explanation of many of these concepts, include separating the hard realtime parts from everything else, in the Giant Robots of Doom talk from PyCon AU 2010: http://pyvideo.org/video/481/pyconau-2010--hard-real-time-python--or--giant-...) One interesting aspect of using a normal OS is that you can *never* reliably read a Real Time clock in user level code - the scheduler doesn't provide adequate guarantees of responsiveness, so there's always going to be some scheduling jitter in the results. This generally doesn't matter for measuring durations within a machine (since the jitter will, with a sufficiently large number of samples, cancel out between the two measurements), but can be a problem for absolute time measurements that are intended to be compared with high precision across different machines. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Very nice! Two possible clarifications: On Tue, Apr 24, 2012 at 10:58 AM, Jim Jewett <jimjjewett@gmail.com> wrote:
"Conversely, if the clock has experienced `Drift`_, its reports of `Absolute Time`_ will show Bias until the adjustment takes place."
"mapped" -> "algorithmically mapped"
Is it a definition for the glossary?
The "C++ Timeout Specification" doesn't have any monotonic anymore. It has a steady_clock, but it's something different. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3128.html#time.cloc...
What do you mean for POSIX? The definition of CLOCK_MONOTONIC by the POSIX specification is: "The identifier for the system-wide monotonic clock, which is defined as a clock whose value cannot be set via clock_settime() and which cannot have backward clock jumps. The maximum possible clock jump shall be implementation-defined." http://pubs.opengroup.org/onlinepubs/000095399/basedefs/time.h.html time.monotonic() of the PEP 418 gives the same guarantee (cannot go backward, cannot be set), except for "system-wide" (Python cannot give this guarantee because of Windows older than Vista).
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.
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?
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 CLOCK_MONOTONIC and CLOCK_REALTIME use the same hardware clocksource and so have the same latency depending on the hardware. Victor
On Tue, Apr 24, 2012 at 6:38 AM, Victor Stinner <victor.stinner@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.
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.cloc... 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?
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
You mean the time() function? It is the system clock and the system clock is not monotonic because it can jump backward. It is also affected when... the system clock is changed :-)
I chose CLOCK_MONOTONIC instead of CLOCK_MONOTONIC_COARSE because I bet that most people prefer a clock with an higher precision over a faster clock. When the issue #14555 (Add more clock identifiers) will be done, you will be able to call time.clock_gettime(time.CLOCK_MONOTONIC_COARSE) in Python if you need a faster monotonic clock.
It is how these clocks are implemented on Linux. I don't know how they are implemented on other OSes. It was just to say that their performance should be *very close* on Linux.
CLOCK_MONOTONIC requires the clock_gettime() function: clock_gettime() is not available on Windows nor Mac OS X. For Hurd, see: http://www.gnu.org/software/hurd/open_issues/clock_gettime.html The PEP 418 uses other monotonic clocks for Windows and Mac OS X, but GNU/Hurd is the only OS not supporting the new time.monotonic() function. Victor
On Wed, Apr 25, 2012 at 1:19 AM, Jim Jewett <jimjjewett@gmail.com> wrote:
I'm still a little fuzzy on *why* it shouldn't count as a monotonic clock.
So are the people who say it shouldn't count (unless you're speaking of the specific implementation on Unix systems, which can go backward if the admin or NTP decides it should be so). I think they are in general mistaking their use case for a general specification, that's all. Even Glyph cited "what other people seem to think" in supporting the usage where "monotonic" implies "high quality" in some informal sense, although he does have a spec for what high quality means, and AIUI an API for it in Twisted. I think we should just accept that "monotonic" is in more or less common use as a synonym for "high quality", and warn *our* users that the implementers of such clocks may be working to a different spec. I think the revised glossary's description of "monotonic" does that pretty well.
Stephen J. Turnbull wrote:
The fact that the clock is not monotonic is a pretty good reason for it not to count as monotonic. I don't think there's anything fuzzy about that.
I'm sorry, am I missing something here? What use case are you talking about?
Who are these people who think monotonic is a synonym for "high quality"? Why should we pander to their confusion at the cost of those who do understand the difference between monotonic and high quality?
Do I understand correctly that you think it is acceptable to call something monotonic regardless of whether or not it actually is monotonic? If not, I'm not sure I understand what you are suggesting here. -- Steven
This is a good reason why it is no more used in the PEP :-)
Note that "precision" as reported by the clock itself may use yet another definition, and may differ between clocks.
Some C function provides the frequency of the clock (and so its resolution), or directly the resolution, but I don't know any function providing the precision. I thought that clock_getres() is the precision, but I was wrong. clock_getres() is really the resolution announced by the OS, even if the OS may be pessimistic (and so wrong, ex: OpenBSD and Solaris). But Python should not try to workaround OS "bugs". Victor
I like the updated glossary - very good summary of the relevant terminology and common points of confusion. One minor gripe below (and it *is* minor, despite the amount of text explaining my point of view...) On Tue, Apr 24, 2012 at 11:58 AM, Jim Jewett <jimjjewett@gmail.com> wrote:
"Not related" is simply not true, as this is the exact meaning of "Real Time" in the term "Real Time Operating System". In the PEP's terms, a Real Time OS is simply an operating system specifically designed to allow developers to meet deadlines expressed as the maximum permitted Real Time Duration between an event occurring and the system responding to that event. The power an RTOS gives you over an ordinary OS is sufficiently low level control over the scheduler (if there's even an entity worth of the name "scheduler" at all) such that you can *demonstrably* meet hard real time deadlines (down to a certain lower limit, generally constrained by hardware). It's a pain to program that way though (and adequately demonstrating correctness gets harder as the code gets more complicated), so you often want to use a dedicated processor for the RTOS bits and a separate processor (with an ordinary OS) for everything else. (There's a good explanation of many of these concepts, include separating the hard realtime parts from everything else, in the Giant Robots of Doom talk from PyCon AU 2010: http://pyvideo.org/video/481/pyconau-2010--hard-real-time-python--or--giant-...) One interesting aspect of using a normal OS is that you can *never* reliably read a Real Time clock in user level code - the scheduler doesn't provide adequate guarantees of responsiveness, so there's always going to be some scheduling jitter in the results. This generally doesn't matter for measuring durations within a machine (since the jitter will, with a sufficiently large number of samples, cancel out between the two measurements), but can be a problem for absolute time measurements that are intended to be compared with high precision across different machines. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Very nice! Two possible clarifications: On Tue, Apr 24, 2012 at 10:58 AM, Jim Jewett <jimjjewett@gmail.com> wrote:
"Conversely, if the clock has experienced `Drift`_, its reports of `Absolute Time`_ will show Bias until the adjustment takes place."
"mapped" -> "algorithmically mapped"
Is it a definition for the glossary?
The "C++ Timeout Specification" doesn't have any monotonic anymore. It has a steady_clock, but it's something different. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3128.html#time.cloc...
What do you mean for POSIX? The definition of CLOCK_MONOTONIC by the POSIX specification is: "The identifier for the system-wide monotonic clock, which is defined as a clock whose value cannot be set via clock_settime() and which cannot have backward clock jumps. The maximum possible clock jump shall be implementation-defined." http://pubs.opengroup.org/onlinepubs/000095399/basedefs/time.h.html time.monotonic() of the PEP 418 gives the same guarantee (cannot go backward, cannot be set), except for "system-wide" (Python cannot give this guarantee because of Windows older than Vista).
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.
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?
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 CLOCK_MONOTONIC and CLOCK_REALTIME use the same hardware clocksource and so have the same latency depending on the hardware. Victor
On Tue, Apr 24, 2012 at 6:38 AM, Victor Stinner <victor.stinner@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.
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.cloc... 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?
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
You mean the time() function? It is the system clock and the system clock is not monotonic because it can jump backward. It is also affected when... the system clock is changed :-)
I chose CLOCK_MONOTONIC instead of CLOCK_MONOTONIC_COARSE because I bet that most people prefer a clock with an higher precision over a faster clock. When the issue #14555 (Add more clock identifiers) will be done, you will be able to call time.clock_gettime(time.CLOCK_MONOTONIC_COARSE) in Python if you need a faster monotonic clock.
It is how these clocks are implemented on Linux. I don't know how they are implemented on other OSes. It was just to say that their performance should be *very close* on Linux.
CLOCK_MONOTONIC requires the clock_gettime() function: clock_gettime() is not available on Windows nor Mac OS X. For Hurd, see: http://www.gnu.org/software/hurd/open_issues/clock_gettime.html The PEP 418 uses other monotonic clocks for Windows and Mac OS X, but GNU/Hurd is the only OS not supporting the new time.monotonic() function. Victor
On Wed, Apr 25, 2012 at 1:19 AM, Jim Jewett <jimjjewett@gmail.com> wrote:
I'm still a little fuzzy on *why* it shouldn't count as a monotonic clock.
So are the people who say it shouldn't count (unless you're speaking of the specific implementation on Unix systems, which can go backward if the admin or NTP decides it should be so). I think they are in general mistaking their use case for a general specification, that's all. Even Glyph cited "what other people seem to think" in supporting the usage where "monotonic" implies "high quality" in some informal sense, although he does have a spec for what high quality means, and AIUI an API for it in Twisted. I think we should just accept that "monotonic" is in more or less common use as a synonym for "high quality", and warn *our* users that the implementers of such clocks may be working to a different spec. I think the revised glossary's description of "monotonic" does that pretty well.
Stephen J. Turnbull wrote:
The fact that the clock is not monotonic is a pretty good reason for it not to count as monotonic. I don't think there's anything fuzzy about that.
I'm sorry, am I missing something here? What use case are you talking about?
Who are these people who think monotonic is a synonym for "high quality"? Why should we pander to their confusion at the cost of those who do understand the difference between monotonic and high quality?
Do I understand correctly that you think it is acceptable to call something monotonic regardless of whether or not it actually is monotonic? If not, I'm not sure I understand what you are suggesting here. -- Steven
This is a good reason why it is no more used in the PEP :-)
Note that "precision" as reported by the clock itself may use yet another definition, and may differ between clocks.
Some C function provides the frequency of the clock (and so its resolution), or directly the resolution, but I don't know any function providing the precision. I thought that clock_getres() is the precision, but I was wrong. clock_getres() is really the resolution announced by the OS, even if the OS may be pessimistic (and so wrong, ex: OpenBSD and Solaris). But Python should not try to workaround OS "bugs". Victor
participants (5)
-
Jim Jewett -
Nick Coghlan -
Stephen J. Turnbull -
Steven D'Aprano -
Victor Stinner