473,703 Members | 2,933 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

time.clock() going backwards??

Hello,

I experimented something very strange, a few days ago. I was debugging an
application at a customer's site, and the problem turned out to be that
time.clock() was going "backwards" , that is it was sometimes (randomically)
returning a floating point value which was "less than" the value returned by
the previous invokation. The computer was a pretty fast one (P4 3Ghz I think,
running Windows XP), and this happened only between very close invokations of
time.clock().

I have triple-verified this, including printing the repr() of the floating
point number and verifying it was really minor than the previous value by a few
microseconds. In other words, I'm absolutely positive that it's not a mistake
on my side, but that time.clock() was really apparently "jumping backward".
This was confusing the hell out of my application, of course, and I just hacked
it so to ignore these bogus reads, and just reading off again. Since the error
was just of a few microseconds, reading time.clock() again produces a number
which was higher than what I had before, and thus OK for my application.

I was wondering if someone had experimented this behaviour before. I tried
googling but to no effect. Is it possible this to be a bug in Python itself
(maybe, shooting at the moon, in the conversion between the 64bit performance
counter and the floating point representation returned by time.clock()), or
could it be a bug in Windows itself or the mother board drivers (buf if so,
wouldn't other application start going mad)?
--
Giovanni Bajo
Aug 25 '06 #1
18 6222

Op 25-aug-2006, om 16:13 heeft Giovanni Bajo het volgende geschreven:
Hello,

Is it possible this to be a bug in Python itself
(maybe, shooting at the moon, in the conversion between the 64bit
performance
counter and the floating point representation returned by time.clock
()), or
could it be a bug in Windows itself or the mother board drivers
(buf if so,
wouldn't other application start going mad)?
--
Giovanni Bajo
Very interesting! While I couldn't possibly know the answer to this,
I do wonder which version of Python you were using. Is it the
bleeding edge 2.5 release candidate?

Michiel

Aug 25 '06 #2
Giovanni Bajo wrote:
Hello,

I experimented something very strange, a few days ago. I was debugging an
application at a customer's site, and the problem turned out to be that
time.clock() was going "backwards" , that is it was sometimes (randomically)
returning a floating point value which was "less than" the value returned by
the previous invokation. The computer was a pretty fast one (P4 3Ghz I think,
running Windows XP), and this happened only between very close invokations of
time.clock().

I have triple-verified this, including printing the repr() of the floating
point number and verifying it was really minor than the previous value by a few
microseconds. In other words, I'm absolutely positive that it's not a mistake
on my side, but that time.clock() was really apparently "jumping backward".
This was confusing the hell out of my application, of course, and I just hacked
it so to ignore these bogus reads, and just reading off again. Since the error
was just of a few microseconds, reading time.clock() again produces a number
which was higher than what I had before, and thus OK for my application.

I was wondering if someone had experimented this behaviour before. I tried
googling but to no effect. Is it possible this to be a bug in Python itself
(maybe, shooting at the moon, in the conversion between the 64bit performance
counter and the floating point representation returned by time.clock()), or
could it be a bug in Windows itself or the mother board drivers (buf ifso,
wouldn't other application start going mad)?
From the MSDN docs for QueryPerformanc eCounter:

Remarks:
On a multiprocessor computer, it should not matter which processor is
called. However, you can get different results on different processors
due to bugs in the basic input/output system (BIOS) or the hardware
abstraction layer (HAL). To specify processor affinity for a thread, use
the SetThreadAffini tyMask function.

Are you running on a multi-core or a multi-processor machine?

The best way to handle this is probably to make your application
'tolerant' to such cases.

[sreeram;]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFE7yhsrgn 0plK5qqURAp1sAJ 9mOO0UbZUhjZQsj ew3roLGQHUabACg vwCJ
I8wDMKiuL2xF/dY7d2b1ccA=
=hRd5
-----END PGP SIGNATURE-----

Aug 25 '06 #3

"Giovanni Bajo" <no***@sorry.co mwrote in message
news:vk******** ************@tw ister2.libero.i t...
Hello,

I experimented something very strange, a few days ago. I was debugging an
application at a customer's site, and the problem turned out to be that
time.clock() was going "backwards" , that is it was sometimes
(randomically)
returning a floating point value which was "less than" the value returned
by
the previous invokation. The computer was a pretty fast one (P4 3Ghz I
think,
running Windows XP), and this happened only between very close
invokations of
time.clock().
I seem to remember this being mentioned before on the list, perhaps by Tim
Peters. Perhaps he will chime in.

tjr

Aug 25 '06 #4
Terry Reedy wrote:
"Giovanni Bajo" <no***@sorry.co mwrote in message
news:vk******** ************@tw ister2.libero.i t...
>>Hello,

I experimented something very strange, a few days ago. I was debugging an
application at a customer's site, and the problem turned out to be that
time.clock( ) was going "backwards" , that is it was sometimes
(randomically )
returning a floating point value which was "less than" the value returned
by
the previous invokation. The computer was a pretty fast one (P4 3Ghz I
think,
running Windows XP), and this happened only between very close
invokations of
time.clock( ).


I seem to remember this being mentioned before on the list, perhaps by Tim
Peters. Perhaps he will chime in.

tjr
If I remember it right, the cause of such a problem is updating the
clock by accessing a time server over a network. Just any such access
results in adjusting the time a bit and leads eventually to such problems.

Claudio Grondi
Aug 25 '06 #5
[Giovanni Bajo[
>I experimented something very strange, a few days ago. I was debugging an
application at a customer's site, and the problem turned out to be that
time.clock() was going "backwards" , that is it was sometimes
(randomicall y) returning a floating point value which was "less than" the
value returned by the previous invokation. The computer was a pretty fast
one (P4 3Ghz I think, running Windows XP), and this happened only between
very close invokations of time.clock().
[Terry Reed]
I seem to remember this being mentioned before on the list, perhaps by Tim
Peters. Perhaps he will chime in.
No real need ;-) BIOS or HAL bug on a multiprocessor (or maybe even
hyperthreaded) box is by far the most likely cause (and the only cause
ever identified for sure by people who followed up). Python's C code
slinging QueryPerformanc eCounter is exceedingly simple, and isn't a
suspect because of that. It's on the edge of vague possibility that
Microsoft's compiler generates non-monotonic code for converting
64-bit integer to double: i.e., Python's C code obviously relies on
that if i and j are _int64 satisfying i >= j, then (double)i >=
(double)j. If that type-conversion code /is/ monotonic (which is
almost certainly so), then the only ways the C code can fail are if
the HW counter overflows (in which case time.clock() would "jump" a
huge amount), or if the sequence of values returned by
QueryPerformanc eCounter is itself non-monotonic at times (which is
consistent with known BIOS/HAL bugs).
Aug 25 '06 #6
Hi,
>>>I experimented something very strange, a few days ago. I was debugging an
applicatio n at a customer's site, and the problem turned out to be that
time.clock () was going "backwards" , that is it was sometimes
(randomicall y)
returning a floating point value which was "less than" the value returned
by the previous invokation.

If I remember it right, the cause of such a problem is updating the
clock by accessing a time server over a network. Just any such access
results in adjusting the time a bit and leads eventually to such problems.
Usualy time is synchronized by making the clock run a little faster or a
little slower until it is in sync with the timeserver. It shouldn't go
backwards... A bad time-sync-program might ofcourse do this, but with a
decent NTP client this shouldn't happen.

- Sander
Aug 25 '06 #7
>I seem to remember this being mentioned before on the list, perhaps by Tim
>Peters. Perhaps he will chime in.
ClaudioIf I remember it right, the cause of such a problem is updating
Claudiothe clock by accessing a time server over a network. Just any
Claudiosuch access results in adjusting the time a bit and leads
Claudioeventual ly to such problems.

Wouldn't that affect time.time (time since the start of the Epoch), not
time.clock (cpu time used by the current process)?

Skip
Aug 26 '06 #8
"Tim Peters" <ti********@gma il.comwrote:
>[Giovanni Bajo[
>>I experimented something very strange, a few days ago. I was debugging an
application at a customer's site, and the problem turned out to be that
time.clock( ) was going "backwards" , that is it was sometimes
(randomically ) returning a floating point value which was "less than" the
value returned by the previous invokation. The computer was a pretty fast
one (P4 3Ghz I think, running Windows XP), and this happened only between
very close invokations of time.clock().

[Terry Reed]
>I seem to remember this being mentioned before on the list, perhaps by Tim
Peters. Perhaps he will chime in.

No real need ;-) BIOS or HAL bug on a multiprocessor (or maybe even
hyperthreade d) box is by far the most likely cause (and the only cause
ever identified for sure by people who followed up). Python's C code
slinging QueryPerformanc eCounter is exceedingly simple, and isn't a
suspect because of that. It's on the edge of vague possibility that
Microsoft's compiler generates non-monotonic code for converting
64-bit integer to double:
It is much simpler than that. With a multiprocessor HAL, including on a
dual-core or hyperthreaded system, QueryPerformanc eCounter returns the raw
cycle counter (RDTSC). However, on Windows XP, the operating system does
not synchronize the cycle counters on multiple processors, and they can be
actually be millions of cycles apart.

This was a change from previous systems. On NT4 and Win2000, the operating
actually rewrote the cycle counters on the second (and beyond) processors
to align them to the first processor, so the delta was usually only a dozen
or two cycles. XP does not appear to do that. I think that is a huge
mistake, since it renders QueryPerformanc eCounter non-monotonic.
--
- Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.
Aug 28 '06 #9
Tim Roberts wrote:
"Tim Peters" <ti********@gma il.comwrote:

>>[Giovanni Bajo[
>>>>I experimented something very strange, a few days ago. I was debugging an
applicati on at a customer's site, and the problem turned out to be that
time.clock( ) was going "backwards" , that is it was sometimes
(randomical ly) returning a floating point value which was "less than" the
value returned by the previous invokation. The computer was a pretty fast
one (P4 3Ghz I think, running Windows XP), and this happened only between
very close invokations of time.clock().

[Terry Reed]
>>>I seem to remember this being mentioned before on the list, perhaps by Tim
Peters. Perhaps he will chime in.

No real need ;-) BIOS or HAL bug on a multiprocessor (or maybe even
hyperthreaded ) box is by far the most likely cause (and the only cause
ever identified for sure by people who followed up). Python's C code
slinging QueryPerformanc eCounter is exceedingly simple, and isn't a
suspect because of that. It's on the edge of vague possibility that
Microsoft's compiler generates non-monotonic code for converting
64-bit integer to double:


It is much simpler than that. With a multiprocessor HAL, including on a
dual-core or hyperthreaded system, QueryPerformanc eCounter returns the raw
cycle counter (RDTSC). However, on Windows XP, the operating system does
not synchronize the cycle counters on multiple processors, and they can be
actually be millions of cycles apart.

This was a change from previous systems. On NT4 and Win2000, the operating
actually rewrote the cycle counters on the second (and beyond) processors
to align them to the first processor, so the delta was usually only a dozen
or two cycles. XP does not appear to do that. I think that is a huge
mistake, since it renders QueryPerformanc eCounter non-monotonic.
How does it come, that processors on same mainboard run at different
speeds? Do they have separate clock-pulse generators?

I can remember, that (at least on very old motherboards) the clock-pulse
generator was a separate element and the processor just used it, so I
would expect, that even in case of multiple processors, if there were
only one clock-pulse generator for all of them, they were not be able to
run at different speeds.

Claudio Grondi
Aug 28 '06 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

13
3285
by: Peter Hansen | last post by:
I would like to determine the "actual" elapsed time of an operation which could take place during a time change, in a platform-independent manner (at least across Linux/Windows machines). Using time.time() doesn't appear to be suitable, since time might jump forwards or backwards at the user's whim, if the system clock is reset, or when a daylight savings time change occurs. Using time.clock() doesn't appear to be suitable on Linux,...
9
2015
by: Fabian | last post by:
I had a very quiet schedule at work today, so I thought I'd finish this script. In theory, it should generate a random time between two moments specified, round it off to a conventional interval if desired, and convert it into text if desired. The text conversion routine is a separate function which could be used more generally if desired. It mostly seems to work ok. Anyone want to either borrow it or show me some horribly obvious flaw...
5
9092
by: Erich Schreiber | last post by:
In the Python Library Reference the explanation of the time.sleep() function reads amongst others: > The actual suspension time may be less than that requested because > any caught signal will terminate the sleep() following execution > of that signal's catching routine. Also, the suspension time may > be longer than requested by an arbitrary amount because of the > scheduling of other activity in the system. I don't understand the...
74
7723
by: Dominik Wallner | last post by:
Hi! I'm currently implementing a program which measures voltages through an external USB-AD-converter. It should output those values as time/voltage pairs. My problem is to measure the time to output (time elapsed since program start would do just fine) - it should be as precise as possible, as there may be only differences in milliseconds between two measurements.
37
4680
by: David T. Ashley | last post by:
I have Red Hat Enterprise Linux 4. I was just reading up about UTC and leap seconds. Is it true on my system that the Unix time may skip up or down by one second at midnight when there is a leap second? By "Unix time" I mean the integer returned by time() and similar functions. I'm concerned about the "down" case. Some of the software I've written
5
2198
by: Charles May | last post by:
Anyone have a simple concept for the best way to store timeclock information in a database. I currently have my table set up like this with a typical daily entry. tcID empID Type Date Time 1 37 'Clockin' 1/18/08 7:45:39 AM 2 38 'Clockin' 1/18/08 7:55:42 AM 3 39 'Clockin' 1/18/08 7:55:42 AM 4 38 'BreakOut' 1/18/08 ...
7
1832
by: Godzilla | last post by:
Hello, I have been reading a thread about time.clock() going backward, which is exactly what I am seeing... the thread generally leaning toward the problem is caused by multi-processor machines. But I am seeing it at a single CPU computer, and running XP. The error I am seeing between two very close invokation of time.clock() is always around 3.5 seconds! This is enough to throw a lot of the timing requirement in the software out of...
0
1191
by: Gabriel Genellina | last post by:
En Tue, 03 Jun 2008 16:58:12 -0300, Pau Freixes <pfreixes@milnou.net> escribió: So the above code corresponds to the standalone version - what about the embedded version? Are you sure it is exactly the *same* code? All those global statements are suspicious, and you don't even need most of them. Note that looking up a name in the global namespace is much slower than using a local name. Also, you're including the time it takes the OS...
0
8744
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
9240
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
0
9103
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
0
8952
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
1
6585
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
4417
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
0
4674
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
3113
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
3
2055
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.