Bengt Richter wrote:
> windows or unix? time.time and time.clock seem to reverse roles as > best-resolution time sources depending on which platform. > Linux. time.time() seems to report (using %e to format the o/p) a fixed number of the order ~1e9. > If you have a pentium with a rdtsc instruction, you can write an extension > module in c to get at it. In C on a 300mhz p2 I got down to 23ns minimum > delta between calls, IIRC. But even then I was subject to the small I do not need ns resolution. A few microseconds would be fine. > probability of an interrupt during my timing loop, and there are many > normally going on, so the longer the interval you are timing the greater > the probability that an interrupt will occur within it (assuming random > independence, which is also not necessarily true). This is why timing > frameworks generally either average brute force or discard outlier timings > and average, or return best-of. All these have different error properties, > and depend on lots of stuff. > > I'm wondering whats your application is. Maybe you need a real-time OS? No, no. All I am looking for is for the system to report its time with better resolution. I know it is possible on my hardware, because I can get at very precise timings using Fortran 95 intrinsics in my other code. However, with Python's time module, I do not seem to be able to access it. -- http://mail.python.org/mailman/listinfo/python-list
