And some anoher question:

SETI@home v7 7.03 windows_intelx86 (opencl_ati_sah)
Number of tasks completed 160
Max tasks per day 112
Number of tasks today 0
Consecutive valid tasks 79
Average processing rate 100.85736935031
Среднее оборотное время 1.67 days
AstroPulse v6 6.06 windows_intelx86 (ati_opencl_100)
Number of tasks completed 2
Max tasks per day 39
Number of tasks today 0
Consecutive valid tasks 6
Average processing rate 742.57870281709
Среднее оборотное время 2.74 days

Will scheduler take into account relative APR difference between different kinds of apps and schedule AP preferable over MB for ATi card if both are available and permitted as in this case ?
It would be good if yes. Then we would have good example of positive load balancing where each device recives that type of work it can do better.

I'll code that up tomorrow!

<edit>Anyone want to try the same test on recent NVIDIA cards?</edit>

Well, since I'm on Boinc 6, I will probably not benefit from that anyhow, since I don't get any V7 MB tasks at all, since the release of 7.03. However for others on Boinc 7, and with relatively modern ATI cards, it would likely be a great improvemement.

---

WARNING!! "THIS IS A SIGNATURE", of the "IT MAY CHANGE AT ANY MOMENT" type. It may, or may not be considered insulting, all depending upon HOW SENSITIVE THE VIEWER IS, to certain inputs to/from the nervous system.

One host has found its correct app versions meanwhile. Now will allow AstroPulse, too.

Application details for host 51991

SETI@home v7 7.01 i686-pc-linux-gnu
Number of tasks completed 20
Max tasks per day 43
Number of tasks today 0
Consecutive valid tasks 10
Average processing rate 22.081600249449
mittlere Taskdauer 7.76 days
SETI@home v7 7.01 x86_64-pc-linux-gnu
Number of tasks completed 305
Max tasks per day 338
Number of tasks today 18
Consecutive valid tasks 305
Average processing rate 24.283285421523
mittlere Taskdauer 0.87 days
SETI@home v7 7.04 x86_64-pc-linux-gnu (opencl_ati_cat132)
Number of tasks completed 364
Max tasks per day 396
Number of tasks today 63
Consecutive valid tasks 363
Average processing rate 41.817861171885
mittlere Taskdauer 1.46 days
SETI@home v7 7.04 x86_64-pc-linux-gnu (opencl_ati5_cat132)
Number of tasks completed 243
Max tasks per day 238
Number of tasks today 0
Consecutive valid tasks 206
Average processing rate 37.114054745567
mittlere Taskdauer 2.76 days

---

_\|/_
U r s

Time to start the feeder perhaps, after the outage?

786	SETI@home Beta Test	2013-05-21 23:26	update requested by user	
787	SETI@home Beta Test	2013-05-21 23:26	Sending scheduler request: Requested by user.	
788	SETI@home Beta Test	2013-05-21 23:26	Reporting 12 completed tasks, requesting new tasks for GPU	
789	SETI@home Beta Test	2013-05-21 23:26	Scheduler request completed: got 0 new tasks	
790	SETI@home Beta Test	2013-05-21 23:26	Message from server: Server error: feeder not running	

---

WARNING!! "THIS IS A SIGNATURE", of the "IT MAY CHANGE AT ANY MOMENT" type. It may, or may not be considered insulting, all depending upon HOW SENSITIVE THE VIEWER IS, to certain inputs to/from the nervous system.

New scheduler is on that should give VLAR results to AMD GPUs with CAL_TARGET > 19. Let me know if anyone sees any problems.

Continue to point out machines that get the wrong work. I'm trying to figure out a change that will prevent machines that error out on a specific version from getting any work for that version. As it is now, their daily quota will go down to 1, but they'll still get one result per day for that version.

---

Will scheduler take into account relative APR difference between different kinds of apps and schedule AP preferable over MB for ATi card if both are available and permitted as in this case ?
It would be good if yes.

I agree, but unfortunately the scheduler was written to not be that smart. It just does a scan through the results in the shared memory, chooses the best application for that result, and checks whether there is more CPU/GPU time still available. If so it checks the next result.

It would be a major change to the structure to get it to choose the best overall app first, then look for results available for that app. And David probably wouldn't agree to that large of a change.

---

As I expected, I'm not gettin any V7 tasks for my host http://setiweb.ssl.berkeley.edu/beta/show_host_detail.php?hostid=57178 Because I'm running Boinc 6, I guess.

