Re: clock() time travel.

["Carlos O'Donell" <carlos at redhat dot com>]

On 01/16/2014 12:15 PM, PaweÅ Sikora wrote:
> On Thursday 16 of January 2014 11:38:55 Carlos O'Donell wrote:
>> On 01/16/2014 05:54 AM, PaweÅ Sikora wrote:> Hi,
>>
>>> i've observed on my i3-540 cpu that subsequent clock() calls *sometimes*
>>> give smaller number of ticks than previous one. is it a known issue?
>>>
>>> BR,
>>> PaweÅ.
>>>
>>> % ./timing
>>> t[current]: 10713902 < t[previous]: 10713903
>>> zsh: abort (core dumped)  ./timing
>>
>> This is either a compiler or kernel bug.
>>
>> On glibc click() is just clock_gettime with
>> CLOCK_PROCESS_CPUTIME_ID followed by the appropriate
>> divisions to get the correctly rounded result.
> 
> hmm, there's interesting note in clock_gettime() manual not metioned
> in clock() manual.
>  
>    "Note for SMP systems
>        The  CLOCK_PROCESS_CPUTIME_ID and CLOCK_THREAD_CPUTIME_ID clocks are
>        realized on many platforms using timers from the CPUs (TSC on i386,
>        AR.ITC on Itanium). These registers may differ between CPUs and as
>        a consequence these clocks may return bogus results if a process is
>        migrated to another CPU. (....)"
>  
> i'm using an intel-i3 (1 processor, 4 cores), so probably subsequent clock()
> snapshots in my testcase contain slightly different values from different
> tsc registers.

IMO that's a kernel bug, but the kernel might disagree.

Either way you have no guarantee of monotonicity anyway.

You need to use clock_gettime and CLOCK_MONOTONIC.

Cheers,
Carlos.