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 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.


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