EDIT- for those that are interested.

Of 20 v7 inconclusives, 18 of them are against a v7 opencl_ati_ of one type or another.

Just got some more inconlusives, however these are Cuda50 v other Cuda applications.
One of which involves 2 GTX 560Ti's.

setiathome enhanced x41zc, Cuda 3.20 (314.22 driver)
Spike count: 0
Autocorr count: 2
Pulse count: 0
Triplet count: 1
Gaussian count: 0


setiathome enhanced x41zc, Cuda 5.00 (320.18 driver)
Spike count: 1
Autocorr count: 2
Pulse count: 0
Triplet count: 1
Gaussian count: 0

---

Grant
Darwin NT

Now that my GTX460 cruncher is on stock app for the first time, it downloaded its first Nvidea AP to crunch using opencl. However, GPU utilization is very low. For MB WUs, GPU utilization is typically 80-90% (for 1 v7 WU), but the AP was only showing ca 4% GPU utilization. I freed up one CPU core and this increased to 18% with occaisional bursts up to 100%. Freeing up a second CPU core made no difference. Is this normal?

The AP WU is currently 24% complete and has been running for 1.5 hours, so it is heading for about 6 hours to complete. Does this sound right for a GTX460 running at 857MHz?

---

Now that my GTX460 cruncher is on stock app for the first time, it downloaded its first Nvidea AP to crunch using opencl. However, GPU utilization is very low. For MB WUs, GPU utilization is typically 80-90% (for 1 v7 WU), but the AP was only showing ca 4% GPU utilization. I freed up one CPU core and this increased to 18% with occaisional bursts up to 100%. Freeing up a second CPU core made no difference. Is this normal?

The AP WU is currently 24% complete and has been running for 1.5 hours, so it is heading for about 6 hours to complete. Does this sound right for a GTX460 running at 857MHz?

Freeing a core (just one for one card) for OpenCL is normal, yes. Can't comment on timings, I'll leave that for the OpenCL specialists.

Have now taken to manually aborting:
-AP WUs on non AVX machines
-v7 cuda50 WUs on all machines
-v7 cuda23 WUs on all GTX580 based machines

If you do that you'll never get APR to settle and scheduler select 'fastest' app. If it's an intermediate measure until you go anon again...

William,

Doesn't appear to be the case. Aborting them is working quite well. The appearances of cuda50 and cuda23 WU is now almost non existent. Haven't had a cuda23 WU in ages ... and cuda50 is now only popping up once in a blue moon ... seems to work better than processing the WUs ... would recommend this approach to anyone to try

:)

---

Claggy

Don't think so mate.

At the moment things seem to be running wellish. Over the last 2.5 hours I have only received 3 x cuda50 GPU WUs, and 2 x AP WUs on boxes that I don't want AP on. All were aborted.

See my advice to use 'venues' in response to another post of yours.

I will say something though that I think you should look at.

The limiting of the GPU allocation to 0.02 CPUs or 0.03 CPUs has the effect of nobbling the GPU. The limit should be upwards of 0.10 CPU (I ran my boxes at 0.20 CPU per GPU prior to v7 migration).

What this does is to ensure that the GPU gets the resources it needs when it needs them. In observing my systems, I have seen utilisation regularly jump to 0.07 - 0.14. In using 0.20 CPUs, it doesn't mean that it has 0.20 CPUs allocated permanently to the GPU. If the GPU isn't using it, then the processor will. It's just an allocation of resource issue that keeps the GPUs munching as fast as they can.

You misunderstand what the 0.02, or 0.10, or whatever means or does.

It does not limit CPU usage.

It controls BOINC's scheduling. If you run 50 GPU tasks at once (first figure), or 10 GPU tasks at once (second figure), the CPU bits will add up to a whole 1.00 CPU, and BOINC will stop running one CPU task (will run one fewer CPU task than normal). That's all.

Yep, I'm aware of that ...

