In past a MB AR=0.44x WU got 42.x credits.

Now the same MB AR get 38.x credits?


WHY ??

---

In past a MB AR=0.44x WU got 42.x credits.

Now the same MB AR get 38.x credits?


WHY ??

Guess you already forgot about that credit adjustment thingy from mid of last year.
If you mean something different, you need to present more detail.

---

_\|/_
U r s

I'm curious about why it need to reduce again..


AFAIK, other project have more credits/hour than SETI@home.
..much more.

Krazy Kenzie’s Kredit Krunch


..will show it soon..

---

BTW.

The past which I mean is the end of March.. ;-)

At the end of March to beginning of April it changed ' - 4 ' credits for the same MB AR-WU..

---

AFAIK, other project have more credits/hour than SETI@home.
..much more.

Because SETI is the "benchmark" project, SETI should give 1 cobblestone of credit for 1 cobblestone worth of work.

Calibrating credit is not easy, and there are many projects who overpay, and more than a few that underpay.

Given that it takes about 3 billion cobblestones to buy one ships' peanut, I'm not sure how much this matters in the real world.

---

I'm little bit confused about some of my teammate which say that a:

ATI Radeon HD 4870
Make in 10 sec. one WU
This is a RAC of ~ 80,000 !

..at MilkyWay@home..


For my knowledge this is cheating.. nothing else..



O.K., current the ATI GPUs have no chance here.. because no support..
..maybe in future..


But.. I think some project must think twice about their credits!


BTW.
I will crunch only SETI@home what ever will be..
The credits are not important for me.
I want only support the science.

But if there are credit hunters out there.. they will think twice if they want to crunch SETI@home with less credits/hour.



-----------------------------

ATI Radeon HD 4870
800 Stream-Processors
1.2 TFLOPS
[from a report in Inet]

MilkyWay@home - ~ 80,000 RAC


nVIDIA GeForce GTX260 Core216 [OC Edition]
216 Stream-Processors
Message in my BOINC: 112 GFLOPS
[in a report I read, stock GPU: ~ 800 GFLOPS]

SETI@home - ~ 7,500 RAC

-----------------------------

O.K., from the FLOPS it could be correct the credits..
But..


And I read that this ATI GPU need half the wattage as my GTX260 Core216 if crunching !

If the ATIs will have the same performance here also like at MilkyWay@home.. of course the next GPUs for me would be ATI [for SETI@home]..

---

But if there are credit hunters out there.. they will think twice if they want to crunch SETI@home with less credits/hour.

... and this has been discussed over the years in great detail.

We have a definition of a cobblestone: a certain amount of work done by a certain computer in a certain amount of time.

That "reference computer" should get 100 cobblestones per day.

Personally, I think some of the projects simply throw the doors open and then find that their credit isn't quite accurate. At that point, they can adjust it, and up or down someone is going to be mad -- or they can hang tight, and take the flak for overpaying/underpaying.

It's a no-win situation.

If you look at some of the cross project stats, as I remember SETI is around middle-of-the-pack -- some projects pay 3x or more, and some pay about 1/3rd.

I think that's more or less where they should be.

---

Ned, I think the thing that bothers people, is that there has been o change to the application and there was no announcement from the team.

Urs that credit change made a difference of 15 - 20 per cent. This is a new drop in the credit awarded.

Saturu, what are complaining about Milkyway for? The GPU app was developed and now Travis is working on Apps for Cuda for Windows, Linux and MAC OS X. Sheds a new light on things really.

---

As I understand it, the "reference computer" is now a moving target based on some function (the mean speed?) of all the hosts returning valid results. This was discussed in some depth about 6 months ago so no-one should be expecting to see a fixed cobblestone value per angle-range any more.

F.

---

O.K., like I said, what ever will come.. I will continue to support only my one and only loved project.. SETI@home ! :-)

But, it's little bit disappointed, that not all project 'pay' the same..


Because of compare the HD 4870 and GTX260:
computerbase.de/artikel

The ATI have 1,200 GFLOPS
The nVIDIA have 800 GFLOPS

