Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: 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)

 

 

First page Previous page 1 2 Next page Last page  View All Python dev RSS feed   Index | Next | Previous | View Threaded


zooko at zooko

Apr 5, 2012, 8:07 PM

Post #1 of 32 (625 views)
Permalink
this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

On Thu, Apr 5, 2012 at 7:14 PM, Greg Ewing <greg.ewing [at] canterbury> 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
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


cs at zip

Apr 5, 2012, 8:36 PM

Post #2 of 32 (608 views)
Permalink
Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed) [In reply to]

On 05Apr2012 21:07, Zooko Wilcox-O'Hearn <zooko [at] zooko> wrote:
| On Thu, Apr 5, 2012 at 7:14 PM, Greg Ewing <greg.ewing [at] canterbury> 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 <cs [at] zip> 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
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


steve at pearwood

Apr 5, 2012, 9:31 PM

Post #3 of 32 (609 views)
Permalink
Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed) [In reply to]

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
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


cs at zip

Apr 5, 2012, 10:19 PM

Post #4 of 32 (608 views)
Permalink
Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed) [In reply to]

On 06Apr2012 14:31, Steven D'Aprano <steve [at] pearwood> 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 <cs [at] zip> 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
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


glyph at twistedmatrix

Apr 5, 2012, 11:39 PM

Post #5 of 32 (610 views)
Permalink
Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed) [In reply to]

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

> On Thu, Apr 5, 2012 at 7:14 PM, Greg Ewing <greg.ewing [at] canterbury> 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
> Python-Dev [at] python
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/glyph%40twistedmatrix.com


stephen at xemacs

Apr 6, 2012, 1:37 AM

Post #6 of 32 (600 views)
Permalink
Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed) [In reply to]

On Fri, Apr 6, 2012 at 3:39 PM, Glyph Lefkowitz <glyph [at] twistedmatrix> 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
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


victor.stinner at gmail

Apr 6, 2012, 7:32 AM

Post #7 of 32 (602 views)
Permalink
Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed) [In reply to]

> 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
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


guido at python

Apr 6, 2012, 8:42 AM

Post #8 of 32 (597 views)
Permalink
Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed) [In reply to]

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" <p.f.moore [at] gmail> wrote:

> On 6 April 2012 11:12, Steven D'Aprano <steve [at] pearwood> 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
> Python-Dev [at] python
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>
>


kristjan at ccpgames

Apr 6, 2012, 10:04 AM

Post #9 of 32 (599 views)
Permalink
Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed) [In reply to]

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=ccpgames.com [at] python [python-dev-bounces+kristjan=ccpgames.com [at] python] fyrir h&#246;nd Victor Stinner [victor.stinner [at] gmail]
Sent: 6. aprl 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
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


cs at zip

Apr 6, 2012, 3:11 PM

Post #10 of 32 (596 views)
Permalink
Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed) [In reply to]

On 06Apr2012 15:19, I wrote:
| On 06Apr2012 14:31, Steven D'Aprano <steve [at] pearwood> 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 <cs [at] zip> 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
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


victor.stinner at gmail

Apr 6, 2012, 4:47 PM

Post #11 of 32 (595 views)
Permalink
Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed) [In reply to]

> 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
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


stephen at xemacs

Apr 7, 2012, 1:12 AM

Post #12 of 32 (589 views)
Permalink
Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed) [In reply to]

On Fri, Apr 6, 2012 at 11:32 PM, Victor Stinner
<victor.stinner [at] gmail> 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
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


stephen at xemacs

Apr 7, 2012, 2:42 AM

Post #13 of 32 (589 views)
Permalink
Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed) [In reply to]

On Sat, Apr 7, 2012 at 8:47 AM, Victor Stinner <victor.stinner [at] gmail> 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
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


p.f.moore at gmail

Apr 7, 2012, 3:08 AM

Post #14 of 32 (589 views)
Permalink
Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed) [In reply to]

On 7 April 2012 09:12, Stephen J. Turnbull <stephen [at] xemacs> 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
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


cs at zip

Apr 7, 2012, 3:43 PM

Post #15 of 32 (583 views)
Permalink
Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed) [In reply to]

On 07Apr2012 01:47, Victor Stinner <victor.stinner [at] gmail> 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 <cs [at] zip> 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 <gnb [at] bby>,
(Apologies to John "Iron Bar" Mackin.)
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


raymond.hettinger at gmail

Apr 7, 2012, 4:36 PM

Post #16 of 32 (590 views)
Permalink
Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed) [In reply to]

On Apr 7, 2012, at 3:08 AM, Paul Moore wrote:

> 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()


ISTM, an event scheduler should use time.time().
If I schedule an event at 9:30am exactly, I really
want my system time to be one that is used.
Stock traders, for example, need to initiate event based
on scheduled times (i.e. the market opening and closing times).