The 0.02 figure is one we've been putting in published and distributed app_info files (e.g. via the installer) for years.

Yep, I'm aware of that too...

Basically, it stops the CPU application count jumping all over the place. NVidia applications are normally happy to run even when every CPU core has a BOINC task running on it (ATI experience may be different). If your experience is different - say for a host with more than one high-power GPU, but a weak CPU, which I would call an unbalanced build - reduce the active CPU count yourself by adjusting the

On multiprocessors, use at most 
Enforced by version 6.1+	100% of the processors

for the venue that host is assigned to.

Yep, tried reducing active CPUs as well ...

Best results obtained by changing 0.02 CPU to 0.20 CPU. In doing this, RAC increased to highest levels of all configurations that I tried. QED in my case. Have a look at Smallpox, it's an i7 3930K with 2 x GTX580s (ranked around #13). You would have to say that it's a bloody good performer wouldn't you given the GPU tech.

cheers mate ...

ps. that is before v7 migration which throws some uncertainty into the mix.

---

Best results obtained by changing 0.02 CPU to 0.20 CPU. In doing this, RAC increased to highest levels of all configurations that I tried. QED in my case. Have a look at Smallpox, it's an i7 3930K with 2 x GTX580s (ranked around #13). You would have to say that it's a bloody good performer wouldn't you given the GPU tech.

How exactly do you attribute effect to cause, with that one?

I'm genuinely interested, but sceptical. If there's a real relationship (both demonstratable and explicable, scientifically), then we ought to change the installer we're writing.

Have now taken to manually aborting:
-AP WUs on non AVX machines
-v7 cuda50 WUs on all machines
-v7 cuda23 WUs on all GTX580 based machines

If you do that you'll never get APR to settle and scheduler select 'fastest' app. If it's an intermediate measure until you go anon again...

William,

Doesn't appear to be the case. Aborting them is working quite well. The appearances of cuda50 and cuda23 WU is now almost non existent. Haven't had a cuda23 WU in ages ... and cuda50 is now only popping up once in a blue moon ... seems to work better than processing the WUs ... would recommend this approach to anyone to try

:)

That is because aborts count as errors against your quota.

edit: I suggest to let at least a few through, slow as they might be.

---

A person who won't read has no advantage over one who can't read. (Mark Twain)

Best results obtained by changing 0.02 CPU to 0.20 CPU. In doing this, RAC increased to highest levels of all configurations that I tried. QED in my case. Have a look at Smallpox, it's an i7 3930K with 2 x GTX580s (ranked around #13). You would have to say that it's a bloody good performer wouldn't you given the GPU tech.

How exactly do you attribute effect to cause, with that one?

I'm genuinely interested, but sceptical. If there's a real relationship (both demonstratable and explicable, scientifically), then we ought to change the installer we're writing.

Richard, I have changed things at my end over time and watched the results. In essence I do not care if you do not believe me or do not want to take what I say at face value. That is your choice and I accept it. I can only speak from my experience and my experience with these machines tells me that 0.03 CPU or something similar reduces processing capabilities for the GPUs ... after a particular value it becomes irrelevant however I chose to set it higher than needed.

When the optimised installer comes out and I will once again be able to set up the system to the manner I like, I will revert to 0.20 CPU and then experiment for myself from there.

cheers

---

William, ain't going to happen pal

---

It looks like to now noone posted a complete app_info.xml part for stock SAHv7 CPU app, or?

