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

[Johannes Stezenbach]

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 ;-)


Regards,
Johannes