With respect to benchmarking, the important attribute of time keeping
is that the start and end times be computed from the same offset.
For that purpose, I would want a clock that wasn't subject to adjustment at all,
or if it did adjust, do so in a way that doesn't hide the fact (i.e. spreading-out
the adjustment over a number of ticks or freezing time until a negative
adjustment had caught-up).

Then, there are timeouts, a common use-case where I'm not clear on the
relative merits of the different clocks. Which is the recommended clock
for code like this?

start = time.time()
while event_not_occurred():
if time.time() - start >= timeout:
raise TimeOutException

Ideally, the clock used here shouldn't get adjusted during the timing.
Failing that, the system time (plain old time.time()) seems like a reasonable
choice (I'm not used to seeing the system time just around at an irregular pace).

If time gets set backwards, it is possible to add code to defend against that as long as
the clock doesn't try to hide that time went backwards:

start = time.time()
while event_not_occurred():
now = time.time()
if now < start:
# time went backwards, so restart the countdown
start = now
if now - start >= timeout:
raise TimeOutException

If the new clocks go in (or rather stay in), there should be some clear recommendations
about which ones to use for various use cases. Those recommendations need to be
explained (i.e. under what circumstance would timeout code be better if one abandoned
time.time() in favor of one of the new clocks).

I ask this because adding multiple clocks WILL cause some confusion.
There will be cases where different tools use different clocks, resulting in unexpected interactions.
Victor is proposing that almost every use of time.time() in the standard library be replaced by
monotonic, but I'm at a loss to explain whether the code would actually be better off
or to explain in what circumstances the new code would behave differently in any observable way.

AFAICT, there has never been a reported bug in sched or Queue because they used time.time(),
so I'm reluctant to have those changed without very clear understanding of how the code would
be better (i.e. what negative outcome would be avoided with time.monotonic or somesuch).


Raymond


kristjan at ccpgames

Apr 7, 2012, 5:55 PM

Post #17 of 32 (588 views)
Permalink
Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed) [In reply to]

Thank you for your veto. Still, again for the sake of keeping track of things and such, there is this: http://en.wikipedia.org/wiki/Wall_clock_time and also my original suggestion: http://bugs.python.org/issue10278



In the end, the world shall be ruled by the nomenclaturists.



K

________________________________
Fr: python-dev-bounces+kristjan=ccpgames.com [at] python [python-dev-bounces+kristjan=ccpgames.com [at] python] fyrir hnd Guido van Rossum [guido [at] python]
Sent: 6. aprl 2012 15:42
To: Paul Moore
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)


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" <p.f.moore [at] gmail<mailto:p.f.moore [at] gmail>> wrote:
On 6 April 2012 11:12, Steven D'Aprano <steve [at] pearwood<mailto:steve [at] pearwood>> 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
Python-Dev [at] python<mailto:Python-Dev [at] python>
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org


raymond.hettinger at gmail

Apr 7, 2012, 6:26 PM

Post #18 of 32 (587 views)
Permalink
Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed) [In reply to]

Just to clarify my previous post.

It seems clear that benchmarking and timeout logic would benefit from a clock that cannot be adjusted by NTP.

I'm unclear on whether time.sleep() will be based on the same clock so that timeouts and sleeps are on the same basis.

For scheduling logic (such as the sched module), I would think that NTP adjusted time would be what you want.

I'm also unclear on the interactions between components implemented with different clocks
(for example, if my logs show three seconds between events and a 10-second time-out exception occurs, is that confusing)?


Raymond



_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


cs at zip

Apr 7, 2012, 6:38 PM

Post #19 of 32 (582 views)
Permalink
Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed) [In reply to]

Victor et al,

Just an update note:

I've started marking up clocks with attributes; not yet complete and I
still need to make a small C extension to present the system clocks to
Python space (which means learning to do that, too).

But you can glance over the start on it here:

https://bitbucket.org/cameron_simpson/css/src/tip/lib/python/cs/clockutils.py

Several feature flags and some properties for qualifying clocks.

Still needed stuff includes: C access to clocks, .accuracy being actual
clock precision versus the resolution of the units in the underlying OS
call, a __repr__ and/or __str__ to decode feature bitmaps into useful
strings, .is_*() __getattr__ method to resolve against flags by name
or maybe has_flag(str), etc.

On 07Apr2012 01:16, Victor Stinner <victor.stinner [at] gmail> wrote:
| > | 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?

For clocks I'm going with two feature flags: WALLCLOCK and RUNTIME. The
former indicates a clock that tries to stay in synch with real world time,
and would still advance when the system is suspended or idle; it would
almost certainly need to "step" over a suspend. The latter means system
run time; it accrues only while the system is up. Neither is CPU usage
(so a time.sleep(10) would add 10 seconds to both).