I made one (for 64bit OS), please let me know if it's OK or wrong. [EDIT: It's OK, thanks William.]

    <app>
        <name>setiathome_v7</name>
    </app>
    <file_info>
        <name>setiathome_7.00_windows_intelx86.exe</name>
        <executable/>
    </file_info>
    <file_info>
        <name>libfftw3f-3-3_upx.dll</name>
        <executable/>
    </file_info>
   <app_version>
        <app_name>setiathome_v7</app_name>
        <version_num>700</version_num>
         <platform>windows_intelx86</platform>
          <file_ref>
            <file_name>setiathome_7.00_windows_intelx86.exe</file_name>
            <main_program/>
         </file_ref>
        <file_ref>
	    <file_name>libfftw3f-3-3_upx.dll</file_name>
        </file_ref>
     </app_version>
     <app_version>
        <app_name>setiathome_v7</app_name>
        <version_num>700</version_num>
         <platform>windows_x86_64</platform>
          <file_ref>
            <file_name>setiathome_7.00_windows_intelx86.exe</file_name>
            <main_program/>
         </file_ref>
        <file_ref>
	    <file_name>libfftw3f-3-3_upx.dll</file_name>
        </file_ref>
     </app_version>

http://boinc2.ssl.berkeley.edu/sah/download_fanout/setiathome_7.00_windows_intelx86.exe
http://boinc2.ssl.berkeley.edu/sah/download_fanout/libfftw3f-3-3_upx.dll


* Best regards! :-) * Philip J. Fry, team seti.international founder. * Optimize your PC for higher RAC. * SETI@home needs your help. *

---

It looks like to now noone posted a complete app_info.xml part for stock SAHv7 CPU app, or?

I made one (for 64bit OS), please let me know if it's OK or wrong.

looks good

---

A person who won't read has no advantage over one who can't read. (Mark Twain)

Now that my GTX460 cruncher is on stock app for the first time, it downloaded its first Nvidea AP to crunch using opencl. However, GPU utilization is very low. For MB WUs, GPU utilization is typically 80-90% (for 1 v7 WU), but the AP was only showing ca 4% GPU utilization. I freed up one CPU core and this increased to 18% with occaisional bursts up to 100%. Freeing up a second CPU core made no difference. Is this normal?

The AP WU is currently 24% complete and has been running for 1.5 hours, so it is heading for about 6 hours to complete. Does this sound right for a GTX460 running at 857MHz?

Freeing a core (just one for one card) for OpenCL is normal, yes. Can't comment on timings, I'll leave that for the OpenCL specialists.

Thanks Richard.

In the end it finished normally in 3.5 hours. Is there a clever way of freeing up one CPU core when the GPU is running an AP but when it is running MBs which do not need it? I do not want to loose 25% of my CPU RAC and cannot lways be present to baby sit the machine.

Not sure why the apparent GPU usage was so low, but it has returned to 70-80% now that the GPU is cruching MBs again.

---

For some strange reason libfftw3f-3-3_upx.dll keeps getting deleted in all my rigs. Three of them are running AVG while my main rig has Bitdefender. I have put up an exclusion for this as well as the v7 main executable files, although neither gave any warnings. I thought the warnings were only for the exe file.

All the completed v7 WUs are now piling under validation pending.
______________

Now that my GTX460 cruncher is on stock app for the first time, it downloaded its first Nvidea AP to crunch using opencl. However, GPU utilization is very low. For MB WUs, GPU utilization is typically 80-90% (for 1 v7 WU), but the AP was only showing ca 4% GPU utilization. I freed up one CPU core and this increased to 18% with occaisional bursts up to 100%. Freeing up a second CPU core made no difference. Is this normal?

The AP WU is currently 24% complete and has been running for 1.5 hours, so it is heading for about 6 hours to complete. Does this sound right for a GTX460 running at 857MHz?

Yes, you need to free a CPU core for astropulses.

You can speed things up.

Add the following params to your ap_cmdline.txt
-unroll 10 -ffa_block 6144 -ffa_block_fetch 1536.

---

With each crime and every kindness we birth our future.

There doesn't seem to any stock linux app for nvidia, will there be an opti app on Monday?


Will Lunatics_x41g_linux64_cuda32 work with v7?

