On 06Apr2012 13:14, Greg Ewing <greg.ew...@canterbury.ac.nz> wrote:
| Cameron Simpson wrote:
| > A monotonic clock never returns t0 > t1 for t0, t1 being two adjacent
| > polls of the clock. On its own it says nothing about steadiness or
| > correlation with real world time.
|
| No, no, no.
| This is the strict mathematical meaning of the word "monotonic",
| but the way it's used in relation to OS clocks, it seems to
| mean rather more than that.
It's like my next paragraph didn't exist...
_Quality of implementation_ says that the montonic() call should try to
return a close that is monotonic and _also_ steady and preferably precise.
How these things are balancer is a matter of policy.
To forstall things, right at the bottom of this I'm going to say i agree
with you about objectives, but not about terminology. I maintain that
"monotonic" still means what I said, and that it is the combination of
the word with "clock" that brings in your other criteria.
| A clock whose only guarantee is that it never goes backwards
| is next to useless. For things like benchmarks and timeouts,
| the important thing about a clock that it *keeps going forward*
| at a reasonably constant rate. [...]
| I'm assuming this is what Linux et al mean when they talk
| about a "monotonic clock", because anything else doesn't make
| sense.
This is why I say there's no global understanding. Why assume?
On a Linux box, "man 3 clock_getres" says (sorry, this is a bit wordy):
All implementations support the system-wide real-time clock, which
is identified by CLOCK_REALTIME. Its time represents seconds and
nanoseconds since the Epoch. When its time is changed, timers for
a relative interval are unaffected, but timers for an absolute point
in time are affected.
More clocks may be implemented. The interpretation of the
corresponding time values and the effect on timers is unspecified.
Sufficiently recent versions of glibc and the Linux kernel support
the following clocks:
CLOCK_REALTIME
System-wide real-time clock. Setting this clock requires
appropriate privileges.
CLOCK_MONOTONIC
Clock that cannot be set and represents monotonic time since
some unspecified starting point.
CLOCK_MONOTONIC_RAW (since Linux 2.6.28; Linux-specific)
Similar to CLOCK_MONOTONIC, but provides access to a raw hard-
ware-based time that is not subject to NTP adjustments.
CLOCK_PROCESS_CPUTIME_ID
High-resolution per-process timer from the CPU.
CLOCK_THREAD_CPUTIME_ID
Thread-specific CPU-time clock.
The first paragraph is very clear about real time (wall clock, and what
time.time() does, being "seconds since the epoch"). The CLOCK_MONOTONIC*
modes clearly imply steadiness.
"man 3p clock_getres" (POSIX clock_getres) is even more verbose and general.
| So if we're going to use the term "monotonic" at all, I think we
| should explicitly define it as having this meaning, i.e.
| both mathematically monotonic and steady.
I think if it is too "unsteady" then it is not "time".
So I actually side with you in the requirement for a "clock", but
monotonic alone does not mean that. Quality of implementation _may_ mean
we don't offer something abjectly erratic.
| Failure to be clear
| about this has caused a huge amount of confusion in this thead
| so far.
And burdening the word "monotonic" itself with exciting new meanings
doesn't help. "monotonic clock", sure, _that_ has additional
connotations, but not just the word monotonic.
Cheers,
--
Cameron Simpson <c...@zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/
We had the experience, but missed the meaning. - T.S. Eliot
_______________________________________________
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