I think resource usage is not a "clock". We could characterise such
timers and counters with a lot of the same metrics we like to use with
clocks, but I do not think they should be returned by a system
purporting to return clocks or clock values.

On 07Apr2012 14:22, I wrote:
| On 06Apr2012 17:30, Glenn Linderman <v+python [at] g> wrote:
| | Hopefully, for each system, the characteristics of each clock can be
| | discovered, and fully characterized in available metadata for the clock...
|
| Victor has asked me to do that for my skeleton, based on the tables he
| has assembled. I'll see what i can do there...

I've started on this, see above.

Victor Stinner <victor.stinner [at] gmail> wrote:
| | - define flags of all clocks listed in the PEP 418: clocks used in
| | the pseudo-code of time.steady and time.perf_counter, and maybe also
| | time.time
|
| I'll make one. It will take a little while. Will post again when ready.

So, new code to glance over as evidence of good faith, if not speed:-(

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

Life is uncertain. Eat dessert first. - Jim Blandy
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


guido at python

Apr 7, 2012, 6:49 PM

Post #20 of 32 (583 views)
Permalink
Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed) [In reply to]

On Sat, Apr 7, 2012 at 6:26 PM, Raymond Hettinger
<raymond.hettinger [at] gmail> wrote:
> Just to clarify my previous post.
>
> It seems clear that benchmarking and timeout logic would benefit from a clock that cannot be adjusted by NTP.
>
> I'm unclear on whether time.sleep() will be based on the same clock so that timeouts and sleeps are on the same basis.

I made the same suggestion earlier but I don't know that anyone did
anything with it. :-( It would be nice to know what clock sleep() uses
on each of the major platforms.

> For scheduling logic (such as the sched module), I would think that NTP adjusted time would be what you want.

In my view, it depends on whether you are scheduling far in the future
(presumably guided by a calendar) or a short time ahead (milliseconds
to hours).

> I'm also unclear on the interactions between components implemented with different clocks
> (for example, if my logs show three seconds between events and a 10-second time-out exception occurs, is that confusing)?

I don't think this is avoidable. The logs will always use time.time()
or a local time derived from it; but we've accepted that for
benchmarking, timeouts and short-interval scheduling, that's not a
good clock to use.

--
--Guido van Rossum (python.org/~guido)
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


cs at zip

Apr 7, 2012, 9:00 PM

Post #21 of 32 (580 views)
Permalink
Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed) [In reply to]

On 07Apr2012 18:49, Guido van Rossum <guido [at] python> wrote:
| On Sat, Apr 7, 2012 at 6:26 PM, Raymond Hettinger
| <raymond.hettinger [at] gmail> wrote:
| > Just to clarify my previous post.
| > It seems clear that benchmarking and timeout logic would benefit
| > from a clock that cannot be adjusted by NTP.

Indeed.
Except for calendar programs setting alarms:-) I suppose they wake up
regularly and consult local time anyway.

| > I'm unclear on whether time.sleep() will be based on the same clock
| > so that timeouts and sleeps are on the same basis.
|
| I made the same suggestion earlier but I don't know that anyone did
| anything with it. :-( It would be nice to know what clock sleep() uses
| on each of the major platforms.

I saw it but didn't know what I could do with it, or even if it can be
found out in any very general sense.

Looking at nanosleep(2) on a recent Linux system says:

POSIX.1 specifies that nanosleep() should measure time against the
CLOCK_REALTIME clock. However, Linux measures the time using the
CLOCK_MONOTONIC clock. This probably does not matter, since the
POSIX.1 specification for clock_settime(2) says that discontinuous
changes in CLOCK_REALTIME should not affect nanosleep():

Setting the value of the CLOCK_REALTIME clock via clock_settime(2)
shall have no effect on threads that are blocked waiting for a relative
time service based upon this clock, including the nanosleep() function;
... Consequently, these time services shall expire when the requested
relative interval elapses, independently of the new or old value
of the clock.

and POSIX's nanosleep(3p) says:

... except for the case of being interrupted by a signal, the suspension
time shall not be less than the time specified by rqtp, as measured by the
system clock CLOCK_REALTIME.

| > For scheduling logic (such as the sched module), I would think that
| > NTP adjusted time would be what you want.
|
| In my view, it depends on whether you are scheduling far in the future
| (presumably guided by a calendar) or a short time ahead (milliseconds
| to hours).

In my view it depends on whether you're working in a calendar or in
elapsed time. The scheduling range ("far in the future" for example)
shouldn't be relevant, for all that "far in the future" is usually done
with a calendar instead of a relative timespans in flat seconds.

Raymond:
| > I'm also unclear on the interactions between components implemented with
| > different clocks (for example, if my logs show three seconds between
| > events and a 10-second time-out exception occurs, is that confusing)?

I don't think it is confusing given some more context; to me it would
usually be a Big Clue that the internal supposedly-wallclock got a big
adjustment between log timestamps. If that shouldn't happen it may be
confusing or surprising...

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

The street finds its own uses for things. - William Gibson
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


solipsis at pitrou

Apr 8, 2012, 3:42 AM

Post #22 of 32 (576 views)
Permalink
Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed) [In reply to]

