[Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

[Victor Stinner]

>> sleep() is implemented in the kernel. The kernel is notified when a
>> clock is set, and so can choose how to handle time adjustement. Most
>> "sleeping" functions use the system clock but don't care of clock
>> adjustement.
>
> We're going around in circles. I'm not asking what sleep does, I want
> on principle a timer that does the same thing as sleep(), regardless
> of how sleep() works. So if on some OS sleep() uses the same algorithm
> as CLOCK_MONOTONIC_RAW, I want my timer to use that too. But if on
> some other OS sleep() uses CLOCK_MONOTONIC, I want my timer there to
> use that. And if on some OS sleep() is buggy and uses the time-of-day
> clock, well, I wouldn't mind if my timer used the same thing.

sleep() takes a number of seconds as argument, so CLOCK_MONOTONIC
should be used, not CLOCK_MONOTONIC_RAW. If I understood correctly,
the unit of CLOCK_MONOTONIC is a second, whereas CLOCK_MONOTONIC_RAW
may be faster or slower than a second.

It looks like CLOCK_MONOTONIC_RAW was added to write a NTP server in
user-space. Extract of the mail including the patch adding
CLOCK_MONOTONIC_RAW to the Linux kernel:
"In talking with Josip Loncaric, and his work on clock synchronization
(see btime.sf.net), he mentioned that for really close synchronization,
it is useful to have access to "hardware time", that is a notion of time
that is not in any way adjusted by the clock slewing done to keep close
time sync.

Part of the issue is if we are using the kernel's ntp adjusted
representation of time in order to measure how we should correct time,
we can run into what Paul McKenney aptly described as "Painting a road
using the lines we're painting as the guide".

I had been thinking of a similar problem, and was trying to come up with
a way to give users access to a purely hardware based time
representation that avoided users having to know the underlying
frequency and mask values needed to deal with the wide variety of
possible underlying hardware counters."
https://lkml.org/lkml/2008/3/19/260

Victor