[Python-Dev] PEP 418 is too divisive and confusing and should be postponed

[Janzert]

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