Re: clock() time travel.

[PaweÅ Sikora <pluto at agmk dot net>]

On Thursday 16 of January 2014 13:55:04 Carlos O'Donell wrote:
> 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).

monotonic-raw is cool if you measuring monotonic-walltime but what can
youn deduce from monotonic-raw results when the benchmark is swapping
or suspended by the kernel scheduler? and finally the monotonic-raw
is not available on the still living redhat-el5 (2.6.18 kernel).

BR,
PaweÅ.