The remaining doubt is about the Nvidia drivers, should I keep using the old 266.58 that was needed by the NV-r521 to not clog the CPUs?
(In fact, 266.58 is Ok and I have no reason to upgrade it, but one of my hosts has 2 560Ti's and the older driver for them is 266.66 which is said that has some issues...)

270.xx and up suffer from excess CPU usage. AFAIK it still not fixed in latest drivers.
I use 263.xx for crunching with GTX250 and it goes very well.

What about using a GTX 680 when the only drivers are 301.10?

How high is "excessive CPU usage" as a % of a CPU on a 2.66GHz Core 2 Quad please?

It will use a full core.
Thats why its called 100% CPU bug.

It took AMD almost 6 month to fix this bug so you will have to see how long it takes for nvidia to resolve this.

100%! What is the split between Interrupt, DPC, Kernel and User time?
To me this sounds like a synchronisation issue and I suspect the code could be changed to get round this. Has the Open CL threading model been changed?

Do you realy mean a "full core"? This would mean 2 CPUs would be 100% loaded on an i7 which I suspect is not the case.

The remaining doubt is about the Nvidia drivers, should I keep using the old 266.58 that was needed by the NV-r521 to not clog the CPUs?
(In fact, 266.58 is Ok and I have no reason to upgrade it, but one of my hosts has 2 560Ti's and the older driver for them is 266.66 which is said that has some issues...)

270.xx and up suffer from excess CPU usage. AFAIK it still not fixed in latest drivers.
I use 263.xx for crunching with GTX250 and it goes very well.

What about using a GTX 680 when the only drivers are 301.10?

How high is "excessive CPU usage" as a % of a CPU on a 2.66GHz Core 2 Quad please?

It will use a full core.
Thats why its called 100% CPU bug.

It took AMD almost 6 month to fix this bug so you will have to see how long it takes for nvidia to resolve this.

100%! What is the split between Interrupt, DPC, Kernel and User time?
To me this sounds like a synchronisation issue and I suspect the code could be changed to get round this. Has the Open CL threading model been changed?

Do you rely mean a "full core"? This would mean 2 CPUs would be 100% loaded on an i7 which I suspect is not the case.

Raistmer tried to fix it with different functions without success.
It has to be fixed by Nvidia.

On the other hand GPU app benefit outweighs anyways.
Running 2 APs in less than 2 hours instead of 1 in 6 - 7 hours is not to shabby i imagine.

---

With each crime and every kindness we birth our future.

This system doesn't suffer from excessive CPU usage:
Win7, i5-2500k
GTX 570
296.35 (quadro driver using modded inf)




I think at most its using 20% CPU.

---

Tested it on my ATI HD6850, 2GB, Catalysts 12.3
Latest AP on ATI, finished all right, faster than I am used to as well. {grin}

I checked with GPU-Z, but a little late to be honest. However, what I saw was a load of 25% alternated with no load, CPU load max 4%. The AP was 7.23 percent blanked.

Will wait for the next.

---

Tested it on my ATI HD6850, 2GB, Catalysts 12.3
Latest AP on ATI, finished all right, faster than I am used to as well. {grin}

I checked with GPU-Z, but a little late to be honest. However, what I saw was a load of 25% alternated with no load, CPU load max 4%. The AP was 7.23 percent blanked.

Will wait for the next.

You should increase unroll factor to 10 at least to get better speed on your card.
Also FFA_block and FFA_block_fetch.

---

With each crime and every kindness we birth our future.

I've read somewhere that DATA_CHUNK_UNROLL should be setted to: half of the Max compute number units:

Can anyone confirm this please??

//TRuEQ

---

TRuEQ & TuVaLu

I also saw that the sbs can be set in <cmdline>-instances_per_device 2 -unroll 9 -ffa_block 8192 -ffa_block_fetch 4096 -sbs 256 -hp</cmdline>

default is 128

I saw somewhere that it isn't implemented yet.

But in my stderr it looks like it is set to 256....
Can someone explain this please?


<core_client_version>7.0.24</core_client_version>
<![CDATA[
<stderr_txt>
Number of app instances per device setted to:2
DATA_CHUNK_UNROLL setted to:9
FFA thread block override value:8192
FFA thread fetchblock override value:4096
Maximum single buffer size setted to:256MB
Running on device number: 0
DATA_CHUNK_UNROLL at default:9
Priority of worker thread raised successfully
Priority of process adjusted successfully, high priority class used
OpenCL platform detected: Advanced Micro Devices, Inc.
BOINC assigns 0 device, slots 0 to 1 (including) will be checked
Used slot is 0; Used GPU device parameters are:
Number of compute units: 18
Single buffer allocation size: 256MB
max WG size: 256

---

TRuEQ & TuVaLu

You should increase unroll factor to 10 at least to get better speed on your card.
Also FFA_block and FFA_block_fetch.

It doesn't happen often that someone talks to me in riddles, but now it's happened. :-)

Care to elaborate, please?
Just think I am a newbie. And be gentle with that whip. Nice....

---

I've read somewhere that DATA_CHUNK_UNROLL should be setted to: half of the Max compute number units:

Can anyone confirm this please??

//TRuEQ

Thats the safe value yes.

But for fast cards it can be increased above number of CUs.
So long it dont result in invalids or getting screen lags.

Unroll 10 - 12 should work on high end cards.
Some cards can cope with 16.

---

With each crime and every kindness we birth our future.

You should increase unroll factor to 10 at least to get better speed on your card.
Also FFA_block and FFA_block_fetch.

It doesn't happen often that someone talks to me in riddles, but now it's happened. :-)

Care to elaborate, please?
Just think I am a newbie. And be gentle with that whip. Nice....

From the Lunatics Installer 0.40 Release Notes:

AP/MB:
-instances_per_device N how many tasks you want to run in parallel. Inverse of <count>.

-hp gives the app high priority

-no_cpu_lock prevents the app from using only a specific CPU core

AP only:
-v505 to process AP 5.05 tasks

-sbs 128 is the max size of single buffer that can be used in program. Lower limit is 128MB, upper - max size allowed particular card. [Note: not active yet]

-unroll 4 Optimal at half the number of Compute Units of the GPU. Lower values also reduce VRAM use. Decrease if you experience lags.

-ffa_block 2048 defines how many different periods GPU will process per single kernel call

-ffa_block_fetch 1024 defines how many threads will be used in FFA initial fetch kernel

ffa_block should be divisible by ffa_block_fetch. Going too high will result in premature 30/30 exit errors.

Claggy

You should increase unroll factor to 10 at least to get better speed on your card.
Also FFA_block and FFA_block_fetch.

It doesn't happen often that someone talks to me in riddles, but now it's happened. :-)

Care to elaborate, please?
Just think I am a newbie. And be gentle with that whip. Nice....

Sorry i didnt intend to riddle.

You can edit your appinfo

command line param to -unroll 10 -ffa_block 8192 -ffa_block_fetch 4096 -no_CPU_lock.

That should speed up your card and give better run times.

---

With each crime and every kindness we birth our future.

I'm using 268,36 on my almost new notebook and have just finished the first AP, all went fine and the CPU use was rather low, mostly under 5%.

The Stderr output contains some stuff that I wonder about, is there something I should do or is that all normal info?

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

Your stderr completelly fine, just many restarts were done for this task.

Sorry i didnt intend to riddle.

LOL, well thanks for the explanation. You too Claggy!

All lines in app_info.xml adjusted.

---

I've read somewhere that DATA_CHUNK_UNROLL should be setted to: half of the Max compute number units:

Can anyone confirm this please??

//TRuEQ

Thats the safe value yes.

But for fast cards it can be increased above number of CUs.
So long it dont result in invalids or getting screen lags.

Unroll 10 - 12 should work on high end cards.
Some cards can cope with 16.

Then I understand.

Thank you Mike

---

TRuEQ & TuVaLu

Sorry i didnt intend to riddle.

LOL, well thanks for the explanation. You too Claggy!

All lines in app_info.xml adjusted.

You have a typo in your appinfo.
Please check.

---

With each crime and every kindness we birth our future.

DATA_CHUNK_UNROLL setted to:10
FFA thread block override value:8192
FFA thread fetchblock override value:4096
CPU affinity ajustment will be skipped
Maximum single buffer size setted to:128MB

better?

Although, it's "set", not "setted".
The verb goes set, set, set. Very easy that one. :P

Also adjusted -unroll to 6, instead of 10. It appears my GPU only has 12 Compute Units, so if half is optimal, then half it is.

-unroll 4 Optimal at half the number of Compute Units of the GPU. Lower values also reduce VRAM use. Decrease if you experience lags.

---

DATA_CHUNK_UNROLL setted to:10
FFA thread block override value:8192
FFA thread fetchblock override value:4096
CPU affinity ajustment will be skipped
Maximum single buffer size setted to:128MB

better?

Although, it's "set", not "setted".
The verb goes set, set, set. Very easy that one. :P

Also adjusted -unroll to 6, instead of 10. It appears my GPU only has 12 Compute Units, so if half is optimal, then half it is.

-unroll 4 Optimal at half the number of Compute Units of the GPU. Lower values also reduce VRAM use. Decrease if you experience lags.

Yep, much better.

Nice run time as well.
Looks good.

---

With each crime and every kindness we birth our future.

100%! What is the split between Interrupt, DPC, Kernel and User time?
To me this sounds like a synchronisation issue and I suspect the code could be changed to get round this. Has the Open CL threading model been changed?

Do you realy mean a "full core"? This would mean 2 CPUs would be 100% loaded on an i7 which I suspect is not the case.

Ray, I would happy if you can provide this info ;)
And yes, I suspect sync issue too.
Yes, perhaps NV changed OpenCL sync model to spinloop.
AFAIK CUDA supports 2 synch models and they configurable via CUDA API.
So far nobody discover configuration possibility for NV OpenCL implementation and such config not part of OpenCL standart too.
There was trick offered on NV forums to create many fake contexts (it was supposet that OpenCL sync model corresponds CUDA's "auto" mode that will switch between sync strategies basing on number of contexts vs number of CPUs). I implemented fake contexts creation. It did not help.
If you have some ideas how to tell NV's OpenCL runtime to use yield instead of spinloop, please let me know.

And to be precise it should be "whole logical CPU usage bug" instead of "whole physical core usage bug".

This system doesn't suffer from excessive CPU usage:
Win7, i5-2500k
GTX 570
296.35 (quadro driver using modded inf)




I think at most its using 20% CPU.

Good to know this!
Now it's interesting to know what caused that, your driver version, your Os version or your GPU version... or smth we even can't imagine ;)

I've read somewhere that DATA_CHUNK_UNROLL should be setted to: half of the Max compute number units:

Can anyone confirm this please??

//TRuEQ

Best value depends on number for memory channels too.
there are 32 (I write by memory not looking to code and wrote that code long ago so mistakes possible) workitems per "unroll". Wavefront supports 64. Each compute unit needs at least 2 wavefronts for full load (actually better would be nicer).