measuring 1/100th seconds, what function?

[Jonas Kölker]

Hello.

I'm doing a Rubik's Cube timer, so I need a function to measure 100ths of
a second. I've browsed through the library reference of python.org, but I
didn't find anything that struck me as 'the perfect fit'. Either it was
system dependent, or it was too grainy (lo-res), or... something else.

so, I need a function which satisfies (in order of importance):

1. It can be used to measure time in the range of up to approximately 1
minute with an accuracy down to 100th-seconds (that's 60000~65536
different values). Better accuracy is a bonus, longer time-frame is a
bigger bonus.

2. it must run on any version of windows upon which python 2.4 can run
(target systems), and run on my system (debian/sarge) __ without the need
for changing the code dependent of environment; any supported
non-Linux/non-windows sytem is a bonus, other supported Linuxes (sp?) is a
bigger bonus (however, I don't expect that it will _not_ work dependent of
distroes)

I'm sorry for asking about such a triviality, but hey, if I can't get it
by RTFM, TFM is buggy ;)

Jonas Kölker

[Peter Hansen]

Jonas Kölker wrote:

I'm doing a Rubik's Cube timer, so I need a function to measure 100ths of
a second. I've browsed through the library reference of python.org, but I
didn't find anything that struck me as 'the perfect fit'. Either it was
system dependent, or it was too grainy (lo-res), or... something else.
It usually helps to specify what you looked at, and perhaps why you
didn't think it was acceptable, to avoid us retracing your steps...
so, I need a function which satisfies (in order of importance):

1. It can be used to measure time in the range of up to approximately 1
minute with an accuracy down to 100th-seconds (that's 60000~65536
different values). Better accuracy is a bonus, longer time-frame is a
bigger bonus.

2. it must run on any version of windows upon which python 2.4 can run

These two constraints cannot be met simultaneously, I believe.
Windows98 does not provide adequate resolution in the timer.

If you are willing to forego Win98 and use only the real Windows OSes,
then I think you get roughly (?) 10ms resolution already with
time.time(). Linux probably gives 1ms resolution or better in pretty
much all cases with time.time().

-Peter

[Grant Edwards]

On 2004-08-10, Jonas Kölker <jo**********@yahoo.com> wrote:

I'm sorry for asking about such a triviality, but hey, if I
can't get it by RTFM, TFM is buggy ;)

Remember to submit a patch when you figure out how to fix the
bug.

--
Grant Edwards grante Yow! .. One FISHWICH
at coming up!!
visi.com

[Tim Peters]

[Jonas Kölker]

I'm doing a Rubik's Cube timer, so I need a function to measure
100ths of a second. ...

Assuming you want to compute wall-time deltas (as opposed to CPU-time
deltas), about the best you can do x-platform is

if sys.platform == "win32":
from time import clock as now
else:
from time import time as now

Then use now(). Unsure which branch Cygwin should take. It's up to
you to determine whether it works "well enough" on each platform you
care about. Note that on a box connected to a network time-correction
service, time.time can appear to "run backwards" briefly at
unpredictable times. The same kind of thing can happen on multi-CPU
boxes -- or not, depending on piles of platform details.

[Bengt Richter]

On Tue, 10 Aug 2004 17:30:14 -0400, Peter Hansen <pe***@engcorp.com> wrote:

Jonas Kölker wrote:

I'm doing a Rubik's Cube timer, so I need a function to measure 100ths of
a second. I've browsed through the library reference of python.org, but I
didn't find anything that struck me as 'the perfect fit'. Either it was
system dependent, or it was too grainy (lo-res), or... something else.

It usually helps to specify what you looked at, and perhaps why you
didn't think it was acceptable, to avoid us retracing your steps...

so, I need a function which satisfies (in order of importance):

1. It can be used to measure time in the range of up to approximately 1
minute with an accuracy down to 100th-seconds (that's 60000~65536
different values). Better accuracy is a bonus, longer time-frame is a
bigger bonus.

2. it must run on any version of windows upon which python 2.4 can run

These two constraints cannot be met simultaneously, I believe.
Windows98 does not provide adequate resolution in the timer.

