>>> 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. Linux is the OS providing the most reliable monotonic clock, why should you use a not reliable monotonic clock instead? NTP doesn't step CLOCK_MONOTONIC, it only slew it. http://www.python.org/dev/peps/pep-0418/#ntp-adjustment Victor _______________________________________________ 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
