[Python-Dev] Use QueryPerformanceCounter() for time.monotonic() and/or time.highres()?

Glyph glyph at twistedmatrix.com
Sat Mar 31 03:58:40 CEST 2012


On Mar 30, 2012, at 9:32 PM, Guido van Rossum wrote:

>>>  - no steps
>> 
>> You mean "not adjusted by NTP"? Except CLOCK_MONOTONIC on Linux, no
>> monotonic clock is adjusted by NTP. On Linux, there is
>> CLOCK_MONOTONIC_RAW, but it is only available on recent Linux kernel
>> (2.6.28).
>> 
>> Do you think that it is important to be able to refuse a monotonic
>> clock adjusted by NTP? What would be the use case of such truly steady
>> clock?
> 
> That depends on what NTP can do to the clock. If NTP makes the clock
> tick *slightly* faster or slower in order to gradually adjust the wall
> clock, that's fine. If NTP can make it jump wildly forward or even
> backward, it's no better than time.time(), and we know why (for some
> purposes) we don't want that.

"no steps" means something very specific.  It does not mean "not adjusted by NTP".

In NTP, changing the clock frequency to be slightly faster or slower is called "slewing" (which is done with adjtime()).  Jumping by a large amount in a single discrete step is called "stepping" (which is done with settimeofday()).  This is sort-of explained by <http://doc.ntp.org/4.1.2/ntpd.htm>.

I think I'm agreeing with Guido here when I say that, personally, my understanding is that slewing is generally desirable (i.e. we should use CLOCK_MONOTONIC, not CLOCK_MONOTONIC_RAW) if one wishes to measure "real" time (and not a time-like object like CPU cycles).  This is because the clock on the other end of the NTP connection from you is probably better at keeping time: hopefully that thirty five thousand dollars of Cesium timekeeping goodness is doing something better than your PC's $3 quartz crystal, after all.

So, slew tends to correct for minor defects in your local timekeeping mechanism, and will compensate for its tendency to go too fast or too slow.  By contrast, stepping only happens if your local clock is just set incorrectly and the re-sync delta has more to do with administrative error or failed batteries than differences in timekeeping accuracy.

-glyph

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20120330/59f7bc1b/attachment-0001.html>


More information about the Python-Dev mailing list