Jason is working on it.

Was just one more example ... hope that helps to identify the problem.

---

_\|/_
U r s

I have a NVIDIA 250 and using driver 296.10 and boinc manager tells me to use the latest driver...
I have successfully run about all versions and CUDA32 and CUDA23 seems almost equally fast. cuda22 and cuda42 works as well.

Link:

http://setiweb.ssl.berkeley.edu/beta/results.php?hostid=60461

Eric, take a look on this WU: http://setiathome.berkeley.edu/workunit.php?wuid=1088184553. It's from main but quite interesting.
Can we have its task for offline testing?

This is boring :-), I have no issues to report. It works like a charm on both of my Nvidia computers. When are we going to see OpenCL for V7, so my ATI HD4850 can do some V7 work?

We are working on it.

---

With each crime and every kindness we birth our future.

We are working on it.

I sure hope so, because this is as boring as driving 1000Km through the desert, on a totally straight road. :-)

Question:

Why does the system continue to send out the slowest apps too (Cuda22, and Cuda32), when the computer reached more than 10 tasks completed for all apps, and it is painfully clear which app is the fastest on that computer (Cuda23)?

hostid=57176

Could someone please whack the logic circuit in the head a couple of times.

We are working on it.

I sure hope so, because this is as boring as driving 1000Km through the desert, on a totally straight road. :-)

I am crunching 10 SETI and then 1 SETI Beta since there is no hurry.

We are working on it.

I sure hope so, because this is as boring as driving 1000Km through the desert, on a totally straight road. :-)

I am crunching 10 SETI and then 1 SETI Beta since there is no hurry.

I'm crunching 10 Beta and 1 main, for the same reason. There is no hurry to crunch anything on main, because they already have millions of crunched but still not analyzed tasks to analyze.

The WU's crunched on main, will only end up in an Olympic size swimming pool of crunched but not analyzed tasks anyhow, and due to lack of man power, they (and any trace of ET) will stay there for years, or possibly forever.

The WU's crunched on main, will only end up in an Olympic size swimming pool of crunched but not analyzed tasks anyhow, and due to lack of man power, they (and any trace of ET) will stay there for years, or possibly forever.

LoL, quite discouraging attitude.... though realistic one :)

The WU's crunched on main, will only end up in an Olympic size swimming pool of crunched but not analyzed tasks anyhow, and due to lack of man power, they (and any trace of ET) will stay there for years, or possibly forever.

LoL, quite discouraging attitude.... though realistic one :)

Well yeah, I do have a bad attitude:-)

Sometimes, I do wonder if the SETI project should be divided into two parts. One part should be about doing what we are doing now, and the new part should only be dealing with analyzing already crunched data. Either that, or stop producing millions of WU's (that only end up in a longterm storage), for a year or so, and start analyzing what we already have.

It's obvious that they can't do both things, and there's a real risk/chance that ET may already have been found, but we may never be able to analyze the data where ET reveals her/himself.

The WU's crunched on main, will only end up in an Olympic size swimming pool of crunched but not analyzed tasks anyhow, and due to lack of man power, they (and any trace of ET) will stay there for years, or possibly forever.

LoL, quite discouraging attitude.... though realistic one :)

Well yeah, I do have a bad attitude:-)

Sometimes, I do wonder if the SETI project should be divided into two parts. One part should be about doing what we are doing now, and the new part should only be dealing with analyzing already crunched data. Either that, or stop producing millions of WU's (that only end up in a longterm storage), for a year or so, and start analyzing what we already have.

It's obvious that they can't do both things, and there's a real risk/chance that ET may already have been found, but we may never be able to analyze the data where ET reveals her/himself.

Lets hope we can analyze the task that will prove there's a signal out there.
Until we find it, we are alone.
My guess is that there are still a bit of space to point the telescopes.
So there's still hope we will find ET one day.

The WU's crunched on main, will only end up in an Olympic size swimming pool of crunched but not analyzed tasks anyhow, and due to lack of man power, they (and any trace of ET) will stay there for years, or possibly forever.

