On 4/5/2012 6:32 AM, Victor Stinner wrote:
Since the only monotonic clock that can be adjusted by NTP is Linux'
CLOCK_MONOTONIC, if we avoid it, then time.monotonic() would always
give a clock that isn't adjusted by NTP.
I thought we decided that NTP adjustment isn't an issue, because
it's always gradual.
Well, in timings it is an issue, but perhaps not a big one. :-)
In any case, which one we use will not change the API, so if it is
decided it is an issue, we can always more to CLOCK_MONOTONIC_RAW in
the future, once Linux< 2.6.26 (or whatever it was) is deemed
unsupported.
I prefer to use CLOCK_MONOTONIC, not because it is also available for
older Linux kernels, but because it is more reliable. Even if the
underlying clock source is unstable (unstable frequency), a delta of
two reads of the CLOCK_MONOTONIC clock is a result in *seconds*,
whereas CLOCK_MONOTONIC_RAW may use an unit a little bit bigger or
smaller than a second. time.monotonic() unit is the second, as written
in its documentation.
I believe the above is only true for sufficiently large time deltas. One
of the major purposes of NTP slewing is to give up some short term
accuracy in order to achieve long term accuracy (e.g. whenever the clock
is found to be ahead of real time it is purposefully ticked slower than
real time).
So for benchmarking it would not be surprising to be better off with the
non-adjusted clock. Ideally there would be a clock that was slewed "just
enough" to try and achieve short term accuracy, but I don't know of
anything providing that.
Janzert
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
