Amen

---

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

---

Just a thought...
Perhaps going back to the days of SETI Classic is the answer: One WU completed equals one credit (Cobblestone). It is still an indicator of how much work your machine has completed without the imaginary number multiplied by some correction factor.

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

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....

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 :)

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....

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 )

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

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.

yep. No universal credits. "ref app" approach defeats it too cause there can't be single ref app for DIFFERENT algorithms...

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.

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

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...)

Which defeats the whole idea of BOINC credits.

yep. No universal credits. "ref app" approach defeats it too cause there can't be single ref app for DIFFERENT algorithms...

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

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

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.

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 optimized in HUGE degree...)

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

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

---

...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?

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.

(that whoever made it obviously feels is 'fine')

mm I wonder who that could be mmmm your to diplomatic mate !!

---

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."

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.

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

---

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.

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

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."