LoL, quite discouraging attitude.... though realistic one :)

Well yeah, I do have a bad attitude:-)

Sometimes, I do wonder if the SETI project should be divided into two parts. One part should be about doing what we are doing now, and the new part should only be dealing with analyzing already crunched data. Either that, or stop producing millions of WU's (that only end up in a longterm storage), for a year or so, and start analyzing what we already have.

It's obvious that they can't do both things, and there's a real risk/chance that ET may already have been found, but we may never be able to analyze the data where ET reveals her/himself.

Lets hope we can analyze the task that will prove there's a signal out there.
Until we find it, we are alone.
My guess is that there are still a bit of space to point the telescopes.
So there's still hope we will find ET one day.

Crunching the tasks as we do on main, is just part one of it. We have millions of already crunched tasks. Part two is to analyze the crunched tasks, and that's where we are light years behind.

It's not a question of lack of tasks to crunch, or places to point the telescope, it's a question of analyzing the millions of already crunched tasks. That is where the problem lies, not any lack of data to crunch.

I can bet that we already have proof of ET's existence, in the already crunched tasks, but unless there's resources freed to run them through an analyzer, we will never ever know.

But I digress, that's really not an issue for this thread. I'll leave it at that.

Question:

Why does the system continue to send out the slowest apps too (Cuda22, and Cuda32), when the computer reached more than 10 tasks completed for all apps, and it is painfully clear which app is the fastest on that computer (Cuda23)?

hostid=57176

Could someone please whack the logic circuit in the head a couple of times.

Regarding this + my own observations:

Let's take a look on 2 my hosts.
1)
SETI@home v7 6.98 windows_intelx86 (cuda23)
Number of tasks completed 28
Max tasks per day 61
Number of tasks today 0
Consecutive valid tasks 28
Average processing rate 153.38553702887
Среднее оборотное время 1.34 days
SETI@home v7 6.98 windows_intelx86 (cuda32)
Number of tasks completed 11
Max tasks per day 45
Number of tasks today 0
Consecutive valid tasks 12
Average processing rate 151.28463934555
Среднее оборотное время 1.44 days
SETI@home v7 6.98 windows_intelx86 (cuda22)
Number of tasks completed 41
Max tasks per day 79
Number of tasks today 0
Consecutive valid tasks 46
Average processing rate 67.216748852632
Среднее оборотное время 3.04 days

As one can see slowest app leads in number of completed tasks, still.

2)
SETI@home v7 6.98 windows_intelx86 (cuda23)
Number of tasks completed 11
Max tasks per day 44
Number of tasks today 3
Consecutive valid tasks 11
Average processing rate 14.061488931941
Среднее оборотное время 3.36 days
SETI@home v7 6.98 windows_intelx86 (cuda32)
Number of tasks completed 14
Max tasks per day 48
Number of tasks today 0
Consecutive valid tasks 15
Average processing rate 14.112470213582
Среднее оборотное время 1.87 days
SETI@home v7 6.98 windows_intelx86 (cuda42)
Number of tasks completed 9
Max tasks per day 43
Number of tasks today 0
Consecutive valid tasks 10
Average processing rate 11.350113377109
Среднее оборотное время 3.41 days
SETI@home v7 6.98 windows_intelx86 (cuda22)
Number of tasks completed 8
Max tasks per day 41
Number of tasks today 0
Consecutive valid tasks 8
Average processing rate 6.2087680445968
Среднее оборотное время 4.05 days

As one can see (though less statistics) situation is OK here.

What cardinal difference between these hosts:
second one can accept all app's flavors while first one can't accept cuda42.

What I think: when BOINC decides what to send and tries to send cuda42 to firat host it sees it's impossible, issues dumb message about driver upgrade... and doing even more dumb thing - sends tasks for cuda22 instead. Maybe because they have bigger queue, maybe because this app first in some inner list - don't know.

