now that hosts recived all tasks from cuda22 up to cuda32 (driver-limited).

I'm not sure why host with such GPU:

Сопроцессоры AMD ATI Radeon HD 4600 series (R730) (1024MB) driver: 1.4.1734 OpenCL: 1.00

Recives HD5 app.

Maybe it will even work but slow... but were ATi GPUs limited with HD5xxx and up or were not?

EDIT:
Eric, please check work allocation for this host: http://setiweb.ssl.berkeley.edu/beta/show_host_detail.php?hostid=63334
why it gets ATi MB 7.03 (that user just aborts) ?

The HD5 version goes to anything of CAL target 7 and above. The non-HD5 version goes to anything of CAL target 5 and above.

And to make matters more confusing, the opencl_ati5_sah is the non-HD5 version. (The 5 in the class name is the CAL target).

On the Astropulse side, cal_ati goes to anything with a CAL target of 4 or above. opencl_ati_100 doesn't check the CAL target. It assumes that anything with OpenCL 1.0 or greater will work. ati_opencl_100 check for a CAL target of 5 or higher.

These are easy to change, so if you think cal_ati could go to a lower target let me know. If you really think that the HD5 should be restricted to 9 or higher, I can do that as well.

As a reminder, the first 9 CAL targets are

1 = ATI Radeon HD 2900 (RV600)
2 = ATI Radeon HD 2300/2400/3200/4200 (RV610)
3 = ATI Radeon HD 2600/3650 (RV630/RV635)
4 = ATI Radeon HD 3800 (RV670)
5 = ATI Radeon HD 4350/4550 (R710)
6 = ATI Radeon HD 4600 series (R730)
7 = ATI Radeon (RV700 class)
8 = ATI Radeon HD 4700/4800 (RV740/RV770)
9 = ATI Radeon HD 5800 series (Cypress)

---

Eric, sending MB on "cal5" targets not right (even on "cal6" ones not right!).
It's known that Ati MB has problems with low HD4xxx cards. Also it's known that ATi ceased HD4xxx support(even high end ones) completely.
Earlier you complained about additional headaches ATi drivers bring. So, why to add difficulties now and try to support definitely unsupported GPUs ???
We will have "enough fun" with "officially supported" ones, I'm sure...

On the Astropulse side, cal_ati goes to anything with a CAL target of 4 or above. opencl_ati_100 doesn't check the CAL target. It assumes that anything with OpenCL 1.0 or greater will work. ati_opencl_100 check for a CAL target of 5 or higher.

These are easy to change, so if you think cal_ati could go to a lower target let me know.

Yes, Brook AP should work even on HD2600 GPUs. Worth to check this being on beta (lets try CAL1 and see how it will behave) If you wanna test the limits set CAL6 for non-HD5. Current CAL5 will fail on most hosts with CAL5 hardware.

opencl_ati_100 doesn't check the CAL target. It assumes that anything with OpenCL 1.0 or greater will work.

Should work OK for AP, beta will show...

If you really think that the HD5 should be restricted to 9 or higher, I can do that as well.

It's the same thing as with Brook+ AP and OpenCL capable GPUs. They will run brook (mostly) but it's just waste of time.
pre-HD5 GPUs have no local memory (LDS not mapped to OpenCL API), it's emulated via global ones so all kernels that try to make use of local memory for speedup actually will get slowdown.
If you want to check it on beta - ok, lets try, but for main I would recommend to set hard constraint on Brook+ AP (not to send to OpenCL capable GPUs) and hard constraint on HD5 MB (not send on pre-HD5 GPUs).

...
As a reminder, the first 9 CAL targets are

1 = ATI Radeon HD 2900 (RV600)
2 = ATI Radeon HD 2300/2400/3200/4200 (RV610)
3 = ATI Radeon HD 2600/3650 (RV630/RV635)
4 = ATI Radeon HD 3800 (RV670)
5 = ATI Radeon HD 4350/4550 (R710)
6 = ATI Radeon HD 4600 series (R730)
7 = ATI Radeon (RV700 class)
8 = ATI Radeon HD 4700/4800 (RV740/RV770)
9 = ATI Radeon HD 5800 series (Cypress)

I would do it this way :
AP Brook+ app goes to targets 1,2,3,4
AP OpenCL app goes to targets 5,6,(7,)8,9

MB app goes to targets 8 and 9
MB HD5 app goes to target 9 and above

---

_\|/_
U r s

The only WU's at the moment that will not run on my Radeon HD 4600 is the MB v7.03.

Why keep restricting what can and cannot be allowed are these restrictions going to apply to main,or is it to satisfy the credit hungry. As far as I can remember its only this latest/last series of MB_sah WU's that are giving problems,I've run them before why not now???

Michael

Agree with replacement target 9 with target 9 and upper :)

The only WU's at the moment that will not run on my Radeon HD 4600 is the MB v7.03.

Why keep restricting what can and cannot be allowed are these restrictions going to apply to main,or is it to satisfy the credit hungry. As far as I can remember its only this latest/last series of MB_sah WU's that are giving problems,I've run them before why not now???