For my knowledge, if the GTX260 have at SETI@home a RAC of: ~ 7,500
Then the HD 4870 should have at MilkyWay@home a RAC of: ~ 11,250

I thought we have now a credit system with FLOP counter..



Maybe here are MilkyWay@home member around with ATI GPUs?

Please give a note which GPU and RAC.. :-)

---

It is probably the CUDA app that has caused this reduction in credits. Mainly because the reported completion time was not based on reality.
Therefore the fault is not with Seti but BOINC for failing to report gpu + cpu time.

Therefore if you want the credits to be where they should be STOP using your graphics card.

It is probably the CUDA app that has caused this reduction in credits. Mainly because the reported completion time was not based on reality.
Therefore the fault is not with Seti but BOINC for failing to report gpu + cpu time.

Therefore if you want the credits to be where they should be STOP using your graphics card.

LOL. Not very likely...

Fred if what you say is true, then the decrease should have been progressive, not a jump every six months.

---

As I understand it, the "reference computer" is now a moving target based on some function (the mean speed?) of all the hosts returning valid results. This was discussed in some depth about 6 months ago so no-one should be expecting to see a fixed cobblestone value per angle-range any more.

F.

Fred,

The reference computer is "defined." It is rock solid.

Using the reference to set credit says that the granting of credit must be based on benchmark * time.

Like it or not, benchmark * time and granting the "middle" score worked. Sometimes you got more, sometimes you got less, but on average you got the right credit.

Counting flops is more repeatable, but it isn't necessarily accurate. It is based on the idea that all flops are created equally.

There is a constant that tries to scale the flop count into something like a benchmark * time score.

Getting the constant right takes lots of tweaking -- probably too much.

The servers know what the benchmark * time score would have been, and what the flop-based score is. Sample a group of "middle" computers, and you know how far FLOP counting diverges from scores based on the mythical 100-cobblestome computer.

Has CUDA shifted the middle upwards to the point where it isn't very accurate? It's possible, because as I understand it we aren't benchmarking the GPU. Eric would know, if he's looked at it recently.

... but when you say that the standard is "floating" that is not accurate. The standard is fixed. The problem is that the standard is an "apple" and the method of granting credit uses "oranges. The project is trying to make oranges look like apples.

-- Ned

---

Ned, I think the thing that bothers people, is that there has been o change to the application and there was no announcement from the team.

Which assumes all kinds of facts not in evidence.

Starting with the fact that for the team to announce that credit was being changed, they would have to make a conscious decision to change credit.

The whole point of Eric's credit adjuster, mentioned elsewhere on the thread, is to take the granting of credit off of the developers' plates -- so they can release a new application without having to spend six months dialing in the multiplier that converts FLOPs to Cobblestones.

We're also ignoring (as usual) the fact that a rising tide lifts all boats. If the multiplier changes, it changes for everyone.

We're assuming that every Multibeam unit gets exactly the same credit based solely on the Angle-Range. We know that "overflows" do much less work. Did we look at the FLOP counts?

... and we're forgetting that the net cash value of a billion cobblestones is just exactly $0.

Credit is good. It measures performance, and it measures how we're doing compared to everyone else -- but credit is an approximation, and that's true no matter how much we want it to be otherwise.

---

You can see the effects of Eric's auto-adjustment script on recent Astropulse_v5 tasks. Because these all have the same FLOPs estimate, it's easy to match them up, and see the gradual progression over time. Here are some of my pendings since the beginning of March:

_1 Mar 2009 ___	1,212.38
_2 Mar 2009 ___	1,214.01
_4 Mar 2009 ___	1,216.71
_7 Mar 2009 ___	1,221.54
_9 Mar 2009 ___	1,224.57
10 Mar 2009 ___	1,225.27
11 Mar 2009 ___	1,226.88
12 Mar 2009 ___	1,228.53
13 Mar 2009 ___	1,230.58
14 Mar 2009 ___	1,232.81
15 Mar 2009 ___	1,236.62
18 Mar 2009 ___	1,241.00
19 Mar 2009 ___	1,242.97
23 Mar 2009 ___	1,249.00
24 Mar 2009 ___	1,250.47
26 Mar 2009 ___	1,255.40
27 Mar 2009 ___	1,256.62
28 Mar 2009 ___	1,258.38
29 Mar 2009 ___	1,259.87
30 Mar 2009 ___	1,260.71
_1 Apr 2009 ___	1,261.68
_2 Apr 2009 ___	1,261.98

