this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

zooko
On Thu, Apr 5, 2012 at 7:14 PM, Greg Ewing <[hidden email]> wrote:
>
> 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.

Yep. As far as I can tell, nobody has a use for an unsteady, monotonic clock.

There seem to be two groups of people:

1. Those who think that "monotonic clock" means a clock that never
goes backwards. These people are in the majority. After all, that's
what the word "monotonic" means ¹ . However, a clock which guarantees
*only* this is useless.

2. Those who think that "monotonic clock" means a clock that never
jumps, and that runs at a rate approximating the rate of real time.
This is a very useful kind of clock to have! It is what C++ now calls
a "steady clock". It is what all the major operating systems provide.

The people in class 1 are more correct, technically, and far more
numerous, but the concept from 1 is a useless concept that should be
forgotten.

So before proceeding, we should mutually agree that we have no
interest in implementing a clock of type 1. It wouldn't serve anyone's
use case (correct me if I'm wrong!) and the major operating systems
don't offer such a thing anyway.

Then, if we all agree to stop thinking about that first concept, then
we need to agree whether we're all going to use the word "monotonic
clock" to refer to the second concept, or if we're going to use a
different word (such as "steady clock") to refer to the second
concept. I would prefer the latter, as it will relieve us of the need
to repeatedly explain to newcomers: "That word doesn't mean what you
think it means.".

The main reason to use the word "monotonic clock" to refer to the
second concept is that POSIX does so, but since Mac OS X, Solaris,
Windows, and C++ have all avoided following POSIX's mistake, I think
Python should too.

Regards,

Zooko

¹ http://mathworld.wolfram.com/MonotonicSequence.html
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

Cameron Simpson
On 05Apr2012 21:07, Zooko Wilcox-O'Hearn <[hidden email]> wrote:
| On Thu, Apr 5, 2012 at 7:14 PM, Greg Ewing <[hidden email]> wrote:
| > 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.
|
| Yep. As far as I can tell, nobody has a use for an unsteady, monotonic clock.

Well, not for a wildly unsteady monotonic clock.

| There seem to be two groups of people:
| 1. Those who think that "monotonic clock" means a clock that never
| goes backwards.

I will always fall into this category.

| These people are in the majority. After all, that's
| what the word "monotonic" means ¹ . However, a clock which guarantees
| *only* this is useless.

Sure. I wouldn't have much use for a clock that was only monotonic, but
the word "clock" implies a bit more all on its own, so I am undisturbed.

| 2. Those who think that "monotonic clock" means a clock that never
| jumps, and that runs at a rate approximating the rate of real time.

If they're calling it "monotonic" on that basis alone, they are
wrong. Pure and simple.

| This is a very useful kind of clock to have! It is what C++ now calls
| a "steady clock". It is what all the major operating systems provide.

Sure. So _call_ it a steady clock!

| The people in class 1 are more correct, technically, and far more
| numerous, but the concept from 1 is a useless concept that should be
| forgotten.
|
| So before proceeding, we should mutually agree that we have no
| interest in implementing a clock of type 1. It wouldn't serve anyone's
| use case (correct me if I'm wrong!) and the major operating systems
| don't offer such a thing anyway.

Bah! They are not disjoint sets of clocks!

Linux' CLOCK_MONOTONIC_RAW is both type 1 and type 2.

| Then, if we all agree to stop thinking about that first concept, then
| we need to agree whether we're all going to use the word "monotonic
| clock" to refer to the second concept,

No.

| or if we're going to use a
| different word (such as "steady clock") to refer to the second
| concept. I would prefer the latter, as it will relieve us of the need
| to repeatedly explain to newcomers: "That word doesn't mean what you
| think it means.".

Yes. Resorting to The Princess Bride to resolve bad terminology is only
funny in a movie, and should be a Big Clue that the term is either being
misused or too badly understood.

| The main reason to use the word "monotonic clock" to refer to the
| second concept is that POSIX does so, but since Mac OS X, Solaris,
| Windows, and C++ have all avoided following POSIX's mistake, I think
| Python should too.

No. If it is not monotonic, DO NOT CALL IT monotonic. Call it steady,
perhaps, if it _is_ steady (within some threshold of course).

But CLOCK_MONOTONIC_RAW is type 1 and 2, and is thus a "steady
monotonic" clock. Probably a good choice for both.

We can argue about what characteristics a useful clock has.
And we can argue about what characteristics the various OS clocks
possess.

But please DO NOT invent a new and misleading meaning for a well defined
word. "monotonic" alone is such a word, and means just one thing.
"monotonic clock" means _more_, but isn't always a requirement; "steady
clock" seems more commonly wanted.

Except of course that some participants say "steady clock" is a
nonsensical term.
--
Cameron Simpson <[hidden email]> DoD#743
http://www.cskk.ezoshosting.com/cs/

Politics, n. Strife of interests masquerading as a contest of principles.
- Ambrose Bierce, _The_Devil's_Dictionary_
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

Steven D'Aprano-8
Cameron Simpson wrote:

> | The main reason to use the word "monotonic clock" to refer to the
> | second concept is that POSIX does so, but since Mac OS X, Solaris,
> | Windows, and C++ have all avoided following POSIX's mistake, I think
> | Python should too.
>
> No. If it is not monotonic, DO NOT CALL IT monotonic. Call it steady,
> perhaps, if it _is_ steady (within some threshold of course).

Um, steady is a stronger promise than monotonic. This is a monotonic sequence:

1, 2, 99, 100, 101, 102, 103, 199, 200, 201, 999

But it isn't steady, because it jumps forward.

Here is a non-monotonic sequence:

1, 2, 3, 4, 5, 6, 7, 2, 3, 4, 5, 6, 7, 8

This isn't steady either, because it jumps backwards.

To be steady, it MUST also be monotonic. If you think that it is appropriate
to call a non-monotonic clock "steady", then I think you should tell us what
you mean by "steady but not monotonic".



--
Steven
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

Cameron Simpson
On 06Apr2012 14:31, Steven D'Aprano <[hidden email]> wrote:
| Cameron Simpson wrote:
| > | The main reason to use the word "monotonic clock" to refer to the
| > | second concept is that POSIX does so, but since Mac OS X, Solaris,
| > | Windows, and C++ have all avoided following POSIX's mistake, I think
| > | Python should too.
| >
| > No. If it is not monotonic, DO NOT CALL IT monotonic. Call it steady,
| > perhaps, if it _is_ steady (within some threshold of course).
|
| Um, steady is a stronger promise than monotonic. This is a monotonic sequence:
|
| 1, 2, 99, 100, 101, 102, 103, 199, 200, 201, 999
|
| But it isn't steady, because it jumps forward.

Sure.

| Here is a non-monotonic sequence:
|
| 1, 2, 3, 4, 5, 6, 7, 2, 3, 4, 5, 6, 7, 8
|
| This isn't steady either, because it jumps backwards.
|
| To be steady, it MUST also be monotonic. If you think that it is appropriate
| to call a non-monotonic clock "steady", then I think you should tell us what
| you mean by "steady but not monotonic".

I took steady to mean "never jumps more than x", for "x" being "small",
and allowing small negatives. If steady implies monotonic and people
agree that that is so, I'm happy too, and happy that steady is a better
aspiration than merely monotonic.
--
Cameron Simpson <[hidden email]> DoD#743
http://www.cskk.ezoshosting.com/cs/

I understand a fury in your words, but not your words.  - William Shakespeare
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

Glyph Lefkowitz
In reply to this post by zooko

On Apr 5, 2012, at 8:07 PM, Zooko Wilcox-O'Hearn wrote:

On Thu, Apr 5, 2012 at 7:14 PM, Greg Ewing <[hidden email]> wrote:

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.

Yep. As far as I can tell, nobody has a use for an unsteady, monotonic clock.

There seem to be two groups of people:

1. Those who think that "monotonic clock" means a clock that never
goes backwards. These people are in the majority. After all, that's
what the word "monotonic" means ¹ . However, a clock which guarantees
*only* this is useless.

While this is a popular view on this list and in this discussion, it is also a view that seems to contradict quite a lot that has been written on the subject, and seems contrary to the usual jargon when referring to clocks.

2. Those who think that "monotonic clock" means a clock that never
jumps, and that runs at a rate approximating the rate of real time.
This is a very useful kind of clock to have! It is what C++ now calls
a "steady clock". It is what all the major operating systems provide.

All clocks run at a rate approximating the rate of real time.  That is very close to the definition of the word "clock" in this context.  All clocks have flaws in that approximation, and really those flaws are the whole point of access to distinct clock APIs.  Different applications can cope with different flaws.

There seems to be a persistent desire in this discussion to specify and define these flaws out of existence, where this API really should instead be embracing the flaws and classifying them.  (Victor is doing a truly amazing job with the PEP in that regard; it's already the first web search hit on every search engine I've tried for more than half of these terms.)

Steadiness, in the C++ sense, only applies to most OS clocks that are given the label of "monotonic" during the run of a single program on a single computer while that computer is running at some close approximation of full power.

As soon as you close your laptop lid, the property of steadiness with respect to real local time goes away; the clock stops ticking forward, and only resumes when the lid is opened again.  The thing I'd like to draw attention to here is that when you get one of these clocks, you *do not* get a parallel facility that allows you to identify whether a suspend has happened (or, for that matter, when the wall clock has stepped).  Or at least, nobody's proposed one for Python.  I proposed one for Twisted, <http://twistedmatrix.com/trac/ticket/2424#comment:26>, but you need an event loop for that, because you need to be able to register interest in that event.

I believe that the fact that these clocks are only semi-steady, or only steady with respect to certain kinds of time, is why the term "monotonic clock" remains so popular, despite the fact that mathematical monotonicity is not actually their most useful property.  While these OS-provided clocks have other useful properties, they only have those properties under specific conditions which you cannot necessarily detect and you definitely cannot enforce.  But they all remain monotonic in the mathematical sense (modulo hardware and OS bugs), so it is the term "monotonic" which comes to label all their other, more useful, but less reliable properties.

The people in class 1 are more correct, technically, and far more
numerous, but the concept from 1 is a useless concept that should be
forgotten.

Technically correct; the best kind of correct!

The people in class 1 are only more correct if you accept that mis-applying jargon from one field (mathematics) to replace generally-accepted terminology in another field (software clocks) is the right thing to do.  I think it's better to learn the local jargon and try to apply it consistently.  If you search around the web for the phrase "monotonic clock", it's applied in a sense closest to the one you mean on thousands and thousands of web pages.  "steady clock" generally applies with reference to C++, and even then is often found in phrases like "is_steady indicates whether this clock is a monotonic clock".

Software developers "mis"-apply mathematical terms like "isomorphic", "orthogonal", "incidental", "tangential", and "reflexive" all the time.  Physicists and mathematicians also disagree on the subtleties of the same terms.  Context is everything.

So before proceeding, we should mutually agree that we have no
interest in implementing a clock of type 1. It wouldn't serve anyone's
use case (correct me if I'm wrong!) and the major operating systems
don't offer such a thing anyway.

+1.

Then, if we all agree to stop thinking about that first concept, then
we need to agree whether we're all going to use the word "monotonic
clock" to refer to the second concept, or if we're going to use a
different word (such as "steady clock") to refer to the second
concept. I would prefer the latter, as it will relieve us of the need
to repeatedly explain to newcomers: "That word doesn't mean what you
think it means.".

I don't think anything can (or should) relieve that need.

I am somewhat sympathetic to your preference for "steady" as a better overall term.  It does express the actually-desired property of the clock, even if that property isn't always present; steadiness is not a property that one can be tempted to synthesize, so it removes the temptation to cloud the discussion with that.  Ultimately I don't prefer it, because I think its provenance is less venerable than "monotonic", just because I have a bit more respect for the POSIX committee than the C++ one :-).

However, whatever choice we make in terminology, the documentation for this API must stress what it actually does, and what guarantee it actually provides.  In that sense, my preferred term for this would be the "time.zfnrg_lfj_lpqq(ZFNRG_TIME | ZFNRG_SEMI_STEADY | ZFNRG_SEE_DOCUMENTATION)".

The main reason to use the word "monotonic clock" to refer to the
second concept is that POSIX does so, but since Mac OS X, Solaris,
Windows, and C++ have all avoided following POSIX's mistake, I think
Python should too.

Do you just mean that the APIs don't have "monotonic" in the name?  They all use different words, which strikes me as more of a failure than a success, in the realm of making mistakes about communicating things :).

Regards,

Zooko

¹ http://mathworld.wolfram.com/MonotonicSequence.html
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/glyph%40twistedmatrix.com


_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

Stephen J. Turnbull
On Fri, Apr 6, 2012 at 3:39 PM, Glyph Lefkowitz <[hidden email]> wrote:

> There seems to be a persistent desire in this discussion to specify and
> define these flaws out of existence, where this API really should instead be
> embracing the flaws and classifying them.

That seems to be precisely what Cameron is advocating.

> I think it's better to learn the local jargon and try to apply it
> consistently.  If you search around the web for the phrase "monotonic
> clock", it's applied in a sense closest to the one you mean on thousands and
> thousands of web pages.

But is "a sense" the *same* sense on all of those pages?  If not, then
some people are going to be upset by anything we label a "monotonic"
clock, because it will suffer from some flaw that's unacceptable in
their applications for "monotonic" clocks.
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

Steven D'Aprano-8
In reply to this post by Glyph Lefkowitz
Glyph Lefkowitz wrote:
> On Apr 5, 2012, at 8:07 PM, Zooko Wilcox-O'Hearn wrote:

>> 2. Those who think that "monotonic clock" means a clock that never jumps,
>> and that runs at a rate approximating the rate of real time. This is a
>> very useful kind of clock to have! It is what C++ now calls a "steady
>> clock". It is what all the major operating systems provide.
>
> All clocks run at a rate approximating the rate of real time.  That is very
> close to the definition of the word "clock" in this context.  All clocks
> have flaws in that approximation, and really those flaws are the whole
> point of access to distinct clock APIs.  Different applications can cope
> with different flaws.

I think that this is incorrect.

py> time.clock(); time.sleep(10); time.clock()
0.41
0.41




--
Steven

_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

Paul Moore
On 6 April 2012 11:12, Steven D'Aprano <[hidden email]> wrote:
Glyph Lefkowitz wrote:
On Apr 5, 2012, at 8:07 PM, Zooko Wilcox-O'Hearn wrote:

2. Those who think that "monotonic clock" means a clock that never jumps,
and that runs at a rate approximating the rate of real time. This is a
very useful kind of clock to have! It is what C++ now calls a "steady
clock". It is what all the major operating systems provide.

All clocks run at a rate approximating the rate of real time.  That is very
close to the definition of the word "clock" in this context.  All clocks
have flaws in that approximation, and really those flaws are the whole
point of access to distinct clock APIs.  Different applications can cope
with different flaws.

I think that this is incorrect.

py> time.clock(); time.sleep(10); time.clock()
0.41
0.41

Blame Python's use of CPU time in clock() on Unix for that. On Windows:

>>> time.clock(); time.sleep(10); time.clock()
14.879754156329385
24.879591008462793

That''s a backward compatibility issue, though - I'd be arguing that time.clock() is the best name for "normally the right clock for interval, benchmark or timeout uses as long as you don't care about oddities like suspend" otherwise. Given that this name is taken, I'd argue for time.wallclock. I'm not familiar enough with the terminology to know what to expect from terms like monotonic, steady, raw and the like.

Paul.


_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

Victor Stinner-3
In reply to this post by zooko
> 2. Those who think that "monotonic clock" means a clock that never
> jumps, and that runs at a rate approximating the rate of real time.
> This is a very useful kind of clock to have! It is what C++ now calls
> a "steady clock". It is what all the major operating systems provide.

Python cannot give such guarantee. Extract of time.monotonic()
function proposed in the PEP 418:

"The elapsed time may or may not include time the system spends in
sleep or hibernation; this depends on the operating system."

The C++ Timeout Specification uses the following definition: "Objects
of class steady_clock represent clocks for which values of time_point
advance at a steady rate relative to real time. That is, the clock may
not be adjusted."

Proposed time.monotonic() doesn't respect this definition because
CLOCK_MONOTONIC *is* adjusted (slewed) on Linux.

We might provide a steady clock, but it would be less portable than
the monotonic clock. I'm not sure that we need such clock, which use
case requires a steady and not a monotonic clock? On Linux, I now
prefer to use CLOCK_MONOTONIC (monotonic) than CLOCK_MONOTONIC_RAW
(monotonic and steady as defined by C++) *because* its frequency is
adjusted.

Victor
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

Guido van Rossum
In reply to this post by Paul Moore

I'd like to veto wall clock because to me that's the clock on my wall, i.e. local time. Otherwise I like the way this thread is going.

--Guido van Rossum (sent from Android phone)

On Apr 6, 2012 4:57 AM, "Paul Moore" <[hidden email]> wrote:
On 6 April 2012 11:12, Steven D'Aprano <[hidden email]> wrote:
Glyph Lefkowitz wrote:
On Apr 5, 2012, at 8:07 PM, Zooko Wilcox-O'Hearn wrote:

2. Those who think that "monotonic clock" means a clock that never jumps,
and that runs at a rate approximating the rate of real time. This is a
very useful kind of clock to have! It is what C++ now calls a "steady
clock". It is what all the major operating systems provide.

All clocks run at a rate approximating the rate of real time.  That is very
close to the definition of the word "clock" in this context.  All clocks
have flaws in that approximation, and really those flaws are the whole
point of access to distinct clock APIs.  Different applications can cope
with different flaws.

I think that this is incorrect.

py> time.clock(); time.sleep(10); time.clock()
0.41
0.41

Blame Python's use of CPU time in clock() on Unix for that. On Windows:

>>> time.clock(); time.sleep(10); time.clock()
14.879754156329385
24.879591008462793

That''s a backward compatibility issue, though - I'd be arguing that time.clock() is the best name for "normally the right clock for interval, benchmark or timeout uses as long as you don't care about oddities like suspend" otherwise. Given that this name is taken, I'd argue for time.wallclock. I'm not familiar enough with the terminology to know what to expect from terms like monotonic, steady, raw and the like.

Paul.


_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org


_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

Kristján Valur Jónsson
In reply to this post by Victor Stinner-3
This is the most amusing of discussions.
Teh key sentence here is "the clock may not be adjusted".  Slewing or accelerating a clock is nerely adding to the already present error of the pace of the clock.
Sometimes a clock runs fast, sometimes it runs slow.  This is without any purposeful slewing or accelerating made by the OS.  Notice how the C++ standard specifies nothing about the error of this steady rate, which is however always nonzero.  This implies that the error in the time, or the variations of its rate, are not important to the meaning of the standard.

The thing wich matters here is that the clock progresses forwards, matching the progress of real times, to some (unsopecified) precision.  It must not suddenly jump backwards or forwards because someone changed the timezone.  That is all that is implied.

Since the error of the clock is unspecified, (that is, the error in its rate of progress) it cannot matter if this rate is temporarily adjusted by hand.



K


________________________________________
Frá: python-dev-bounces+kristjan=[hidden email] [python-dev-bounces+kristjan=[hidden email]] fyrir h&#246;nd Victor Stinner [[hidden email]]
Sent: 6. apríl 2012 14:32
To: Zooko Wilcox-O'Hearn
Cc: Python-Dev
Efni: Re: [Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)


The C++ Timeout Specification uses the following definition: "Objects
of class steady_clock represent clocks for which values of time_point
advance at a steady rate relative to real time. That is, the clock may
not be adjusted."

Proposed time.monotonic() doesn't respect this definition because
CLOCK_MONOTONIC *is* adjusted (slewed) on Linux.
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

Kristján Valur Jónsson
In reply to this post by Steven D'Aprano-8
This is the original reason for the original defect (issue 10278)
unix' clock() doesn't actually provide a clock in this sense, it provides a resource usage metric.
K

________________________________________
Frá: python-dev-bounces+kristjan=[hidden email] [python-dev-bounces+kristjan=[hidden email]] fyrir h&#246;nd Steven D'Aprano [[hidden email]]
Sent: 6. apríl 2012 10:12
To: Python-Dev
Efni: Re: [Python-Dev] this is why we shouldn't call it a "monotonic    clock" (was: PEP 418 is too divisive and confusing and should   be postponed)

I think that this is incorrect.

py> time.clock(); time.sleep(10); time.clock()
0.41
0.41




--
Steven

_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/kristjan%40ccpgames.com
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

Cameron Simpson
In reply to this post by Cameron Simpson
On 06Apr2012 15:19, I wrote:
| On 06Apr2012 14:31, Steven D'Aprano <[hidden email]> wrote:
| | Here is a non-monotonic sequence:
| |
| | 1, 2, 3, 4, 5, 6, 7, 2, 3, 4, 5, 6, 7, 8
| |
| | This isn't steady either, because it jumps backwards.
| |
| | To be steady, it MUST also be monotonic. If you think that it is appropriate
| | to call a non-monotonic clock "steady", then I think you should tell us what
| | you mean by "steady but not monotonic".
|
| I took steady to mean "never jumps more than x", for "x" being "small",
| and allowing small negatives. If steady implies monotonic and people
| agree that that is so, I'm happy too, and happy that steady is a better
| aspiration than merely monotonic.

I've had some sleep. _Of course_ steady implies monotonic, or it
wouldn't steadily move forwards.
--
Cameron Simpson <[hidden email]> DoD#743
http://www.cskk.ezoshosting.com/cs/

I went to see a psychiatrist.  He told me I was crazy.  I told him
I wanted a second opinion, so he said, "Ok, you're ugly, too."
        - Rodney Dangerfield
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

Cameron Simpson
In reply to this post by Kristján Valur Jónsson
On 06Apr2012 17:07, Kristj�n Valur J�nsson <[hidden email]> wrote:
| Steven D'Aprano:
| > I think that this is incorrect.
| > py> time.clock(); time.sleep(10); time.clock()
| > 0.41
| > 0.41
|
| This is the original reason for the original defect (issue 10278)
| unix' clock() doesn't actually provide a clock in this sense, it provides a resource usage metric.

Yeah:-( Its help says "Return the CPU time or real time since [...]".
Two very different things, as demonstrated. I suppose neither goes
backwards, but this seems like a classic example of the "useless
monotonic clock" against which Greg Ewing railed.

And why? For one thing, because one can't inspect its metadata to find
out what it does.
--
Cameron Simpson <[hidden email]> DoD#743
http://www.cskk.ezoshosting.com/cs/

Tens of thousands of messages, hundreds of points of view.  It was not called
the Net of a Million Lies for nothing.  - Vernor Vinge, _A Fire Upon The Deep_
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

Victor Stinner-3
> | This is the original reason for the original defect (issue 10278)
> | unix' clock() doesn't actually provide a clock in this sense, it provides a resource usage metric.
>
> Yeah:-( Its help says "Return the CPU time or real time since [...]".
> Two very different things, as demonstrated. I suppose neither goes
> backwards, but this seems like a classic example of the "useless
> monotonic clock" against which Greg Ewing railed.
>
> And why? For one thing, because one can't inspect its metadata to find
> out what it does.

Should I add another key to the result of
time.get_clock_info('clock')? How can we define "clock on Windows"
(almost monotonic and steady clock) vs "clock on UNIX" (CPU time) with
a flag or a value?

Victor
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

Victor Stinner-3
In reply to this post by zooko
> 2. Those who think that "monotonic clock" means a clock that never
> jumps, and that runs at a rate approximating the rate of real time.
> This is a very useful kind of clock to have! It is what C++ now calls
> a "steady clock". It is what all the major operating systems provide.

For the "C++" part, I suppose that you are thinking to:
"Objects of class steady_clock represent clocks for which values of
time_point advance at a steady rate relative to real time. That is,
the clock may not be adjusted."
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3128.html#time.clock.steady

I don't understand this definition. All clocks have a clock drift.
This is just one exception: atomic clocks, but such clocks are rare
and very expensive.

http://www.clocktypes.com/buy_atomic_clocks.html
"Atomic clocks can have a high price, but if you really want to buy
one there is at least one place you can purchase an atomic clock.

    Agilent Technologies (www.agilient.com)
    Model number 5071A atomic clock with a long-term stability better
than 1 x 10-14 price - $50,390"

There is a simple "trick" to get a very cheap steady clock: adjust the
clock manually. Extract of a Wikipedia article:
"More advanced clocks and old mechanical clocks often have some kind
of speed trimmer where one can adjust the speed of the clock and thus
reduce the clock drift. For instance, in pendulum clocks the clock
drift can be manipulated by slightly changing the length of the
pendulum."
http://en.wikipedia.org/wiki/Clock_drift

Or you can use a NTP daemon to adjust automatically using a free farm
of atomic clocks distributed around the world.

So you can get a cheap steady clock if you accept that (OMG!) it can
be adjusted.

Or did I misunderstand "the clock may not be adjusted"?

Victor
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

Stephen J. Turnbull
In reply to this post by Victor Stinner-3
On Fri, Apr 6, 2012 at 11:32 PM, Victor Stinner
<[hidden email]> wrote:

> On Linux, I now prefer
> to use CLOCK_MONOTONIC (monotonic) than CLOCK_MONOTONIC_RAW
> (monotonic and steady as defined by C++) *because* its frequency is
> adjusted.

I don't think that's a reason that should be considered.  There just
doesn't seem to be a single best clock, nor do clocks of similar
character seem to be easy to find across platforms.  So the reasons
I'd like to see are of the form "we should provide CLOCK_MONOTONIC on
Linux as one of our small selection of recommended clocks *because*
the frequency adjustment makes it *most* useful in use-cases A and B,
and it's a *reasonable* choice in use-case C *but* we need to document
that it's a terrible choice for use-case D."

Why do I ask for this kind of argument?  Because there are only a few
people (you, Glyph, Zooko) who seem to have studied clocks closely
enough to be able to evaluate the technical issues involved in "*this*
clock is good/mediocre/unusable in *that* use case."  I'm happy to
leave such judgments up to you guys.  What the rest of us can
contribute is (a) use cases to consider and (b) our opinions on the
relative importance of various use cases in whether we should
recommend a particular clock (ie, provide a named API in the stdlib
for it).
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

Stephen J. Turnbull
In reply to this post by Victor Stinner-3
On Sat, Apr 7, 2012 at 8:47 AM, Victor Stinner <[hidden email]> wrote:

> "Objects of class steady_clock represent clocks for which values of
> time_point advance at a steady rate relative to real time. That is,
> the clock may not be adjusted."
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3128.html#time.clock.steady
>
> I don't understand this definition. All clocks have a clock drift. [[...]]
> you can use a NTP daemon to adjust automatically using a free farm
> of atomic clocks distributed around the world.

That's inside the black box; C++ doesn't care about *how* the clock is
made to be steady by the system.  The system could incorporate an
atomic clock, or it could use NTP to keep the clock closely
corresponding to physical time.  The C++ program doesn't ask, and the
system shouldn't tell.

> So you can get a cheap steady clock if you accept that (OMG!) it can
> be adjusted.
>
> Or did I misunderstand "the clock may not be adjusted"?

I think you are not keeping your context consistent with the viewpoint
of the C++ committee.  To the C++ committee, a steady clock may be
expected to "just keep ticking" as far as the C++ program is
concerned.  What this means is that the clock value is incremented in
sequence: it never goes backward, and it never "jumps over" a possible
time value.  How closely that "ticking" approximates physical time is
Somebody Else's Problem; C++ simply assumes that it does.

In other words, a clock adjustment in the C++ standard means that the
clock's reported time values occur out of sequence.  However, if the
intervals between clock ticks are adjusted by NTP (or by a little old
Swiss watchmaker moving the pendulum bob) in order to improve its
steadiness (ie, accurate correspondence to physical time), C++ doesn't
know about that, and doesn't care.

Amusingly enough, various people's statements about common usage of
"monotonic" notwithstanding, C++'s definition of "monotonic" was
"mathematically monotonic."  Cf. N3092, 20.10.1.
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3092.pdf)

Regards,
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

Paul Moore
In reply to this post by Stephen J. Turnbull
On 7 April 2012 09:12, Stephen J. Turnbull <[hidden email]> wrote:
>
> I don't think that's a reason that should be considered.  There just
> doesn't seem to be a single best clock, nor do clocks of similar
> character seem to be easy to find across platforms.  So the reasons
> I'd like to see are of the form "we should provide CLOCK_MONOTONIC on
> Linux as one of our small selection of recommended clocks *because*
> the frequency adjustment makes it *most* useful in use-cases A and B,
> and it's a *reasonable* choice in use-case C *but* we need to document
> that it's a terrible choice for use-case D."


>From the PEP:

"""
Use cases:

Display the current time to a human (e.g. display a calendar or draw a
wall clock): use system clock, i.e. time.time() or
datetime.datetime.now().
Event scheduler, timeout: time.monotonic().
Benchmark, profiling: time.clock() on Windows, time.monotonic(), or
fallback to time.time()

Functions

To fulfill the use cases, the functions' properties are:

time.time(): system clock, "wall clock".
time.monotonic(): monotonic clock
time.get_clock_info(name): get information on the specified time function
"""

That broadly covers it, I'd say. There are 2 main exceptions I see:
(1) your suggestion of "explain why clock X is a terrible choice for
use case Y" isn't there, although I'm not sure how important that is,
and (2) there's no really good cross-platform option given for
benchmarking/profiling (time.clock() is fine on Windows, but it gives
CPU time on Unix - is that acceptable?)

Also, Victor - you missed time.clock() from "Functions". Was that
deliberate because it's sometimes CPU time? Maybe it should be added
for clarity?

Paul.
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

Cameron Simpson
In reply to this post by Victor Stinner-3
On 07Apr2012 01:47, Victor Stinner <[hidden email]> wrote:
| I don't understand this definition. All clocks have a clock drift.
| This is just one exception: atomic clocks, but such clocks are rare
| and very expensive.

They've got drift too. It is generally very small.

Anecdote: I used to keep my wristwatch (oh, the days of wrist
watches:-) synched to an atomic clock. By walking 4 metres down the hall
from my office to peer into the window of the room with the atomic
clock:-)

Cheers,
--
Cameron Simpson <[hidden email]> DoD#743
http://www.cskk.ezoshosting.com/cs/

Knox's 386 is slick.            Fox in Sox, on Knox's Box
Knox's box is very quick.       Plays lots of LSL. He's sick!
        - Gregory Bond <[hidden email]>,
          (Apologies to John "Iron Bar" Mackin.)
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
12