If you are willing to forego Win98 and use only the real Windows OSes,
then I think you get roughly (?) 10ms resolution already with
time.time(). Linux probably gives 1ms resolution or better in pretty
much all cases with time.time().

On windows I like to use time.clock()
For NT4 with python 2.3.2 (yeah I ought to upgrade both ;-)

from time import time,clock
min(filter(None,[-(time()-time()) for i in xrange(100000)])) 0.0099999904632568359 min(filter(None,[-(clock()-clock()) for i in xrange(100000)])) 5.8666657594130811e-006

IOW, time apparently gets the NT4 basic os time slice delta (10ms),
whereas clock tries to get something better (and it's pretty good).
The filter call is because time()-time() makes a lot of zeroes.
clock() is fast enough not to require it. Not one zero in 100k, anyway. min([-(clock()-clock()) for i in xrange(100000)])

5.8666656741479528e-006

And that's not the minimum resolution of the timer clock() uses, it's
near the minimum time between two readings you can get from python.
Maybe some other loop mechanism can get two two samples faster and
then subtract them. A game for someone ;-)

Regards,
Bengt Richter

[Peter Hansen]

Bengt Richter wrote:

On windows I like to use time.clock() [snip samples showing better resolution than time.time()] IOW, time apparently gets the NT4 basic os time slice delta (10ms),
whereas clock tries to get something better (and it's pretty good).

All true, though the OP said he wanted code that would work on both
platforms (though Tim's response shows how trivial it is to
dynamically pick the best routine).

Presumably there's a human involved somewhere, plus a multitasking
OS with other things going on, and Python as well (not widely known
as a good hard realtime language ;-), so going for the extra
resolution of time.clock() is likely to be an exercise in higher
resolution, but no better accuracy...

-Peter

[Roy Smith]

Tim Peters <ti********@gmail.com> wrote:

Note that on a box connected to a network time-correction
service, time.time can appear to "run backwards" briefly at
unpredictable times.

This will never happen if you're running NTP. NTP does gradual
adjustments to the clock rate to ensure that the system clock is always
monotonically increasing.

It can happen if you're running some kind of time sync service other
than NTP. Why anybody would want to do such a thing is beyond me.

[Dan Christensen]

Roy Smith <ro*@panix.com> writes:

Tim Peters <ti********@gmail.com> wrote:

Note that on a box connected to a network time-correction
service, time.time can appear to "run backwards" briefly at
unpredictable times.

This will never happen if you're running NTP. NTP does gradual
adjustments to the clock rate to ensure that the system clock is always
monotonically increasing.

ntp only works well if your clock rate is very consistent. On all of
the laptops I've used, I get frequent adjustments:

Aug 6 20:30:45 localhost ntpd[911]: time reset -0.472600 s
Aug 5 22:04:57 localhost ntpd[919]: time reset +0.670974 s
Aug 5 22:34:06 localhost ntpd[919]: time reset +0.884625 s
Aug 5 23:13:54 localhost ntpd[919]: time reset -0.376758 s

I don't see any reason in principle ntp couldn't allow a greater
offset between the local machine and the servers, and use gradual
adjustments in this case. But it doesn't.

Dan

[Roy Smith]

In article <87************@uwo.ca>, Dan Christensen <jd*@uwo.ca> wrote:

Roy Smith <ro*@panix.com> writes:

Tim Peters <ti********@gmail.com> wrote:

Note that on a box connected to a network time-correction
service, time.time can appear to "run backwards" briefly at
unpredictable times.

This will never happen if you're running NTP. NTP does gradual
adjustments to the clock rate to ensure that the system clock is always
monotonically increasing.

ntp only works well if your clock rate is very consistent. On all of
the laptops I've used, I get frequent adjustments:

Aug 6 20:30:45 localhost ntpd[911]: time reset -0.472600 s
Aug 5 22:04:57 localhost ntpd[919]: time reset +0.670974 s
Aug 5 22:34:06 localhost ntpd[919]: time reset +0.884625 s
Aug 5 23:13:54 localhost ntpd[919]: time reset -0.376758 s

I don't see any reason in principle ntp couldn't allow a greater
offset between the local machine and the servers, and use gradual
adjustments in this case. But it doesn't.

Dan

I stand corrected. Thank you.