On Fri, Sep 2, 2011 at 10:56 AM, John Stultz wrote:
> On Wed, 2011-08-31 at 07:43 +1200, Michael Hope wrote:
>> I was quite impressed with how steady the process clock was under
>> different CPU loads. It doesn't seem to round up or down to a
>> scheduler tick either which is nice.
>
> Hmm. Very
On Wed, 2011-08-31 at 07:43 +1200, Michael Hope wrote:
> I was quite impressed with how steady the process clock was under
> different CPU loads. It doesn't seem to round up or down to a
> scheduler tick either which is nice.
Hmm. Very interesting results! Its been a little while since I've looke
> It was a bit random across the different suites. CoreMark
> uses clock_gettime(CLOCK_REALTIME, ...) which is a wall clock
> with NTP adjustments. EEMBC uses clock() which is a lower
> resolution wall clock.
So everything was mostly wall clock based. We had not tested
CLOCK_PROCESS_CPUTIME_ID
On Wed, Aug 31, 2011 at 12:38 AM, Turgis, Frederic wrote:
> Hi,
>
> What was the timer used previously for benchmarks ?
It was a bit random across the different suites. CoreMark uses
clock_gettime(CLOCK_REALTIME, ...) which is a wall clock with NTP
adjustments. EEMBC uses clock() which is a low
Hi,
What was the timer used previously for benchmarks ?
Your page focuses on accuracy while I think an important point is already the
availability/functionality of clock_gettime(CLOCK_PROCESS/THREAD_CPUTIME_ID,
...) on ARM, which measures process/thread execution time vs "wall time" for
most o
