GetTickCount vs. clock for msec resolution

[Tim Peters]

[Les Schaffer]
> i am talking to some hardware, needing to resolve 10's-100's of msec
> of time. So I started playing around with the clock and GetTickCount
> functions under win32 to check for finer time resolution.
>
> See code below. timimg results for win2k at:
>
>   http://folks.astrian.net/godzilla/ticks.html
>
> GetTickCount has some funniness in its behavior.
>
> i'm good and stickin with clock for now. But I am curious to hear
> other people's observations about msec time resolution or possibly
> even smaller, particularly on winXX and linux.

GetTickCount is a legacy API; its resolution varies across systems, but is
never better than 10ms, and is as coarse as 55ms on Win9X.

Python on Windows uses the QueryPerformanceCounter API for time.clock(),
thanks to Mark Hammond.  How good that is (indeed, whether it even exists!)
depends on your platform.  On my home box, it updates 1,193,180 times per
second (use QueryPerformanceFrequency to get your magic number -- it will
probably be the same if you're running on a Win9X Pentium).  So ms resolution
is a yawn for it.  BTW, you'll find the hardcoded number 1193180 in
winsound.c too:  this isn't a coincidence <wink>.

clock() on Linux returns CPU time, not wall-clock time.  I don't remember
what its resolution is, but you won't like it.  time.time() may or may not be
better for you there (across Unix flavors, it varies from microsecond to
full-second resolution; on Win9X it's something bizarre, *appearing* to be
10ms unless you look very carefully and notice it's only updated 18.2 times
per second).

In any case, don't mistake resolution for accuracy.  You didn't ask about
accuracy <0.5 wink>.

for-more-on-that-do-a-google-search-ly y'rs  - tim