Is there a clever way of freeing up one CPU core when the GPU is running an AP but when it is running MBs which do not need it? I do not want to loose 25% of my CPU RAC and cannot lways be present to baby sit the machine.

With your version of BOINC, you can do this with an app_config.xml file in your SETI data directory. Here's mine - set the gpu usage value to the values you need for your card. You don't need the max concurrent line - I use it to limit the number of AP's running at one time. Setting a value of one for the cpu usage will reserve one core but only while the AP task is running.


<app_config>
<app>
<name>astropulse_v6</name>
<max_concurrent>2</max_concurrent>
<gpu_versions>
<gpu_usage>.33</gpu_usage>
<cpu_usage>1.0</cpu_usage>
</gpu_versions>
</app>
<app>
<name>setiathome_v7</name>
<gpu_versions>
<gpu_usage>.33</gpu_usage>
<cpu_usage>.06</cpu_usage>
</gpu_versions>
</app>
</app_config>

Add the following params to your ap_cmdline.txt
-unroll 10 -ffa_block 6144 -ffa_block_fetch 1536.

Mike, will r1316 accept those command line switches? (question I asked in msattler's thread).

---

Another Fred
Support SETI@home when you search the Web with GoodSearch or shop online with GoodShop.

There doesn't seem to any stock linux app for nvidia, will there be an opti app on Monday?


Will Lunatics_x41g_linux64_cuda32 work with v7?

Frankly we haven't the faintest idea.
It has AC code but it's not been alphaed on Linux.
update your app_info with the tags that have been published and give it a try?

Pay close attention to any problems.

x41g is going to have a higher rate of inconclusives, but it may just work.

---

A person who won't read has no advantage over one who can't read. (Mark Twain)

Well, things seem to have settled a bit here.
My RAC drop is not so declined as before.
I have all the kibble I could wish for under the still enforced 100 task bit.

I suppose the drop in RAC is due to the fact that pendings are up a bit, and I am waiting for the new opti installer to do more than one task per GPU.

I have checked a couple of rigs, and it looks like I am at 90+ on all, so the few percent I am not using on a few rigs might account for something.

---

"Time is simply the mechanism that keeps everything from happening all at once."

Is there a clever way of freeing up one CPU core when the GPU is running an AP but when it is running MBs which do not need it? I do not want to loose 25% of my CPU RAC and cannot lways be present to baby sit the machine.

With your version of BOINC, you can do this with an app_config.xml file in your SETI data directory. Here's mine - set the gpu usage value to the values you need for your card. You don't need the max concurrent line - I use it to limit the number of AP's running at one time. Setting a value of one for the cpu usage will reserve one core but only while the AP task is running.


<app_config>
<app>
<name>astropulse_v6</name>
<max_concurrent>2</max_concurrent>
<gpu_versions>
<gpu_usage>.33</gpu_usage>
<cpu_usage>1.0</cpu_usage>
</gpu_versions>
</app>
<app>
<name>setiathome_v7</name>
<gpu_versions>
<gpu_usage>.33</gpu_usage>
<cpu_usage>.06</cpu_usage>
</gpu_versions>
</app>
</app_config>

Add the following params to your ap_cmdline.txt
-unroll 10 -ffa_block 6144 -ffa_block_fetch 1536.

Mike, will r1316 accept those command line switches? (question I asked in msattler's thread).

With r_1316 you need to add/edit it in the cmdline in appinfo.xml.

---

With each crime and every kindness we birth our future.

There doesn't seem to any stock linux app for nvidia, will there be an opti app on Monday?


Will Lunatics_x41g_linux64_cuda32 work with v7?

Frankly we haven't the faintest idea.
It has AC code but it's not been alphaed on Linux.
update your app_info with the tags that have been published and give it a try?

Pay close attention to any problems.

x41g is going to have a higher rate of inconclusives, but it may just work.

One WU finished waiting for validation.

http://setiathome.berkeley.edu/result.php?resultid=3023153356

Will keep an eye one things.