On Fri, 2016-02-26 at 18:02 -0700, jd1008 wrote:
> Note that the accuracy of this depends on several factors, such
as
how
> long the measured interval is compared to the basic unit of
timekeeping
> (IOW if you want to measure the execution time of a short sequence
of
> instructions, you need to loop a few million times and divide the
> result), and how much overhead is incurred in calling the timing
> routines.
>
> poc
Hi Patrick.
Actually, no.
Since the virtual timer is incremented only while the process is
actually running on the cpu, the time difference from when you first
"start" the timer, and when you "stop" the timer
(in Ranjan's case, just before exit), gives the most accurate time
possible on a system like linux.
Not what I meant. I know the system is only timing the process while
it's running, but there are still overheads to calling the timing
routines which count against the process (as they are running in user
state before entering the system and after exiting it). If the code of
interest is short compared to this, the overhead will skew the result,
but Ranjan hasn't said anything about the code to be measured so we
don't know if this matters or not. Eliminating these factors is
possible but tricky.
What Ranjan can do also, is to set the process scheduling class
to REALTIME (which
is as approximate to REALTIME as a multiuser virtual mem system can
provide). Thus he will get a very accurate benchmark for the segment
of code he wants to measure.
I doubt that will make any difference. As you said, the timers are
measuring process virtual time, so whether the process is scheduled
more or less frequently shouldn't matter.
poc