BT 0.46

[jjwhalen]

(Changed) CPU%: if CPU % < 1% add 1 digit, like 0.001 and round of properly. 0.000 should be shown as empty.

Sorry, but in v0.46 PrimeGrid's AP26 Search (cuda23) v1.01 is still showing no CPU activity (CPU % = null field, no CPU time in parentheses) through its entire run   According to PrimeGrid's database, my most recent result reported an actual CPU time of 0.64sec on a run time of 628.64sec, or 0.102%.  That's on an Intel Q9400 at 2.66GHZ, with an EVGA GTS250 moderately overclocked.

This still isn't a big deal for me, but I predict that as other projects optimize their CUDA (& possibly ATI) apps, you'll be seeing more tiny CPU:GPU ratios like this (depending, of course, on what kind of data they are crunching).

Best wishes.

[fred]

(Changed) CPU%: if CPU % < 1% add 1 digit, like 0.001 and round of properly. 0.000 should be shown as empty.

Sorry, but in v0.46 PrimeGrid's AP26 Search (cuda23) v1.01 is still showing no CPU activity (CPU % = null field, no CPU time in parentheses) through its entire run   According to PrimeGrid's database, my most recent result reported an actual CPU time of 0.64sec on a run time of 628.64sec, or 0.102%.  That's on an Intel Q9400 at 2.66GHZ, with an EVGA GTS250 moderately overclocked.

This still isn't a big deal for me, but I predict that as other projects optimize their CUDA (& possibly ATI) apps, you'll be seeing more tiny CPU:GPU ratios like this (depending, of course, on what kind of data they are crunching).

Best wishes.

The problem is the time is probably used most at the beginning and the end. Check the elapsed time the value () should be the cpu run time, the other value should be the wall clock time.

[jjwhalen]

(Changed) CPU%: if CPU % < 1% add 1 digit, like 0.001 and round of properly. 0.000 should be shown as empty.

Sorry, but in v0.46 PrimeGrid's AP26 Search (cuda23) v1.01 is still showing no CPU activity (CPU % = null field, no CPU time in parentheses) through its entire run  According to PrimeGrid's database, my most recent result reported an actual CPU time of 0.64sec on a run time of 628.64sec, or 0.102%.  That's on an Intel Q9400 at 2.66GHZ, with an EVGA GTS250 moderately overclocked.

This still isn't a big deal for me, but I predict that as other projects optimize their CUDA (& possibly ATI) apps, you'll be seeing more tiny CPU:GPU ratios like this (depending, of course, on what kind of data they are crunching).

Best wishes.

The problem is the time is probably used most at the beginning and the end. Check the elapsed time the value () should be the cpu run time, the other value should be the wall clock time.

Right.  The problem with the v1.01 AP26/cuda23 is that there is no () value in the ET field, and the CPU % field remains at zero (blank), even with the task completed (Ready to report).  It appears that CPU activity <1sec and/or <1% just is not registering, or is being rounded down to nada.

You're probably right about the CPU feeding data to the GPU only at the beginning and receiving from it at the very end.  AP26 is literally searching for an Arithmetic Progression of 26 prime numbers.  The dataset is probably long and narrow, and can be crunched by the GPU without a lot of back-and-forth.  This differs from (say) GPUGRID's ACEMD2 app, where they're playing with high-res 3D molecular models--the CPU load is a sustained 10~12% of ET for the entire run of the task, with a big spike at the beginning.

B/W

[fred]

Right.  The problem with the v1.01 AP26/cuda23 is that there is no () value in the ET field, and the CPU % field remains at zero (blank), even with the task completed (Ready to report).  It appears that CPU activity <1sec and/or <1% just is not registering, or is being rounded down to nada.

You're probably right about the CPU feeding data to the GPU only at the beginning and receiving from it at the very end.  AP26 is literally searching for an Arithmetic Progression of 26 prime numbers.  The dataset is probably long and narrow, and can be crunched by the GPU without a lot of back-and-forth.  This differs from (say) GPUGRID's ACEMD2 app, where they're playing with high-res 3D molecular models--the CPU load is a sustained 10~12% of ET for the entire run of the task, with a big spike at the beginning.

B/W

If there is no value between () than the cpu time is not reported back to the BOINC client.
I made a note to do some testing when I have a cuda 2.3 computer.

[jjwhalen]

--SNIIP--
If there is no value between () than the cpu time is not reported back to the BOINC client.

I respectfully disagree.  I suspended a task in progress.  The boinc_task_state.xml reads as follows:

<active_task>
    <project_master_url>http://www.primegrid.com/</project_master_url>
    <result_name>ap26_21231867_21231877_128_1</result_name>
    <checkpoint_cpu_time>0.390002</checkpoint_cpu_time>
    <checkpoint_elapsed_time>375.264000</checkpoint_elapsed_time>
    <fraction_done>0.777778</fraction_done>
</active_task>

As I said in my original post, CPU time is small, but still nonzero.  Also, please remember that the client is reporting nonzero CPU time back to the project server on all these tasks.

B/W

[fred]

I respectfully disagree.  I suspended a task in progress.  The boinc_task_state.xml reads as follows:

<active_task>
    <project_master_url>http://www.primegrid.com/</project_master_url>
    <result_name>ap26_21231867_21231877_128_1</result_name>
    <checkpoint_cpu_time>0.390002</checkpoint_cpu_time>
    <checkpoint_elapsed_time>375.264000</checkpoint_elapsed_time>
    <fraction_done>0.777778</fraction_done>
</active_task>

As I said in my original post, CPU time is small, but still nonzero.  Also, please remember that the client is reporting nonzero CPU time back to the project server on all these tasks.

B/W

Ok now I see what's the problem, I should be able to correct it.