Hi Andre,

Thanks for your hints.

I increase the sampling interval to 100,001 and find the result is reasonable to estimate the execution time. But the sampling result is not reliable if the interval is below 100,001.

I also evaluate the intervals of 300,001 and 500,001 for CPU_CLK_UNHALTED, and the sampling result scales well.


On Thu, Aug 20, 2009 at 11:01 PM, Andre Richter <arichter@mytum.de> wrote:
Hi Paul,

look at your CPU utilization during the test.
If it's not 100%, then you might try this:

9.281s * (CPU Utilization)  =   1.35s   ??

Cycles are not counted when your CPU is in idle or not fully utilized. That may be where your seconds are gone missing?

Best regards,
Andre

Am 20.08.2009 um 16:38 schrieb Paul Yuan:

Hi @ll,

I used OProfile to sample CYCLE on AMD Opteron 2.0GHz.

opcontrol --event=CPU_CLK_UNHALTED:3001 --image=gzip.exe

The sampling result is 902,645.   The execution time of gzip.exe is 9.281s (linux time command).

Estimated execution time: sampling result * sampling interval / CPU frequency
902,645 * 3001 / 2,000,000,000 = 1.35s.  But this result is very different from 9.281s.

BTW, when I changed event count to 1,0001 the sampling result is 752,647. And changed to 10,0001, the result is 167,612.
Why does not the sampling result scale with the event count?

--
Regards,
Paul Yuan (Ԭ)
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july_______________________________________________
oprofile-list mailing list
oprofile-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oprofile-list




--
Regards,
Paul Yuan (Ԭ)