I found the problem. There are apparently two different methods for computing speed... One is based on the predicted speed of the GPU, and it is what is used to determine which version is faster. When the random factor is added into that you're most likely to get the version that has computed the fewest results so far.

This is contrary to the behaviour David has said the scheduler should have and so I will fix it.

Mind you, the cuda42 we got first was the version which 63280 has completed most of.

The random factor can go both ways, but the deviations from the average are larger for apps than have done fewer results.

---

Enabled work fetch for v7. It's remote host though.. will try to speedup work fetch there a little...

EDIT: that host out of game for today... there was some power loss so all hosts rebooted. And GPU in lowered freq after reboot (local logon required to enable fan and full speed). So estimation times rised to 1-2 hours instead of ~10-20 mins...
it will ask new work not very soon

Look for this host instead: http://setiweb.ssl.berkeley.edu/beta/show_host_detail.php?hostid=39394
there are MB and MB HD5, MB has bigger APR. Difference not so great as with cuda22 & other, but both app version have >200 eligible results already.
It just got new 20 tasks few mins ago. Could you post log for that fetch ?

EDIT: and there were SETI@home v7 v7.03 (opencl_ati5_sah), slower ones %)

SETI@home v7 7.03 windows_intelx86 (opencl_ati_sah)
Number of tasks completed 306
Max tasks per day 342
Number of tasks today 74
Consecutive valid tasks 309
Average processing rate 90.332877853703
Среднее оборотное время 1.48 days
SETI@home v7 7.03 windows_intelx86 (opencl_ati5_sah)
Number of tasks completed 275
Max tasks per day 309
Number of tasks today 113
Consecutive valid tasks 276
Average processing rate 82.306080532354
Среднее оборотное время 1.18 days

Was it random or bug ? ;)

When the random factor is added into that you're most likely to get the version that has computed the fewest results so far.

And the slowest app most probably will have fewer results ... un-optimization :)

OK, I think I've fixed it. I want to confirm before I check the changes in. Let me know if you see more funny business.

---

Look for this host instead: http://setiweb.ssl.berkeley.edu/beta/show_host_detail.php?hostid=39394
there are MB and MB HD5, MB has bigger APR. Difference not so great as with cuda22 & other, but both app version have >200 eligible results already.
It just got new 20 tasks few mins ago. Could you post log for that fetch ?

EDIT: and there were SETI@home v7 v7.03 (opencl_ati5_sah), slower ones %)

SETI@home v7 7.03 windows_intelx86 (opencl_ati_sah)
Number of tasks completed 306
Max tasks per day 342
Number of tasks today 74
Consecutive valid tasks 309
Average processing rate 90.332877853703
Среднее оборотное время 1.48 days
SETI@home v7 7.03 windows_intelx86 (opencl_ati5_sah)
Number of tasks completed 275
Max tasks per day 309
Number of tasks today 113
Consecutive valid tasks 276
Average processing rate 82.306080532354
Среднее оборотное время 1.18 days

Was it random or bug ? ;)

Guess you have switched apps in your post :
opencl_ati_sah == HD5
opencl_ati5_sah == non-hd5

---

_\|/_
U r s

why the hell such names was chosen?!!! There are enough tru issues to not to add such name substitudes >:[
(EDIT: yeah, "5" in stock name means non-HD5 app. "Funny" :/ )

OK, I think I've fixed it. I want to confirm before I check the changes in. Let me know if you see more funny business.

With posted log it would be more obvious why host got 20 slower app tasks (maybe I messed HD5 with non-HD5 one, but host recived task for slower app indeed).

Did one more work fetch request - now got 20 tasks for fastest app.
Will see if it's consistent behavior or just random luck....

EDIT: btw, for this testing it would be worth to reduce number of simultaneously allocated tasks from 20 let say to 5 or maybe less. Not ?
It's not main, we do tasks here only for testing and fetch 20 similar tasks for current testing is just resources waste.

2 more separate fetches - 3 and 2 tasks recived, all for fastest app.
Looks good so far.

Started another NV GPU host (GSO9600).
Not too good beginning - 60 tasks already recived. All cuda22 ones. And this host supports cuda23 and cuda32 too and cuda23 expected to be fastest. But queue filled with slowest tasks.
http://setiweb.ssl.berkeley.edu/beta/show_host_detail.php?hostid=63368

Meanwhile, on the other guinea-pig host, the first three fetches after Eric's 22:29 fix all resulted in cuda50 work - which is what would be desired, given the host's established APR records.

And another fetch on ATi host: 13 tasks, all for fastest app.
So, with already established APR all Ok now. task distribution for newly added host could be better though.

Yes, I wish it didn't pick a single app to distribute to on each RPC, but recalculated best app for each result. I dont see an easy way to fix that.

---

SETI@home v7 7.00 windows_intelx86 (cuda22)
Number of tasks completed 85
Max tasks per day 119
Number of tasks today 0
Consecutive valid tasks 86
Average processing rate 57.869216272821
Среднее оборотное время 1.28 days
SETI@home v7 7.00 windows_intelx86 (cuda23)
Number of tasks completed 89
Max tasks per day 122
Number of tasks today 0
Consecutive valid tasks 89
Average processing rate 121.86273824761
Среднее оборотное время 1.53 days
SETI@home v7 7.00 windows_intelx86 (cuda32)
Number of tasks completed 214
Max tasks per day 248
Number of tasks today 0
Consecutive valid tasks 215
Average processing rate 124.01397894416
Среднее оборотное время 1.88 days

Because of GPU downclock APR for cuda23 now biased. APR for cuda32 became bigger than for cuda23 though cuda23 is the fastest for this host.
Interesting, will BOINC be able to correct APR when I will do local logon and restore normal GPU speed or host will recive only suboptimal tasks now?...

EDIT: and here we will be able to check how good random factor is. In particular, if SD of 1 is really enough. Host worked with full speed GPU many days already. It will work with downclocked GPU 1-2 days. If random factor does its work such deviation should be healed on subsequent work fetches.
If random factor too low host will stick in suboptimal state.
Interesting experiment ;)

The rates are so close together that you should have a good chance of getting some cuda23. Otherwise you'd have to wait for the processing rate to get back down to normal on cuda32.

---

The rates are so close together that you should have a good chance of getting some cuda23. Otherwise you'd have to wait for the processing rate to get back down to normal on cuda32.

it's normal on cuda32. And if I return GPU to full speed before some downloaded cuda32 tasks will be processed, it will remain normal. While cuda23 APR was reduced.
Will see in what it results.

And another fetch request on GSO9600 - again cuda22...
Quite strange random, 3 in row with 3 possible variants.

Eric, could you check this host please http://setiweb.ssl.berkeley.edu/beta/show_host_detail.php?hostid=63368 - does server consider other plan classes besides cuda22 at all ?

Sorry for not warning you. I needed to reset stats and cancel previous results. Your versions should be random again until you get back to 10 results per.

Checking on your hosts now.

---