calculating system clock resolution

[jUrner@arcor.de]

Hello all

I have the problem of how to calculate the resolution of the system
clock.
Its now two days of head sratching and still there is nothing more than
these few lines on my huge white sheet of paper stiring at me. Lame I
know.

import time

t1 = time.time()
while True:
t2 = time.time()
if t2 > t1:
print t1, t2
# start calculating here
break


BTW t1 and t2 print out equal up to the fraction on my machine. What
does
python know that I don't? A pointer to the source lines where this is
implemented
would even be helpfull to clear this out. Can't seem to find it.

Anyone any ideas?

[MrJean1]

Re: calculating system clock resolution


Depends .... iff you are using Linux, print

cat /proc/cpuinfo

and look for the line "cpu ...Hz: ...". Parsing that would be
straightforward .

Keep in mind, the time.time() function reports the "wall clock" time,
which usually has up to a millisecond resolution, regardless of the CPU
speed.

There is also time.clock(), more about that on
<http://docs.python.org/lib/module-time.html>

/Jean Brouwers


jUrner@arcor.de wrote:[color=blue]
> Hello all
>
> I have the problem of how to calculate the resolution of the system
> clock.
> Its now two days of head sratching and still there is nothing more than
> these few lines on my huge white sheet of paper stiring at me. Lame I
> know.
>
> import time
>
> t1 = time.time()
> while True:
> t2 = time.time()
> if t2 > t1:
> print t1, t2
> # start calculating here
> break
>
>
> BTW t1 and t2 print out equal up to the fraction on my machine. What
> does
> python know that I don't? A pointer to the source lines where this is
> implemented
> would even be helpfull to clear this out. Can't seem to find it.
>
> Anyone any ideas?[/color]

[Serge Orlov]

Re: calculating system clock resolution

jUrner@arcor.de wrote:[color=blue]
> Hello all
>
> I have the problem of how to calculate the resolution of the system
> clock.
> Its now two days of head sratching and still there is nothing more than
> these few lines on my huge white sheet of paper stiring at me. Lame I
> know.
>
> import time
>
> t1 = time.time()
> while True:
> t2 = time.time()
> if t2 > t1:
> print t1, t2
> # start calculating here
> break
>
>
> BTW t1 and t2 print out equal up to the fraction on my machine. What
> does
> python know that I don't? A pointer to the source lines where this is
> implemented
> would even be helpfull to clear this out. Can't seem to find it.
>
> Anyone any ideas?[/color]

I think you are pretty close:

import time

def resolution_samp le():
t1 = time.time()
while True:
t2 = time.time()
if t2 > t1:
return t2 - t1

def timer_resolutio n():
return min(resolution_ sample() for x in xrange(10))

The function above (timer_resoluti on) is actually pretty dumb. I think
the number of samples to take depends on resolution.

[jUrner@arcor.de]

Re: calculating system clock resolution

Maybe it was not too clear what I was trying to point out.

I have to calculate the time time.time() requires to return the next
tick of the clock.
Should be about 0.01ms but this may differ from os to os.

BTW (I'm new to linux) cat /proc/cpuinfo is nice but I have 2457.60
bogomips.
Is this something i should be concerned about? I mean is this
contageous or something ;-)

