and also because of the excessive CPU usage.

Claggy

Let's be more precise. Could you point to reports about high CPU usage on 280.xx drivers? Maybe I missed them?

And don't forget it's a test!. Good tester should try one config, record all possible issues, then try another one. We want to get fuill picture here, not just to find good config for tester himself and stay in dark for all other possible configs.

From this point of view I would recommed all who experience high CPU usage on low blanked tasks to test this behavior with 280.xx drivers, report it, and if high CPU usage remains, suspend testing until next binary/driver update or revert to proven driver version like 267.xx.

and also because of the excessive CPU usage.

Claggy

Let's be more precise. Could you point to reports about high CPU usage on 280.xx drivers? Maybe I missed them?

I've been doing AP and v7 benches all day with 280.19 and Cat 11.7/11.8, both the NV_r521 apps and the ATI_r521 apps use lots of CPU, as does the v7 ATI__r331 app, bench results in their respective threads.
I also did a couple of AP tasks with 280.19 and Cat 11.7, the NV_r521 app even got stalled by a CPU Einstein task starting, i had to suspend the Einstein task to get the GPU usage to go back up,

Here are the two NV_AP tasks that took a long time and had heavy CPU usage (normal CPU usage is around 600 secs for 0% Blanked tasks):

resultid=2014222887

resultid=2014199218

and here are two ATI_AP tasks that had excessive CPU usage with Cat 11.7:

resultid=2000626885

resultid=2000626711

I've since then gone back down to 267.24 and Cat 11.5/SDK2.5

Claggy

I see, thanks.
Interesting, that zero-blanked task has lower CPU time than low-blanked one... two times increased elapsed time... It's definitely not normal behavior.

I await another reports, preferably from NV-GPUs only and different NV GPU generations, non-FERMI too.

I see, thanks.
Interesting, that zero-blanked task has lower CPU time than low-blanked one... two times increased elapsed time... It's definitely not normal behavior.

I await another reports, preferably from NV-GPUs only and different NV GPU generations, non-FERMI too.

The first NV task i ran with 280.19 had about 5% GPU usage, i suspended it after an hour and a half at 50%, i let the GTX460 do a couple of shorties, then unsuspended the AP task, then it showed almost normal GPU usage,

Claggy

Add this to my cmdline -no_cpu_lock with space before the -no_cpu_lock raistmer’s post

-no_cpu_lock - disables affinity setting

<cmdline>-ffa_block 6144 -ffa_block_fetch 1536 -unroll 8 -instances_per_device 2 -hp -no_cpu_lock</cmdline>

---

Current System Info:
i7/950 64-bit, EVGA GTX460SE, EVGA GTS250, 6Gb ram, nVIDIA 266.58, BOINC 6.12.33, beta nVIDIA Astropulse r521, BOINC Recheduler 2.6
History:
BIONC 6.13.1, nVIDIA 270.61, beta nVIDIA Astropulse r521, BOINC Recheduler 2.6

Under the conditions listed under History, ran 4 AP tasks which ended in -202 errors, with numerous restarts. The AP tasks were rescheduled manually via the rescheduler.
http://setiathome.berkeley.edu/results.php?hostid=5501972&offset=0&show_names=0&state=5&appid=5

After more continued reading of this thread, I decided to revert both the nVIDIA driver and the BOINC application to that which is listed under Current System Info.

Questions:
1) The AP currently being d/l (1) or waiting to start (5) appear to be normal ap tasks that I was getting prior to testing, even though none have started at this point. Shouldn't there be an application description change to note that these tasks are for cuda processing as in the change from MB6.03 to 6.10(fermi)?

2) Do the AP tasks automatically run as cuda tasks or must they be rescheduled as such?

Did this old man's eyes have missed something that touched on either of these questions? If so, I apologize.

---

I don't buy computers, I build them!!

Sorry Cliff but you are right, all the AP work you show are for the CPU. Any that you get for the GPU will be marked as astropulse_v505 5.05 (cuda) in your BM. Also, on your tasks page it will show up as Astropulse v505
Anonymous platform (NVIDIA GPU)

---

PROUD MEMBER OF Team Starfire World BOINC

Correction.

If the units are resheduled they still show as CPU work.
You only see in stderr.txt when finnished by GPU.
Look at my host, i have hundreds of MB work marked as ATI finnished by CPU.

---

With each crime and every kindness we birth our future.

Raistmer..............

On both of my boxes containing GTX 580 I found very high CPU use while running the AP Open CL app. Using version NVIDIA drivers 280.19 and version 275.33. Installed driver version 266.58 and CPU useage went to normal. I was also seeing driver reset after Boinc stopped. Reduced unroll to 8 and solved this problem. Currently using this cmdline and count.

<cmdline>-ffa_block 6144 -ffa_block_fetch 1536 -unroll 8 -instances_per_device 4</cmdline>
<count>0.25</count>

---

Boinc....Boinc....Boinc....Boinc....

I was also seeing driver reset after Boinc stopped. Reduced unroll to 8 and solved this problem. Currently using this cmdline and count.

<cmdline>-ffa_block 6144 -ffa_block_fetch 1536 -unroll 8 -instances_per_device 4</cmdline>
<count>0.25</count>

Thanks, it's a new info. It means driver reset at BOINC stop not nessasary connected with any BOINC API flaws.

