Message boards :
Number crunching :
Average Credit Decreasing?
Message board moderation
Previous · 1 . . . 17 · 18 · 19 · 20 · 21 · 22 · 23 . . . 32 · Next
Author | Message |
---|---|
betreger Send message Joined: 29 Jun 99 Posts: 11412 Credit: 29,581,041 RAC: 66 |
Amen |
tullio Send message Joined: 9 Apr 04 Posts: 8797 Credit: 2,930,782 RAC: 1 |
I've split work. I am running Einstein@home GPU tasks on my Windows/Nvidia PC and both SETI@home and SETI Beta GPU tasks on my Linux/ATI box with OpenCL. But I am getting many more credits from Einstein with its fixed credits system. Tullio |
Grant (SSSF) Send message Joined: 19 Aug 99 Posts: 13841 Credit: 208,696,464 RAC: 304 |
Just a thought... The old system was not an indicator of work done. Getting 1 Credit for a noisy WU that lasts 3 seconds is not even close to being on par with getting 1 Credit for a WU that takes 12 hours to complete. Just get rid of the fudge factor for the (supposed) actual v highly theoretical efficiency factor. There should just a be reference system with a reference application. The time it takes for it to process a valid WU should determine the amount of Credit granted for that WU. A noisy WU 0.5 Credits. A shorty 5 Credits A mid range unit 50 Credits A VLAR 100 Credits (even for those occasional VLARs that take 50% longer than most others- the same amount of work is being done, it's just taking longer due to application limitations). WUs of other ARs between those 3 get proportionally more or less Credit. (Numbers created at random with no relationship to the actual values of a Cobblestone. Just used for illustrative purposes only). If your hardware does things in less time, then you will get more Credit per day than the reference system. If it's slower, then you get less. If there is an optimised application for your specific hardware then you will get even more Credit per day. If the project releases an improved application then everyone that uses it will get more Credit per day than the reference system. There is no fudging of the Credit system for (supposed) actual v theoretical efficiency. The new stock application is more efficient than the reference, so it will result in more Credit per day. New hardware comes along, an application is written for it. If it's faster than the reference system, you will get more Credit per day than the reference. If that application is then optimised, then you will get even more Credit per day. Theoretical efficiencies have nothing to do with Credit granted. Grant Darwin NT |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
Then the question arise "how bad" ref app should be. Definitely that ref app can't just be stock CPU app cause it has different paths for different CPU capabilities for example. So, 1) where to find that app... 2) how to translate credits between different apps (AP vs MB, MBv6 vs MBv7 (autocorr search added) ) 3) how to translate between different projects. All these questions lead to requirement of more universal approach. Cause being implemented as is it's even worse than FLOP counting "v2" approach where project scientist arbitrary (in fact, cause real floating point performance will relate on memory throughput and access pattern too as trivial example) assigns some FLOPs connected with specific parts of algorithm and credit calculated just adding FLOPs for computed parts. BTW, AFAIK some projects, where different apps really very different (for example, where few different subprojects implemented) indeed abandon whole idea of universal credit and grant separate entities (like different badges) for separate subprojects. It has own advantages - for example, nobody will whine about AP vs MB credit dispairing cause all will see that there are AstoCredits and MultiCredits.... |
Brent Norman Send message Joined: 1 Dec 99 Posts: 2786 Credit: 685,657,289 RAC: 835 |
I would say that GBT has to be the new reference, since Eric has said that 90% plus tasks will be coming from there. Which app, CPU CUDA AMD I will leave to the experts to figure out :) |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
And such scheme will allow decoupling between technical(scheduling!) meaning of RAC and credits and their social (competitive) meaning. From other side, competition will be more complex cause there will be no single param to max out. In short, leave CreditScrew fixing for scheduling improvement and revert to "v2" FLOP-counting with important addition: always recall that those FLOPs of "different color" for different algorithms so all credits are "colored" and should remain such (separate credit accounting for different algorithms). This will make competition fair... but restrics it only to particular algorithm/app/subproject. [though, "fairness" will be limited even here - MB and its' AR-curve.... those colors will form "continuous spectrum" LoL ] (PulseFind FLOPS of light green, autocorr of magenta and Triplets of dark blue... what a nice palette we will have :D ) |
Grant (SSSF) Send message Joined: 19 Aug 99 Posts: 13841 Credit: 208,696,464 RAC: 304 |
BTW, AFAIK some projects, where different apps really very different (for example, where few different subprojects implemented) indeed abandon whole idea of universal credit and grant separate entities (like different badges) for separate subprojects. It has own advantages - for example, nobody will whine about AP vs MB credit dispairing cause all will see that there are AstoCredits and MultiCredits.... Which defeats the whole idea of BOINC credits. Grant Darwin NT |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
BTW, AFAIK some projects, where different apps really very different (for example, where few different subprojects implemented) indeed abandon whole idea of universal credit and grant separate entities (like different badges) for separate subprojects. It has own advantages - for example, nobody will whine about AP vs MB credit dispairing cause all will see that there are AstoCredits and MultiCredits.... yep. No universal credits. "ref app" approach defeats it too cause there can't be single ref app for DIFFERENT algorithms... |
Grant (SSSF) Send message Joined: 19 Aug 99 Posts: 13841 Credit: 208,696,464 RAC: 304 |
Then the question arise "how bad" ref app should be. 1 What is the oldest hardware supported? The original release application for that hardware would determine the amount of Credit a WU was to receive. The mix of Shorties, mid range & VLARs over a week (or month) would result in an average amount of work done per day or hour. So Credits per day or hour for that reference system would be the reference value. 2 The original release application for the new application becomes the new standard- however it is referenced to the old standard so that on the reference hardware it would result in (approximately) the same credit per day/ hour etc as the original application did. This avoids Credit deflation with the introduction of longer running applications. 3 The oldest supported hardware with the original application has already set the amount of credit per hour the reference system will produce. Other projects base their awarding of Credit to give (approximately) the same amount of Credit per hour/day etc as Seti. FLOP counting "v2" approach where project scientist arbitrary (in fact, cause real floating point performance will relate on memory throughput and access pattern too as trivial example) assigns some FLOPs connected with specific parts of algorithm and credit calculated just adding FLOPs for computed parts. The system prior to the launch of Credit New wasn't perfect, but it was better than what came before, and orders of magnitude better than what we have now with Credit New. Grant Darwin NT |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
BTW, that "how bad ref app should be" question not so simple. While it can be tweaked for different SIMD levels it can't account for old-school generic optimization when optimizer learns algorithm better than initial coder did ... And that's part of issue with current AP credits state. There is initial AP app still distributed. Initial Lunatics app distributed as "advanced SIMD" one.. but actually it contains few my and not my only generic optimization that allow x2 (at least) speedup w/o any connection to SIMD level of app. So, how bad ref app should be - it's the real question... Then take similar app as original AP was for project A, and state of art CPU app like current CPU MB for project B... call them ref apps and ... and get all those "why MilkyWay pays so much more than SETI" as we have currently. (BTW, names of project has real meaning, initial MW app was optimizad in HUGE degree...) |
Grant (SSSF) Send message Joined: 19 Aug 99 Posts: 13841 Credit: 208,696,464 RAC: 304 |
Which defeats the whole idea of BOINC credits. No, the idea of a reference application doesn't defeat cross project comparison of credits, it actually makes it possible. The reference application on the reference hardware will produce so many Credits per hour/day/week/month or whatever. All other projects base their granting of credit with their original release applications to give the (approximately) same amount of credit per hour/day/week/month whatever. Grant Darwin NT |
Grant (SSSF) Send message Joined: 19 Aug 99 Posts: 13841 Credit: 208,696,464 RAC: 304 |
So, how bad ref app should be - it's the real question... The originally released project application, as it was designed for the greatest possible compatibility, not performance. Grant Darwin NT |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
So, how bad ref app should be - it's the real question...
yep :) [though adding: ref apps should be optimized at the same level would solve issue... but to determine to whom they should will be next interesting question :D |
Darth Beaver Send message Joined: 20 Aug 99 Posts: 6728 Credit: 21,443,075 RAC: 3 |
How about just leaving Credit new alone and do what I have said have a extra formula for the Vlars only Something like what I put up it's simple won't bruse any ego's The only thing that has to be decided is weather you apply it to all units meaning all units will get a Time credit or weather you only apply it to vlars Or just go back to what Richard said 1 unit 1 credit like the old days then the real race will be down to who can process the units the quickest and that's is more a personal race . mm "If I upgrade this i'll be able to do them in ??hrs ,""but if I upgrade my whole system it will be better mmm how much cash have I got "example of a conversation in my head back then :-) Darn it I was down to 11hrs before the whole thing was changed and I thought that was great considering I started at 33hrs per unit |
rob smith Send message Joined: 7 Mar 03 Posts: 22492 Credit: 416,307,556 RAC: 380 |
...to do so would mean dismantling some very badly written and ill-documented code - most of this is due to the way the code has been patched over the years. It would be far simpler to remove the whole section that does the credit calculation and replace it with a simple look-up table, with Angle-range as the control value, and credit as the return value - having spent a few weeks looking at Angle-Ranges and Run-Times I think there would only need to be four or five values - so simple to implement and so effective..... Wrap a bit of fairly simple error trapping around that and you get a "fair" credit system that awards the user for the task run in much the same way as many other BOINC based projects do. Bob Smith Member of Seti PIPPS (Pluto is a Planet Protest Society) Somewhere in the (un)known Universe? |
jason_gee Send message Joined: 24 Nov 06 Posts: 7489 Credit: 91,093,184 RAC: 0 |
Actually what it all means, I predict, is that the existing mechanism (that whoever made it obviously feels is 'fine') will break within the next 8.3 months, and since both the provided math and the lack of user collaboration to fix it indicate, whoever made it has no idea what they made or how it works and where it falls short. Pretty simple really. It's supposed to estimate how long tasks take, and does a crap job of that, so no reason we should expect it to get credit more right. "Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions. |
Darth Beaver Send message Joined: 20 Aug 99 Posts: 6728 Credit: 21,443,075 RAC: 3 |
(that whoever made it obviously feels is 'fine') mm I wonder who that could be mmmm your to diplomatic mate !! |
kittyman Send message Joined: 9 Jul 00 Posts: 51477 Credit: 1,018,363,574 RAC: 1,004 |
I don't get too wound up about the whacko credit system any more. It is what it is....broken. But, since it is as broken for everybody else as it is for me, it still allows some comparison between myself and all others here on Seti. Comparison between projects was never possible when others are allowed to award credits in whatever fashion they wish to. And some do not use CreditMew at all. I am more interested in a better app to deal with these nasty crunching Guppies.... Meow. "Time is simply the mechanism that keeps everything from happening all at once." |
Chris Adamek Send message Joined: 15 May 99 Posts: 251 Credit: 434,772,072 RAC: 236 |
Except for the people who are abandoning all GPU Green Bank work. Saw a dude on the first page of the top computer stat page who, between his 4 computers, has abandoned almost 2000 tasks to keep his precious RAC up. That's getting to the point of absurdity IMHO... Chris |
kittyman Send message Joined: 9 Jul 00 Posts: 51477 Credit: 1,018,363,574 RAC: 1,004 |
Yeah, a bit crappy. Dunno how someone can feel much pride in that accomplishment. You might out him right here in this thread. Then we'll see how proud they are of their RAC. As usual, the kitties have taken the high road and are dutifully crunching as best they can everything that the server sends. Meow! "Time is simply the mechanism that keeps everything from happening all at once." |
©2024 University of California
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.