---------------------------------------

WU True angle range: 0.447962
Claimed credit 42.0589188818647

Sent 22 Mar 2009 20:09:36 UTC
Received 31 Mar 2009 1:30:26 UTC

---------------------------------------

WU True angle range: 0.447952
Claimed credit 40.8764912429021

Sent 27 Mar 2009 3:36:16 UTC
Received 5 Apr 2009 19:22:49 UTC

---------------------------------------

..from my old Athlon 600.

Changing from stock to opt. will not change the Credits.


The credits - from the first post in this thread - are from my CUDA rig.
But, I took the credits from my 'wingmen', because of the CUDA overclaim..


ALSO.. between AP and MB there is a different.



How BOINC measure the GFLOPS of the GPUs?
Or it's from a data base?

Why have a GTX260 Core216 (stock) 805 GFLOPS, and my OCed in BOINC 'only' 112 GFLOPS?
It's different measured areas? GPU / shader or other?

---

You can see the effects of Eric's auto-adjustment script on recent Astropulse_v5 tasks. Because these all have the same FLOPs estimate, it's easy to match them up, and see the gradual progression over time. Here are some of my pendings since the beginning of March:

_1 Mar 2009 ___	1,212.38
_2 Mar 2009 ___	1,214.01
_4 Mar 2009 ___	1,216.71
_7 Mar 2009 ___	1,221.54
_9 Mar 2009 ___	1,224.57
10 Mar 2009 ___	1,225.27
11 Mar 2009 ___	1,226.88
12 Mar 2009 ___	1,228.53
13 Mar 2009 ___	1,230.58
14 Mar 2009 ___	1,232.81
15 Mar 2009 ___	1,236.62
18 Mar 2009 ___	1,241.00
19 Mar 2009 ___	1,242.97
23 Mar 2009 ___	1,249.00
24 Mar 2009 ___	1,250.47
26 Mar 2009 ___	1,255.40
27 Mar 2009 ___	1,256.62
28 Mar 2009 ___	1,258.38
29 Mar 2009 ___	1,259.87
30 Mar 2009 ___	1,260.71
_1 Apr 2009 ___	1,261.68
_2 Apr 2009 ___	1,261.98

True, it illustrates the gradual adjustment which ought to happen. Of course the adjustment for S@H Enhanced work is separate from that for Astropulse_v5 and Sutaru's point that Enhanced credit seems to have made a fairly abrupt change is difficult to explain. IMO it probably is related to CUDA both being faster and BOINC grossly under-reporting the time for those hosts.

I think it's a small price to pay for increased project productivity, but if it drives away too many who focus on credit the long-term effect may be counterproductive.

                                                                  Joe

True, it illustrates the gradual adjustment which ought to happen. Of course the adjustment for S@H Enhanced work is separate from that for Astropulse_v5 and Sutaru's point that Enhanced credit seems to have made a fairly abrupt change is difficult to explain. IMO it probably is related to CUDA both being faster and BOINC grossly under-reporting the time for those hosts.

Eric's script takes the median of, IIRC, 10,000 recent reported tasks. Maybe it's possible that the number of tasks reported by CUDA hosts has made the median reach a tipping point: last time we looked, it was firmly in the P4 range. If it's crept up into Core2 territory, then the changed benchmark/productivity ratio would explain the effect.

I'm concerned that this is all anecdotal so far. Nobody has posted any sourced, dated, factual information on MB tasks. Maybe it's time for another Hosts db dump.

Okay, I think Sutaru is talking about this situation.

http://setiathome.berkeley.edu/result.php?resultid=1182474287

against

http://setiathome.berkeley.edu/result.php?resultid=1196522444

There has been an 10% drop in claimed credit even for Cuda.

---