PEP 418: Add tables of clock accuracy

* Add a "NTP adjusted" section
 * Don't use CLOCK_MONOTONIC_RAW on Linux for time.monotonic()
This commit is contained in:
Victor Stinner 2012-04-03 00:18:51 +02:00
parent c11b091c2c
commit 7ba7cc657f
1 changed files with 82 additions and 13 deletions

View File

@ -143,12 +143,9 @@ Pseudo-code [#pseudo]_::
clk_id = monotonic.clocks[0]
return time.clock_gettime(clk_id)
except OSError:
# CLOCK_MONOTONIC_RAW requires a Linux kernel >= 2.6.28
del monotonic.clocks[0]
return time.time()
monotonic.clocks = []
if hasattr(time, 'CLOCK_MONOTONIC_RAW'):
monotonic.clocks.append(time.CLOCK_MONOTONIC_RAW)
if hasattr(time, 'CLOCK_HIGHRES'):
monotonic.clocks.append(time.CLOCK_HIGHRES)
monotonic.clocks.append(time.CLOCK_MONOTONIC)
@ -246,6 +243,32 @@ Hardware clocks
32,768 Hz
NTP adjusted
============
NTP has diffent methods to adjust a clock:
* "slewing": change the clock frequency to be slightly faster or slower
(which is done with adjtime()). Since the slew rate is limited to 0.5 ms/s,
each second of adjustment requires an amortization interval of 2000 s. Thus,
an adjustment of many seconds can take hours or days to amortize.
* "stepping": jump by a large amount in a single discrete step (which is done
with settimeofday())
By default, the time is slewed if the offset is less than 128 ms, or stepped
otherwise.
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.
Get more detail in the `documentation of the NTP daemon
<http://doc.ntp.org/4.1.2/ntpd.htm>`_.
Operating system clocks
=======================
@ -258,7 +281,7 @@ Name Resolution Accuracy Adjusted by NTP? Actio
CLOCK_MONOTONIC_RAW 1 ns (*) No Stopped
gethrtime 1 ns (*) No Not stopped
CLOCK_HIGHRES 1 ns (*) No ?
CLOCK_MONOTONIC 1 ns (*) Yes on Linux Stopped on Linux
CLOCK_MONOTONIC 1 ns (*) Slewed on Linux Stopped on Linux
mach_absolute_time() 1 ns (*) No ?
QueryPerformanceCounter() \- 0.3 ns - 5 ns No Accuracy issue
GetTickCount[64]() 1 ms 1 ms - 15 ms No Include suspend time
@ -278,6 +301,25 @@ the clock. It does not reflect the stability the clock rate. For
example, QueryPerformanceCounter() has a good accuracy but is known to
not have a steady rate.
Examples of clock accuracy on x86_64:
========================= ================ ===============
Name Operating system Accuracy
========================= ================ ===============
CLOCK_MONOTONIC_RAW Linux 3.2 1 ns
CLOCK_MONOTONIC Linux 3.2 1 ns
CLOCK_HIGHRES SunOS 5.11 2 ns
CLOCK_MONOTONIC SunOS 5.11 2 ns
QueryPerformanceCounter Windows Vista 10 ns
CLOCK_MONOTONIC FreeBSD 8.2 11 ns
CLOCK_MONOTONIC OpenBSD 5.0 10 ms
GetTickCount Windows Vista 15.6 ms
========================= ================ ===============
For CLOCK_MONOTONIC and CLOCK_MONOTONIC_RAW, the accuracy of this table is the
result of clock_getres(). It looks like Linux does not implement
clock_getres() and always return 1 nanosecond.
mach_absolute_time
^^^^^^^^^^^^^^^^^^
@ -325,14 +367,12 @@ The following operating systems don't support CLOCK_MONOTONIC:
* Mac OS X
* Windows
CLOCK_MONOTONIC_RAW is specific to Linux. It is similar to
CLOCK_MONOTONIC, but provides access to a raw hardware-based time that
is not subject to NTP adjustments. CLOCK_MONOTONIC_RAW requires Linux
2.6.28 or later.
On Linux, NTP may adjust the CLOCK_MONOTONIC rate (slewed), but it cannot
jump backward.
On Linux, NTP may adjust the CLOCK_MONOTONIC rate, but it cannot jump
backward. If available, CLOCK_MONOTONIC_RAW should be used instead of
CLOCK_MONOTONIC to avoid the NTP adjustment.
CLOCK_MONOTONIC_RAW is specific to Linux. It is similar to CLOCK_MONOTONIC, but
provides access to a raw hardware-based time that is not subject to NTP
adjustments. CLOCK_MONOTONIC_RAW requires Linux 2.6.28 or later.
CLOCK_MONOTONIC stops while the machine is suspended.
@ -504,8 +544,23 @@ time() 1 sec 1 sec
========================= =============== ===============
(*) The accuracy of system clocks depends on the operating system and
the hardware clock. On Windows, the accuracy is in the range 1 ms -
15 ms.
the hardware clock.
Examples of clock accuracy on x86_64:
========================= ================ ===============
Name Operating system Accuracy
========================= ================ ===============
CLOCK_REALTIME Linux 3.2 1 ns
CLOCK_REALTIME FreeBSD 8.2 11 ns
CLOCK_REALTIME SunOS 5.11 10 ms
CLOCK_REALTIME OpenBSD 5.0 10 ms
GetSystemTimeAsFileTime Windows Vista 15.6 ms
========================= ================ ===============
For CLOCK_REALTIME, the accuracy of this table is the result of clock_getres().
It looks like Linux does not implement clock_getres() and always return 1
nanosecond.
Windows: GetSystemTimeAsFileTime
@ -573,6 +628,20 @@ Resolution:
clock_getres(CLOCK_REALTIME) is 1 nanosecond on Linux.
* GetProcessTimes(): call GetSystemTimeAdjustment().
Examples of clock accuracy on x86_64:
========================= ================ ===============
Name Operating system Accuracy
========================= ================ ===============
clock() Linux 3.2 1 ms
clock() SunOS 5.11 1 ms
clock() FreeBSD 8.2 7.8 ms
clock() OpenBSD 5.0 10 ms
========================= ================ ===============
The accuracy of clock() in this table is the result of 1 / CLOCKS_PER_SEC.
Thread
^^^^^^