again less credits?
again less credits? |
|
| log in |
Message boards : Number crunching : again less credits?
1 · 2 · 3 · 4 . . . 7 · Next
| Author | Message |
|---|---|
 [seti.international] Philip J. Fry Volunteer tester  Send message Joined: 6 Apr 07 Posts: 6566 Credit: 50,685,782 RAC: 20,131  | |
|
| |
ID: 882293 ·  | |
|
Urs Echternacht Volunteer tester Send message Joined: 15 May 99 Posts: 501 Credit: 23,152,661 RAC: 42,056 | |
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 | |
| ID: 882333 · | |
|
[seti.international] Philip J. Fry Volunteer tester Send message Joined: 6 Apr 07 Posts: 6566 Credit: 50,685,782 RAC: 20,131 | |
|
| |
| ID: 882342 · | |
|
[seti.international] Philip J. Fry Volunteer tester Send message Joined: 6 Apr 07 Posts: 6566 Credit: 50,685,782 RAC: 20,131 | |
|
| |
| ID: 882352 · | |
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. ____________ | |
| ID: 882363 · | |
|
[seti.international] Philip J. Fry Volunteer tester Send message Joined: 6 Apr 07 Posts: 6566 Credit: 50,685,782 RAC: 20,131 | |
|
| |
| ID: 882373 · | |
... 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. ____________ | |
| ID: 882450 · | |
|
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. | |
| ID: 882490 · | |
|
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. | |
| ID: 882494 · | |
|
[seti.international] Philip J. Fry Volunteer tester Send message Joined: 6 Apr 07 Posts: 6566 Credit: 50,685,782 RAC: 20,131 | |
|
| |
| ID: 882498 · | |
|
It is probably the CUDA app that has caused this reduction in credits. Mainly because the reported completion time was not based on reality. | |
| ID: 882502 · | |
It is probably the CUDA app that has caused this reduction in credits. Mainly because the reported completion time was not based on reality. LOL. Not very likely... | |
| ID: 882503 · | |
|
Fred if what you say is true, then the decrease should have been progressive, not a jump every six months. | |
| ID: 882505 · | |
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. 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 ____________ | |
| ID: 882517 · | |
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. ____________ | |
| ID: 882524 · | |
|
Richard Haselgrove Volunteer tester Send message Joined: 4 Jul 99 Posts: 7453 Credit: 39,525,124 RAC: 32,155  | |
|
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 | |
| ID: 882542 · | |
The other day I changed to optimized versions from stock versions on all my computers. On stock version I got 42.x credits on a MB AR=0.44x WU. With the optimized versions I get 38.x credits for the same type of WU. Sten-Arne | |
| ID: 882544 · | |
|
[seti.international] Philip J. Fry Volunteer tester Send message Joined: 6 Apr 07 Posts: 6566 Credit: 50,685,782 RAC: 20,131 | |
|
| |
| ID: 882581 · | |
|
Josef W. Segur Volunteer developer Volunteer tester Send message Joined: 30 Oct 99 Posts: 3930 Credit: 934,263 RAC: 14  | |
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: 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 | |
| ID: 882626 · | |
|
Richard Haselgrove Volunteer tester Send message Joined: 4 Jul 99 Posts: 7453 Credit: 39,525,124 RAC: 32,155 | |
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. | |
| ID: 882631 · | |
Message boards : Number crunching : again less credits?
| Copyright © 2013 University of California |
