PAPI Library verifiction

[pushpen]

Dear all,

I would like to request you to define a reason behind the PAPI library - output verification.

I have run the test code flops.c around 10 times and I have got following results...

Question: Can anybody explain why MFLOPS are varying for the same program ????? as the input data size is remained as it is, as shown below:
-------------
Real_time: 6.423375 Proc_time: 6.333596 Total flpins: 2001605376 MFLOPS: 316.029877
flops.c PASSED
Real_time: 6.520362 Proc_time: 6.433974 Total flpins: 2001479936 MFLOPS: 311.079865
flops.c PASSED
Real_time: 6.523087 Proc_time: 6.429263 Total flpins: 2001472896 MFLOPS: 311.306732
flops.c PASSED
Real_time: 6.374007 Proc_time: 10.498365 Total flpins: 2001718912 MFLOPS: 190.669586
flops.c PASSED
Real_time: 6.546931 Proc_time: 6.457129 Total flpins: 2001473664 MFLOPS: 309.963409
flops.c PASSED
Real_time: 6.370028 Proc_time: 10.492290 Total flpins: 2001657216 MFLOPS: 190.774094
flops.c PASSED
Real_time: 6.511530 Proc_time: 6.431089 Total flpins: 2001502976 MFLOPS: 311.223053
flops.c PASSED
Real_time: 6.373152 Proc_time: 10.499630 Total flpins: 2001659904 MFLOPS: 190.640991
flops.c PASSED
Real_time: 6.517484 Proc_time: 6.430055 Total flpins: 2001484544 MFLOPS: 311.270233
flops.c PASSED
Real_time: 6.369537 Proc_time: 10.487989 Total flpins: 2001656064 MFLOPS: 190.852219
flops.c PASSED
---------

I am new, so sorry if anybody has already justified before but I could not find any justification so please guide me about this.

Thank you

Pushpen

[Dan Terpstra]

It's because your system is not totally quiet.
MFLOPS = flpins/Proc_time
Although flpins is constant, at least to about 0.01%, the measured Proc_time is bimodal between ~6.4 and 10.5 seconds. It's that variability in time that does it. This may be due to a daemon or other interrupt service that occurs periodically during the execution of your program.

[nickspapi]

Hi Dan,

I have a similar problem with the original poster, but with the difference that I am using the PAPI_get_virt_nsec() or PAPI_get_virt_usec() functions, which are supposed to account only for the when a thread is in user mode (so execution times of external sources should not be accounted). The same application under the same workload executes once ~5sec and once ~7sec, while another application once ~7sec and another ~10sec. The elapsed time is actually ~5sec (or ~7sec for the second app).

The application is in Java and contacts an agent in native code to use the PAPI counters. Only 2 Java threads are shown to be executed by executing "top H" - and the one has almost constant CPU utilization of >98%. I am initializing the libraries and register the threads that will be using the meters. During the installation of PAPI I got:

....
checking for working CLOCK_THREAD_CPUTIME_ID POSIX 1b timer... yes
checking for thread virtual clock or cycle counter... clock_thread_cputime_id
...

which would suggest everything is fine. The same applications return standard results on another machine with a single CPU further suggesting that there's nothing wrong with the approach.

The CPU of the "problematic" machine is Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz and perfex -i returns the cpu_type to be 18 (Intel Core 2).
Could this behaviour have anything to do with the fact that I disabled the second core of the processor (echo 0 >> /sys/devices/system/cpu/cpu1/online)? Is there any other issue you can think?

Thank you for your help,

Best Regards,
Nick