[Steven D'Aprano]

Re: calculating system clock resolution

On Fri, 07 Apr 2006 16:39:40 -0700, jUrner wrote:
[color=blue]
> Maybe it was not too clear what I was trying to point out.
>
> I have to calculate the time time.time() requires to return the next
> tick of the clock.
> Should be about 0.01ms but this may differ from os to os.[/color]

I suspect that Python isn't quite fast enough to give an accurate measure
for this, but I could be wrong.

You can try this:

def calc_time_res() :
now = time.time
start = now()
x = start
while start == x:
x = now()
print x - start

Trying it, I get a fairly small number:



[color=blue][color=green][color=darkred]
>>> calc_time_res()[/color][/color][/color]
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<stdin>", line 2, in calc_time_res
NameError: global name 'time' is not defined[color=blue][color=green][color=darkred]
>>> import time
>>>
>>> calc_time_res()[/color][/color][/color]
2.50339508057e-05[color=blue][color=green][color=darkred]
>>> calc_time_res()[/color][/color][/color]
2.59876251221e-05[color=blue][color=green][color=darkred]
>>> calc_time_res()[/color][/color][/color]
2.59876251221e-05[color=blue][color=green][color=darkred]
>>> calc_time_res()[/color][/color][/color]
2.59876251221e-05[color=blue][color=green][color=darkred]
>>> calc_time_res()[/color][/color][/color]
2.40802764893e-05








[color=blue]
>
> BTW (I'm new to linux) cat /proc/cpuinfo is nice but I have 2457.60
> bogomips.
> Is this something i should be concerned about? I mean is this
> contageous or something ;-)[/color]

[Steven D'Aprano]

Re: calculating system clock resolution

Ah, drat -- hit the wrong key and sent the last post before I had finished
writing it... the following is what I *intended* to send.

On Fri, 07 Apr 2006 16:39:40 -0700, jUrner wrote:
[color=blue]
> Maybe it was not too clear what I was trying to point out.
>
> I have to calculate the time time.time() requires to return the next
> tick of the clock.
> Should be about 0.01ms but this may differ from os to os.[/color]

I suspect that Python isn't quite fast enough to give an accurate measure
for this, but I could be wrong.

You can try this:

def calc_time_res() :
now = time.time
start = now()
x = start
while start == x:
x = now()
print x - start

Trying it, I get a fairly small number:
[color=blue][color=green][color=darkred]
>>> calc_time_res()[/color][/color][/color]
1.50203704834e-05[color=blue][color=green][color=darkred]
>>> calc_time_res()[/color][/color][/color]
1.50203704834e-05[color=blue][color=green][color=darkred]
>>> calc_time_res()[/color][/color][/color]
1.50203704834e-05

This is Python 2.3 running under Fedora Core 2 Linux.


--
Steven.

[Ron Adam]

Re: calculating system clock resolution

Steven D'Aprano wrote:[color=blue]
> On Fri, 07 Apr 2006 16:39:40 -0700, jUrner wrote:
>[color=green]
>> Maybe it was not too clear what I was trying to point out.
>>
>> I have to calculate the time time.time() requires to return the next
>> tick of the clock.
>> Should be about 0.01ms but this may differ from os to os.[/color]
>
> I suspect that Python isn't quite fast enough to give an accurate measure
> for this, but I could be wrong.[/color]
[color=blue][color=green][color=darkred]
>>>> import time
>>>>
>>>> calc_time_res()[/color][/color]
> 2.50339508057e-05[color=green][color=darkred]
>>>> calc_time_res()[/color][/color]
> 2.59876251221e-05[color=green][color=darkred]
>>>> calc_time_res()[/color][/color]
> 2.59876251221e-05[color=green][color=darkred]
>>>> calc_time_res()[/color][/color]
> 2.59876251221e-05[color=green][color=darkred]
>>>> calc_time_res()[/color][/color]
> 2.40802764893e-05[/color]

Trying this on my win xp gives the following.


0.0150001049042 # time.time()

2.23492091872e-006 # time.clock()

2.7936511484e-006
1.95555580388e-006 #<- lowest value for time.clock()
1.95555580388e-006
1.95555580388e-006
3.35238137808e-006
1.95555580388e-006
1.95555580388e-006
1.95555580388e-006
2.23492091872e-006

But I think this is going to vary from system to system as well as what
os is used. And it may be effected by other tasks as well so checking
multiple times is probably needed.


def calc_time_res() :
now = time.time
start = now()
x = start
while start == x:
x = now()
print x - start

def calc_time_res2( ):
now = time.clock
start = now()
x = start
while start == x:
x = now()
print x - start

def calc_time_res3( ):
now = time.clock
r = range(10)
times = [now() for x in r]
start = times[0]
for x in times[1:]:
print x-start
start = x

calc_time_res()
print
calc_time_res2( )
print
calc_time_res3( )

[jUrner@arcor.de]

Re: calculating system clock resolution

def calc_time_res() :
now = time.time
start = now()
x = start
while start == x:
x = now()
print x, start # <--
print x - start

print calc_time_res()[color=blue][color=green]
>> 1.50203704834e-05[/color][/color]

Something is going wrong here.
If you look at the function ,time.time() returns time in microseconds
(most oses and so
does mine).
So the calculation goes, lets say 1.23 - 1.24
How can the result be something like 1.50203704834e-05 ?
I would expect 0.01.

Next is, the first print statement prints out x and start equal up to
the fraction.

Is it Python giggeling?
Maybe it's python throwing the rounded float at us but internally
keeps calculating with the float returned by the os.
Maybe I'm wrong.

[Steven D'Aprano]

Re: calculating system clock resolution

On Sat, 08 Apr 2006 04:16:20 -0700, jUrner wrote:
[color=blue]
> def calc_time_res() :
> now = time.time
> start = now()
> x = start
> while start == x:
> x = now()
> print x, start # <--
> print x - start
>
> print calc_time_res()[color=green][color=darkred]
>>> 1.50203704834e-05[/color][/color]
>
> Something is going wrong here.
> If you look at the function ,time.time() returns time in microseconds
> (most oses and so does mine).[/color]

From help(time.time) :

time() -> floating point number
Return the current time in seconds since the Epoch.
Fractions of a second may be present if the system clock provides them.

Seconds, not microseconds.

[color=blue]
> So the calculation goes, lets say 1.23 - 1.24[/color]

How can the time *after* the while loop be less than the time *before* the
while loop?
[color=blue]
> How can the result be something like 1.50203704834e-05 ?[/color]

Have you looked at the output of time.time()?
[color=blue][color=green][color=darkred]
>>> time.time()[/color][/color][/color]
1144496209.3221 531

Of course, Python only prints a certain number of digits; to see the full
amount, use string formatting:
[color=blue][color=green][color=darkred]
>>> '%40.30f' % time.time()[/color][/color][/color]
'1144496642.905 987024307250976 562500000000'


This brings me to an even simpler method of getting the resolution of
time.time(), without the overhead of a while loop:
[color=blue][color=green][color=darkred]
>>> abs(time.time() - time.time())[/color][/color][/color]
1.0013580322265 625e-05

which is approximately 0.01ms, just as you expected.



--
Steven.

[Peter Hansen]

Re: calculating system clock resolution

Steven D'Aprano wrote:[color=blue]
> This brings me to an even simpler method of getting the resolution of
> time.time(), without the overhead of a while loop:
>[color=green][color=darkred]
>>>>abs(time.ti me() - time.time())[/color][/color]
>
> 1.0013580322265 625e-05
> which is approximately 0.01ms, just as you expected.[/color]

This doesn't necessarily work, at least on Windows, where the
time.time() resolution is much worse than the time it takes to execute a
couple of calls to time.time(). Most of the time the values returned by
two consecutive time.time() calls are identical, differing only if the
timer just happens to tick between the two. (On my machine a simple
while loop that performs the above calculation until it produces a
non-zero value has to run on average over 10000 times.)

-Peter

[Tim Peters]

Re: calculating system clock resolution

[jUrner][color=blue][color=green]
>> def calc_time_res() :
>> now = time.time
>> start = now()
>> x = start
>> while start == x:
>> x = now()
>> print x, start # <--
>> print x - start
>>
>> print calc_time_res()
>> 1.50203704834e-05
>>
>> Something is going wrong here.
>> If you look at the function ,time.time() returns time in microseconds
>> (most oses and so does mine).[/color][/color]

Don't confuse resolution with precision (or make up other words you
like better ;-)): just because some quantity is given with N bits
doesn't mean it's _accurate_ to N bits. See below for a more
extreme example.

[Steven D'Aprano][color=blue]
> ...
> This brings me to an even simpler method of getting the resolution of
> time.time(), without the overhead of a while loop:
>[color=green][color=darkred]
> >>> abs(time.time() - time.time())[/color][/color]
> 1.0013580322265 625e-05
>
> which is approximately 0.01ms, just as you expected.[/color]

Caution: the most likely outcome on Windows for that line is 0.0.
That's because the clock mechanism underlying time.time() on Windows
only updates at a frequency of 18.2 Hz (older systems) or 64 Hz (newer
systems). IOW, time.time() only "changes" 18.2 to 64 times per second
on Windows, and two consecutive calls are consequently likely to
return exactly the same result.

In contrast, time.clock() on Windows typically updates more than a
million times per second.

[jUrner@arcor.de]

Re: calculating system clock resolution

Starts getting confusing...

on linux I get
print time.time()[color=blue][color=green]
>> xxx.23[/color][/color]

Is it mentioned somewhere that print truncates floats ?
Thats new to me. Kinda surprising that is.

print '%.30' % time.time()[color=blue][color=green]
>> xxx.23456678990 ...[/color][/color]
I knew it must have been hiding somewhere

On windows I'd expect a resolution of round around 15ms. Thats why I
fell for the trap assuming linux is operating on about the same.
Anyway.
As far as I can see there is no nice way except for the brute force
loop
to calculate this resolution. This was giving me head sratches and
thats
why the loop in the initial post was so shamelessly empty. I was
thinking
about the poor dudes running an os with a resolution of about 1 second.
I was hoping for s.o. releasing an ace from his sleeve. Well, there
seems
to be no way to know except knowing.

Or like Sege Orlov put it[color=blue][color=green]
>> I think the number of samples to take depends on resolution ;-)[/color][/color]

Crappy oses that is. Time for them to get standardized.

[Sybren Stuvel]

Re: calculating system clock resolution

jUrner@arcor.de enlightened us with:[color=blue]
> Is it mentioned somewhere that print truncates floats ?[/color]

'print' prints str(time()). On the interactive prompt, you see
repr(time()). float.__str__ truncates. I don't know where it's
documented, but this is the reason why you see the truncation.

Sybren
--
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?
Frank Zappa