Michael

Cause you said by yourself that MB 7.03 fails on your GPU. Why to send failing work to hosts? It's not credit-related at all. It's just resurces usage optimization project-wise.

I've done as recommended, ati_cal to 1+, opencl_ati5_sah to 6+, opencl_ati_sah to 9+. Left opencl astropulse as is.

---

I've done as recommended, ati_cal to 1+, opencl_ati5_sah to 6+, opencl_ati_sah to 9+. Left opencl astropulse as is.

Fine! Will see if GPUs can handle all that they get now.

I've done as recommended, ati_cal to 1+, opencl_ati5_sah to 6+, opencl_ati_sah to 9+. Left opencl astropulse as is.

Fine! Will see if GPUs can handle all that they get now.

You can also (I think) add the opencl_ati5_sah to the list for Radeon HD4600 runs to end of est time and beyond, no driver restarts or progess.

23% or 1 CPU no visible GPU load. Have not aborted WU's yet.

Michael

I've done as recommended, ati_cal to 1+, opencl_ati5_sah to 6+, opencl_ati_sah to 9+. Left opencl astropulse as is.

Fine! Will see if GPUs can handle all that they get now.

You can also (I think) add the opencl_ati5_sah to the list for Radeon HD4600 runs to end of est time and beyond, no driver restarts or progess.

23% or 1 CPU no visible GPU load. Have not aborted WU's yet.

Michael

What you describe seems not like it really successfully runs.
If valid result will be in the and then I would reconsider target assignment, but not earlier.

Today all my hosts in "quote reached" state so no meaningful results can recived, server just sends those task that still not hit the quota.
Day or 2 more and some picture will be formed. Most MB apps are in "beyond 10" state already for almost all my hosts.

BTW, current "tape" not very good for AP work distribution testing. Too many completed tasks are not eligible ones. So reaching 10 eligible will be long process...

Not quite about scheduler but about server still:

16/05/2013 18:28:03 SETI@home Beta Test update requested by user
16/05/2013 18:28:06 SETI@home Beta Test [sched_op_debug] Starting scheduler request
16/05/2013 18:28:06 SETI@home Beta Test Sending scheduler request: Requested by user.
16/05/2013 18:28:06 SETI@home Beta Test Reporting 1 completed tasks, requesting new tasks for GPU
16/05/2013 18:28:06 SETI@home Beta Test [sched_op_debug] CPU work request: 0.00 seconds; 0.00 CPUs
16/05/2013 18:28:06 SETI@home Beta Test [sched_op_debug] NVIDIA GPU work request: 783079.71 seconds; 0.00 GPUs
16/05/2013 18:28:08 SETI@home Beta Test Scheduler request completed: got 0 new tasks
16/05/2013 18:28:08 SETI@home Beta Test [sched_op_debug] Server version 701
16/05/2013 18:28:08 SETI@home Beta Test Message from server: NVIDIA GPU: Upgrade to the latest driver to use all of this project's GPU applications
16/05/2013 18:28:08 SETI@home Beta Test Project requested delay of 7 seconds
16/05/2013 18:28:08 SETI@home Beta Test [sched_op_debug] handle_scheduler_reply(): got ack for result 01mr13ab.32491.17249.16.16.111_0
16/05/2013 18:28:08 SETI@home Beta Test [sched_op_debug] Deferring communication for 7 sec
16/05/2013 18:28:08 SETI@home Beta Test [sched_op_debug] Reason: requested by project

No reason given why 0 tasks allocated. It's not too nice to user - to give nothing and did not explain why.
Looking on host page I could conclude it's because all app versions now reached todays quota... but not all "so experienced" in right places looking. Much better would be to add another line to server reply with words like "quota reached" or something alike.
Rule of thumb - no requests should be declined w/o reason explanation.
Could this be fixed ?

Correct behavior on my ATi host:

SETI@home v7 7.03 windows_intelx86 (opencl_ati_sah)
Number of tasks completed 56
Max tasks per day 70
Number of tasks today 75
Consecutive valid tasks 37
Average processing rate 101.13771401391
Среднее оборотное время 1.16 days
SETI@home v7 7.03 windows_intelx86 (opencl_ati5_sah)
Number of tasks completed 50
Max tasks per day 77
Number of tasks today 20
Consecutive valid tasks 44
Average processing rate 94.746974396929
Среднее оборотное время 0.64 days

opencl_ati_sah work was allocated up to quota then (and only then) opencl_ati5_sah was allocated.

Looks working! Now will see how other hosts behave.

No reason given why 0 tasks allocated. It's not too nice to user - to give nothing and did not explain why.

Which host was this. I'd like to see if I can figure out why, and maybe add an explanation.

---

No reason given why 0 tasks allocated. It's not too nice to user - to give nothing and did not explain why.

Which host was this. I'd like to see if I can figure out why, and maybe add an explanation.

It was: http://setiweb.ssl.berkeley.edu/beta/show_host_detail.php?hostid=18439 and I bet because of full quota. As soon as quota was increased due to new validations host recived new work for corresponding app.