An answer to the question of how the canonical result is selected is a different matter, and I couldn't find a definitive answer after poking around the Wiki for a while. Maybe one of the Devs will see this and shed some illumination on this.

I hope, then I can add that...

But, as far as I know, a "random" choice is made. If they all compare, it does not matter which one is selected.

In the case of a single value, this could be the "middle" result. But, since it is a complex blend of spikes, Gaussians, triplets, etc., "middle" kind of loses its meaning. In that case, a random choice is as valid a choice as any other.

---

This is a very complex topic... In addition to what has already been said here, I suggest reading the Wiki http://boinc-doc.net/boinc-wiki/ sections on credit, claimed credit, benchmarking, optimized apps... that'll get you started at any rate.

(snip)

Nice summary of the factord effecting the client side claimed credit issue and how "custom" optimized clients and apps relate to it.

An answer to the question of how the canonical result is selected is a different matter, and I couldn't find a definitive answer after poking around the Wiki for a while. Maybe one of the Devs will see this and shed some illumination on this.

Alinator

This is a very complex topic... In addition to what has already been said here, I suggest reading the Wiki http://boinc-doc.net/boinc-wiki/ sections on credit, claimed credit, benchmarking, optimized apps... that'll get you started at any rate.

I'll try to give a two-paragraph summary of what I've learned/heard/figured out/guessed; credit is based on "number of operations performed", not how long it took one particular machine to do those operations. Because this number generally can't be counted any other way, (time taken * benchmark score) is used to get the claimed credit. Because the benchmarks are very imperfect (and it is very very difficult to make them ANY better than they are) an "averaging" system on several computer's results is used to get the actual credit awarded. Optimized applications "break" this system; they do more work per unit time than the benchmark shows, thus they ask for less credit (and show estimated times much higher than they should be, messing up scheduling). The local fix for your computer is to run an optimized benchmark program - which is not available for all platforms, and would "break" the system in the opposite direction for projects without optimized applications, asking for too MUCH credit.

The short-term "global" fix is for BOINC Manager 4.72 and above to apply a "correction factor", so the estimated times and possibly the credit asked for is closer to the credit historically actually awarded for this machine on this project. (Seems to be working; after only 4-5 results, my double-speed/half-credit optimized client box is already showing a correction factor on SETI of 0.78.) The long-term fix is for each project's application to do it's own benchmarking; if you run an optimized SETI but an unoptimized SZTAKI, each will report the "right" benchmark values for that project on your computer. All of this is being worked on; in the meantime, the present system is "pretty good", and a lot more equitable than "one credit per workunit no matter what size". Remember, the credit system is secondary to getting the work done...

Thanks :-)

---

A quick and easy experiment you can run to help get a better perspective on these effects is to make a test run of a few results with your normal software suite running, then disable everything else, rebenchmark and run a few results again.

Most likely you will see a noticable difference in the claimed credit between the two runs, and this is on the exact same hardware.

Alinator

Thanks for the advice Alinator I'll give that a try

Phill

---

Save a tree, eat a Beaver.

Thanks James, Alinator and MJ, that clears it up I just thought that some people were getting a bit of a raw deal with claimed credit, actually I was more woried that someone was going to post that I should have looked harder to see how grading for claimed credit works or that I had missed it somewhere, thanks again for your replys :D

Phill.

A quick and easy experiment you can run to help get a better perspective on these effects is to make a test run of a few results with your normal software suite running, then disable everything else, rebenchmark and run a few results again.

Most likely you will see a noticable difference in the claimed credit between the two runs, and this is on the exact same hardware.

Alinator

One thing I don't understand is that my results usually claimed credit in the range between 25 and 32 pr WU - but when I started using an optimzed worker it only claims beween 6 and 7 credits pr. WU

The reason is simple. The claimed credits are based on your benchmarks * time (basically). So less time = less credit

---

One thing I don't understand is that my results usually claimed credit in the range between 25 and 32 pr WU - but when I started using an optimzed worker it only claims beween 6 and 7 credits pr. WU

It still does the work, only more efficient...

---

Actually, I have noticed on a P4 with hyper-threading, that boinc seems to benchmark it at 1/2 (1/2 for one WU, 1/2 for the other), when in reality 2 WU's finish far quicker at once then if you were to run them one at a time

---

Thanks James, Alinator and MJ, that clears it up I just thought that some people were getting a bit of a raw deal with claimed credit, actually I was more woried that someone was going to post that I should have looked harder to see how grading for claimed credit works or that I had missed it somewhere, thanks again for your replys :D

Phill.

---

Save a tree, eat a Beaver.

Is it just me or has anybody else noticed that there is no real correlation between the times and claimed credit, for example how can one host that spends twice the ammount of time than another host crunching the same work unit get a claimed credit of only 2.07 more (see link below for meaning).

Surely theres something wrong here or am I just showing that my lack of knowledge on grading results here, Have I missed how the results are graded, and I am not on about the granted credit here as I know thats based on the average from all completed results.

http://setiathome.berkeley.edu/workunit.php?wuid=25292481

The piece missing is the processing speed of the two computers:
Host 1122852
Measured floating point speed 2078.89 million ops/sec
Measured integer speed 3877.74 million ops/sec
CPU Time 9,098.09
Claimed Credit 31.36

Host 201991
Measured floating point speed 1215.55 million ops/sec
Measured integer speed 1601.34 million ops/sec
CPU Time 20,507.16
Claimed Credit 33.43

Slower computer takes more time to do the same work, same work = (approximately) same credit.

Hope this helps make it clear.

MJ

---

Is it just me or has anybody else noticed that there is no real correlation between the times and claimed credit, for example how can one host that spends twice the ammount of time than another host crunching the same work unit get a claimed credit of only 2.07 more (see link below for meaning).

Surely theres something wrong here or am I just showing that my lack of knowledge on grading results here, Have I missed how the results are graded, and I am not on about the granted credit here as I know thats based on the average from all completed results.

http://setiathome.berkeley.edu/workunit.php?wuid=25292481

Actually you've picked an example where the system seems to be working the way it's intended. :-)

For a given WU, the claimed credit should be the same regardless of the host it ran on, all other things being equal.

In practice, due to limitations in benchmarking accuracy, differences in compiler optimizations across platforms (as well as "custom" optimized clients within platforms), differences in host CPU loading, etc, there can be a wide variation between what two hosts will claim on any given work unit.

Alinator

Is it just me or has anybody else noticed that there is no real correlation between the times and claimed credit, for example how can one host that spends twice the ammount of time than another host crunching the same work unit get a claimed credit of only 2.07 more (see link below for meaning).

Surely theres something wrong here or am I just showing that my lack of knowledge on grading results here, Have I missed how the results are graded, and I am not on about the granted credit here as I know thats based on the average from all completed results.

http://setiathome.berkeley.edu/workunit.php?wuid=25292481

I believe seti's aware of this and is working on a fix.
I've noticed the duel processor and ht machines claim about half the credit for the same number of seconds on a single processor which can and has killed my granted on a number of WU's.

---

Is it just me or has anybody else noticed that there is no real correlation between the times and claimed credit, for example how can one host that spends twice the ammount of time than another host crunching the same work unit get a claimed credit of only 2.07 more (see link below for meaning).

Surely theres something wrong here or am I just showing that my lack of knowledge on grading results here, Have I missed how the results are graded, and I am not on about the granted credit here as I know thats based on the average from all completed results.

http://setiathome.berkeley.edu/workunit.php?wuid=25292481

---

Save a tree, eat a Beaver.