bug report: [ #447945 ] time.time() is not non-decreasing

Johannes Stezenbach yawyi at gmx.de
Sat Aug 4 21:11:21 CEST 2001

zooko at zooko.com <zooko at zooko.com> wrote:
>------- begin included strace output
>gettimeofday({996940586, 982012}, NULL) = 0
>gettimeofday({996940586, 982154}, NULL) = 0
>gettimeofday({996940586, 982295}, NULL) = 0
>gettimeofday({996940586, 982435}, NULL) = 0
>gettimeofday({996940586, 982576}, NULL) = 0
>gettimeofday({996940586, 982718}, NULL) = 0
>gettimeofday({996940586, 982859}, NULL) = 0
>gettimeofday({996940586, 976989}, NULL) = 0
>So my `gettimeofday()' sometimes returns a decreasing value.
>Hm.  So I suppose I should report this as bug to debian...

This happens on laptops with variable CPU clock frequency
(Intel Speed Step or something similar).

Linux calibrates its timing loop at boot time, and since the
kernel itself does not process APM events, it cannot recalibrate
when the CPU clock speed changes (my laptop's BIOS changes the
CPU clock when I un/plug AC). Linux uses the CPU clock
cycle counter to achieve microsecond relolution for
gettimeofday(), the long term accuracy of gettimeofday() is
determined by a timer interrupt and thus is independent of
the CPU clock.

I noticed that when I got some negative times when profiling
some C code ;-)


More information about the Python-list mailing list