This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: clock() time travel.
- From: PaweÅ Sikora <pluto at agmk dot net>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: libc-help at sourceware dot org
- Date: Thu, 16 Jan 2014 19:48:20 +0100
- Subject: Re: clock() time travel.
- Authentication-results: sourceware.org; auth=none
- References: <2a73b22e707bbe6dce3871aacf7d8a69 at agmk dot net> <6559318 dot s3zxh1qg9A at localhost dot localdomain> <52D81844 dot 5000404 at redhat dot com>
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 :)
BR,
PaweÅ.