Well, off to main then with 100% of my HD7870.

---

WARNING!! "THIS IS A SIGNATURE", of the "IT MAY CHANGE AT ANY MOMENT" type. It may, or may not be considered insulting, all depending upon HOW SENSITIVE THE VIEWER IS, to certain inputs to/from the nervous system.

Yep, that is definitely the reason. I may ponder a little on whether some of the higher v6 clients can be brought into the action without threatening to crash too many machines. That's farther down the road then decided what to do about app versions that don't run.

---

Continue to point out machines that get the wrong work. I'm trying to figure out a change that will prevent machines that error out on a specific version from getting any work for that version. As it is now, their daily quota will go down to 1, but they'll still get one result per day for that version.

http://setiweb.ssl.berkeley.edu/beta/results.php?hostid=61050 did get Brook+ libs for AP app (see below). BOINC is at 6.10.58, Cat 11.12 is last with OpenCL for XPx64.

05/22/13 05:44:42		ATI GPU 0: ATI Radeon HD5x00 series (Redwood) (CAL version 1.4.1646, 1024MB, 620 GFLOPS peak)
...
05/22/13 05:46:49	SETI@home Beta Test	Finished download of brook_cal.dll
05/22/13 05:46:49	SETI@home Beta Test	Started download of brook.dll

---

_\|/_
U r s

As I expected, I'm not gettin any V7 tasks for my host http://setiweb.ssl.berkeley.edu/beta/show_host_detail.php?hostid=57178 Because I'm running Boinc 6, I guess.

Well, off to main then with 100% of my HD7870.

There now is BM 7.0.64 and it does not have the REC-based shedule anymore.
Sten, I'd say it may be worth testing.

You can always downgrade.

New scheduler is on that should give VLAR results to AMD GPUs with CAL_TARGET > 19. Let me know if anyone sees any problems.

Continue to point out machines that get the wrong work. I'm trying to figure out a change that will prevent machines that error out on a specific version from getting any work for that version. As it is now, their daily quota will go down to 1, but they'll still get one result per day for that version.

1) You could try to decrease CAL target gradually. Cause even my HD6950 dealed with VLARs just fine when they were available.

2)It's important to be sure that BOINC make decision based on constant (or quite regular ) failures, not on few single cases. Or it will be another "de-optimization".

Yes, I was thinking of "max tasks per day" of 1 and "consecutive valid tasks" of 0 as an indicator of failure. And in that case, I would give that app version 0.1 GFLOP 99% of the time and standard estimated flops the other 1% of the time.

---

There now is BM 7.0.64 and it does not have the REC-based shedule anymore.

Untrue.

Yep, that is definitely the reason. I may ponder a little on whether some of the higher v6 clients can be brought into the action without threatening to crash too many machines. That's farther down the road then decided what to do about app versions that don't run.

Ah well, nothing to do about that then. I'm done here it seems when it comes to GPU testing. Leaving 2 cores to run Beta MB7 on the CPU though.

I may upgrade to Boinc 7 one day, but unlikely not before "the cows comes home" though.

http://setiweb.ssl.berkeley.edu/beta/results.php?hostid=61050 did get Brook+ libs for AP app (see below). BOINC is at 6.10.58, Cat 11.12 is last with OpenCL for XPx64.

05/22/13 05:44:42		ATI GPU 0: ATI Radeon HD5x00 series (Redwood) (CAL version 1.4.1646, 1024MB, 620 GFLOPS peak)
...
05/22/13 05:46:49	SETI@home Beta Test	Finished download of brook_cal.dll
05/22/13 05:46:49	SETI@home Beta Test	Started download of brook.dll

Upon updating BOINC to 6.10.60, reset the project to start over from cleaned Beta directory. Maybe the older apps still in the project directory caused the unwanted library downloads.

---

_\|/_
U r s

A bunch of VLARs was holding things up again. I cleared them out.

---

A bunch of VLARs was holding things up again. I cleared them out.

Was that clearout meant to affect tasks already started?

Never mind, but it caused an interesting stderr for task 13975057. Was somebody talking about a race condition?

Any that had a result that hadn't been sent to a wingman got cancelled as well. Sorry about that. That is a weird stderr.

---

There now is BM 7.0.64 and it does not have the REC-based shedule anymore.

Untrue.

Ok.

Workfetch procedure is in my opinion alot better.

A bunch of VLARs was holding things up again. I cleared them out.

But how about to allow some of ATi GPUs to crunch them ?