I was also seeing driver reset after Boinc stopped. Reduced unroll to 8 and solved this problem. Currently using this cmdline and count.

<cmdline>-ffa_block 6144 -ffa_block_fetch 1536 -unroll 8 -instances_per_device 4</cmdline>
<count>0.25</count>

Thanks, it's a new info. It means driver reset at BOINC stop not nessasary connected with any BOINC API flaws.

Well, there are a lot of reasons for driver resets - including overheating, undervolting, bad VRAM - and probably more, even before we get on to driver bugs and application quirks.

But we do need to get rid of all the known application issues, so we can clearly see whatever else is lying underneath, and move on to dealing with that.

I was also seeing driver reset after Boinc stopped. Reduced unroll to 8 and solved this problem. Currently using this cmdline and count.

<cmdline>-ffa_block 6144 -ffa_block_fetch 1536 -unroll 8 -instances_per_device 4</cmdline>
<count>0.25</count>

Thanks, it's a new info. It means driver reset at BOINC stop not nessasary connected with any BOINC API flaws.

My unscientific observation "felt like" it was due to the AP Open CL app since it only happened when that app had been running.

---

Boinc....Boinc....Boinc....Boinc....

This is new:

8/8/2011 12:32:02 PM | SETI@home | Task ap_22ap11ac_B5_P1_00172_20110804_31703.wu_1 exited with zero status but no 'finished' file
8/8/2011 12:32:02 PM | SETI@home | If this happens repeatedly you may need to reset the project.

---

Executive Director GPU Users Group Inc. -
brad@gpuug.org

That is no error message.

And furthermore, it's not application specific but has to do with the heartbeat checks between every application and the BOINC client.

Gruß,
Gundolf
[edit]And never reset the project because of that recommandation. It's absolute nonsense![/edit]

could finish two more results.
http://setiathome.berkeley.edu/result.php?resultid=2029837505
runtime 4,042.37
CPU time 558.98
single pulses: 4
repetitive pulses: 0
percent blanked: 0.00
waiting for validation to Astropulse v505 v5.05 finished 22 Jun 2011 | 13:01:24 UTC
Will hopefully validate when ap_validate will run again.

edit: sorry this result runs on CPU not GPU
http://setiathome.berkeley.edu/result.php?resultid=2031637483
runtime 12.46
CPU time 10.44
In ap_remove_radar.cpp: get_indices_to_randomize: num_ffts_forecast < 100. Blanking too much RFI?
waiting for validation to Astropulse v505 v5.05 finished 8 Aug 2011 | 11:22:27 UTC
Will hopefully validate when ap_validate will run again.

---

Matthias

half the work units were invalid, running ap made my desktop laggy, when after endless tweaking of the app info.

I did fast look through your results and found 8k and 16k values for FFA block params. Did you try lower values too? Could you list FFA params values you tried already?

Also, could you remember non-overflowed results (not 30 pulses in both categories) that give invalid/inconclusive? Or all of them were overflows ?

i did try some lower ffa values, but it didnt seem to matter, the desktop was always laggy when running astropulse 521. i don't remember the exact params i tried but i did go pretty low to try and iron things out.

most of my errors were from the -30 overflows.

since i stopped running astropulse i have been able to add 400mhz to my cida cards memory speed and not get errors. and 15mhz to the core. it seems to me that running astropulse really taxes the heck out of a cuda card. you cant have the slightest instability or it will error out. with multibeam you can overclock to the point where you are unstable and still get 98% of the work units validated.

by the way i did try running the card at default values for core shader and memory speed, just to see if that would help but i still got errors. it just didnt work for me.

half the work units were invalid, running ap made my desktop laggy, when after endless tweaking of the app info.

I did fast look through your results and found 8k and 16k values for FFA block params. Did you try lower values too? Could you list FFA params values you tried already?

Also, could you remember non-overflowed results (not 30 pulses in both categories) that give invalid/inconclusive? Or all of them were overflows ?

i did try some lower ffa values, but it didnt seem to matter, the desktop was always laggy when running astropulse 521. i don't remember the exact params i tried but i did go pretty low to try and iron things out.

most of my errors were from the -30 overflows.

since i stopped running astropulse i have been able to add 400mhz to my cida cards memory speed and not get errors. and 15mhz to the core. it seems to me that running astropulse really taxes the heck out of a cuda card. you cant have the slightest instability or it will error out. with multibeam you can overclock to the point where you are unstable and still get 98% of the work units validated.

by the way i did try running the card at default values for core shader and memory speed, just to see if that would help but i still got errors. it just didnt work for me.

You're running the ap_5.06_win_x86_SSE3_OpenCL_NV_r521.exe app on a AMD Athlon 64 Processor 3200+, correct me if i'm wrong, But I'm sure it only has SSE2, not the SSE3 the app requires, which might be why almost every task is inconclusive.

Claggy

according to cpu-z my cpu has mmx, 3dnow!, see 1 2 and 3, and is x86-64 capable.

You have to wait til validators are running again to see if your units get validated.
I had 35 in a row last week all validated except 1.

For screen lag you should try lower unroll factor.
Your GPU only has 4 compute units so i would try unroll 4 or 3 to see if it gets better.

What i could see on your results you only changed FFA values.

Even with high params 16384 you have 2 results with 0/0 signals found.

---

With each crime and every kindness we birth our future.