This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: clock() time travel.


On 01/16/2014 01:48 PM, PaweÅ Sikora wrote:
> On Thursday 16 of January 2014 12:35:00 Carlos O'Donell wrote:
>> 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.
> 
> i need to measure an overall cpu execution time with something like
> a monotonic-process-cputime. an abstract monotonic timer which can
> be speedup/slowdown via ntp updates is not what i really need.
> 
> maybe i should bind my process to a single cpu core with sched_setaffinity()
> for reliable clock_gettime(CLOCK_PROCESS_CPUTIME_ID) results?
> 
> benchmarking is really paintful in these days :)

You may wish to look at glibc's "benchtests" directory to see what we do.

In particular our use of:

       CLOCK_MONOTONIC_RAW (since Linux 2.6.28; Linux-specific)
              Similar to CLOCK_MONOTONIC, but provides access to a raw 
	      hardware-based time that is not subject to NTP adjustâ
              ments or the incremental adjustments performed by adjtime(3).


Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]