> | I made the same suggestion earlier but I don't know that anyone did
> | anything with it. :-( It would be nice to know what clock sleep() uses
> | on each of the major platforms.
>
> I saw it but didn't know what I could do with it, or even if it can be
> found out in any very general sense.
>
> Looking at nanosleep(2) on a recent Linux system says:

time.sleep() uses select(), not nanosleep().
select() is not specified to use a particular clock. However, since it
takes a timeout rather than a deadline, it would be reasonable for it
to use a non-adjustable clock :-)
http://pubs.opengroup.org/onlinepubs/9699919799/functions/select.html

Regards

Antoine.


_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


guido at python

Apr 8, 2012, 7:29 AM

Post #23 of 32 (575 views)
Permalink
Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed) [In reply to]

On Sun, Apr 8, 2012 at 3:42 AM, Antoine Pitrou <solipsis [at] pitrou> wrote:
>
>> | I made the same suggestion earlier but I don't know that anyone did
>> | anything with it. :-( It would be nice to know what clock sleep() uses
>> | on each of the major platforms.
>>
>> I saw it but didn't know what I could do with it, or even if it can be
>> found out in any very general sense.
>>
>> Looking at nanosleep(2) on a recent Linux system says:
>
> time.sleep() uses select(), not nanosleep().
> select() is not specified to use a particular clock. However, since it
> takes a timeout rather than a deadline, it would be reasonable for it
> to use a non-adjustable clock :-)
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/select.html

Still, my hope was to cut short a bunch of discussion by declaring
that on every platform, one of the timers available should match the
one used by sleep(), select() and the like -- assuming they all use
the same timer underneath in a typical OS, even though (due to
standardization at different times by different standards bodies) they
aren't all specified the same.

IOW "What's good enough for sleep() is good enough for
user-implemented timeouts and scheduling." as a way to reach at least
one decision for a platform with agreed-upon cross-platform
characteristics that are useful.

What to name it can't be decided this way, although I might put
forward time.sleeptimer().

I personally have a need for one potentially different clock -- to
measure short intervals for benchmarks and profiling. This might be
called time.performancetimer()?

--
--Guido van Rossum (python.org/~guido)
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


solipsis at pitrou

Apr 8, 2012, 8:35 AM

Post #24 of 32 (573 views)
Permalink
Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed) [In reply to]

On Sun, 8 Apr 2012 07:29:30 -0700
Guido van Rossum <guido [at] python> wrote:
>
> What to name it can't be decided this way, although I might put
> forward time.sleeptimer().

interval_timer() ?
I would suggest timer() simply, but it's too close to time().

> I personally have a need for one potentially different clock -- to
> measure short intervals for benchmarks and profiling. This might be
> called time.performancetimer()?

It's called perf_counter() in the PEP:
http://www.python.org/dev/peps/pep-0418/#deferred-api-time-perf-counter

Regards

Antoine.
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


victor.stinner at gmail

Apr 8, 2012, 5:00 PM

Post #25 of 32 (575 views)
Permalink
Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed) [In reply to]

> IOW "What's good enough for sleep() is good enough for
> user-implemented timeouts and scheduling." as a way to reach at least
> one decision for a platform with agreed-upon cross-platform
> characteristics that are useful.

sleep() is implemented in the kernel. The kernel is notified when a
clock is set, and so can choose how to handle time adjustement. Most
"sleeping" functions use the system clock but don't care of clock
adjustement.

> I personally have a need for one potentially different clock -- to
> measure short intervals for benchmarks and profiling. This might be
> called time.performancetimer()?

I deferred this topic because it is unclear to me if such timer has to
count elapsed time during a sleep or not. For example, time.clock()
does on UNIX, whereas it doesn't on Windows. You may need two clocks
for this:
* time.perf_counter(): high-resolution timer for benchmarking, count
time elasped during a sleep
* time.process_time(): High-resolution (?) per-process timer from the
CPU. (other possible names: time.process_cpu_time() or
time.cpu_time())

On Windows, GetProcessTimes() has not a "high-resolution": it has a
accuracy of 1 ms in the best case. QueryPerformanceCounter() counts
time elapsed during a sleep, I don't know for GetProcessTimes.

Victor
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

First page Previous page 1 2 Next page Last page  View All Python dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.