But this would explain why my (and Sten's host too btw, he refused to do driver upgrade too) ends up with worse app.

Eric, can you check this "theory" ?

Question:

Why does the system continue to send out the slowest apps too (Cuda22, and Cuda32), when the computer reached more than 10 tasks completed for all apps, and it is painfully clear which app is the fastest on that computer (Cuda23)?

hostid=57176

Could someone please whack the logic circuit in the head a couple of times.

[snip to keep the size down]

What cardinal difference between these hosts:
second one can accept all app's flavors while first one can't accept cuda42.

What I think: when BOINC decides what to send and tries to send cuda42 to firat host it sees it's impossible, issues dumb message about driver upgrade... and doing even more dumb thing - sends tasks for cuda22 instead. Maybe because they have bigger queue, maybe because this app first in some inner list - don't know.

But this would explain why my (and Sten's host too btw, he refused to do driver upgrade too) ends up with worse app.

Eric, can you check this "theory" ?

Interesting theory Raistmer. I do get Cuda23 (the fastest on my system) tasks too of course, but maybe the answer to why I still get the slower apps at all, lies in your theory perhaps.

Could someone please whack the logic circuit in the head a couple of times.

I would like to at times. Somewhere in the arcana of the server is a decision to use the average elapsed time for results from a host rather than the FLOP/s estimate when deciding which app version to send. When reading the server logs it appears that although CUDA22 is the fastest version in terms of FLOP/s, CUDA32 has returned its results fastest (probably because it had shorter results than CUDA 22)

I've never followed the logic through to find out why the server makes this decision. If I get some time in the next couple days, I will.

---

Could someone please whack the logic circuit in the head a couple of times.

I would like to at times. Somewhere in the arcana of the server is a decision to use the average elapsed time for results from a host rather than the FLOP/s estimate when deciding which app version to send. When reading the server logs it appears that although CUDA22 is the fastest version in terms of FLOP/s, CUDA32 has returned its results fastest (probably because it had shorter results than CUDA 22)

I've never followed the logic through to find out why the server makes this decision. If I get some time in the next couple days, I will.

That did not really end up in a part of my Swedish brain that understood exactly what you meant, because in factual speed, comparing same or similar AR's, Cuda22 is the slowest, followed by Cuda32, and the clear winner is Cuda23. If the server logic says something else, it is simply wrong.

Why isn't the decison logic simply based on the APR from each apps after 10 completed tasks and make the decision from that?

NVIDIA GeForce 315M (474MB) driver: 267.54:
--------------------------------------------
SETI@home v7 6.98 windows_intelx86 (cuda22)

Average processing rate: 8.1967443005726
--------------------------------------------
SETI@home v7 6.98 windows_intelx86 (cuda23)

Average processing rate: 11.169030492552
---------------------------------------------
SETI@home v7 6.98 windows_intelx86 (cuda32)

Average processing rate 10.650823216767
---------------------------------------------

It should be pretty simple for the server to see that the APR for Cuda23 is the winner, and stop sending both cuda22 and cuda32. But then, what do I know, I'm using simple logic, and I guess the server is using some other kind of logic :-)

Ah well, it doesn't hurt me much whatever app I run, it just makes the word "logic" hurt my brain a bit when I happen to think about it :-)

Sorry, my mistake. I just typed CUDA22 when I meant CUDA23.

---

Sorry, my mistake. I just typed CUDA22 when I meant CUDA23.

Thanks, now your post made full sense. I have seen the light :-)

But still using the APR fully to decide what app to send, seems to me to be the best and simplest way, and then I would end up with only Cuda23 tasks.

I went through the server logic and apparently the server always uses elapsed time to determine which app is fastest unless that information is not available, in which case it uses app version performance averaged across all hosts!

If anyone else want to go to the BOINC developers list to ask why elapsed time rather than host performance is used in estimate_flops() in sched_version.cpp, feel free. I'm not feeling up to fighting that battle right now.

---