Milkyway: DOUBLE CREDIT FUNDRAISER CANCELLED

[Slicker]

Since BOINC is open source, the projects admins have the ability to bypass the new credit system and do whatever they want.

Does DA remind you of NASCAR officials? NASCAR forces drivers to use restrictor plates in much the same way that projects credit uses DA's new credit system if they upgrade their software. For those who don't know what they are, restrictor plates block the amount of air going into the carburator which reduces the horsepower it can make. The more horsepower a car makes, the smaller the hole in the restrictor plate. Of course, the officials say restrictor plates are meant to slow down the vehicles for safety reasons. Sounds good in theory. In reality, they make all the cars go almost exactly the same speed. That means the cars get bunched up and that means more crashes. That's kind of the opposite of safety if you ask me. In addition, it penalizes the good teams and rewards the crappy ones by leveling the playing field. (I though they were pros! Do they give pro drag racers a head start? No!) Anyway, it sure sounds a lot like the new credit system to me.

I always thought the admins lowered (or raised) credit on their own accord and the whole "credit cops" was a conspiracy theory. Until now.... Anyone else see the e-mail in the boinc_projects mailing list between DA and the eon project admin the other day?

> On Jul 29, 2011, at 1:18 PM, David Anderson wrote:
>
>> Sam:
>>
>> The BOINC server code (intentionally) has no mechanism for adjusting
>> credit, to avoid spiraling credit inflation. Instead:
>>
>> - Ask your volunteers which projects are giving more credit than
>> yours, and tell me. I'll investigate.
>>

Looks like the credit cop is not a myth. The really funny part (if you want to call it that) is that the eon admin's reposonse listed WCG, SETI, and uFluids as some of the projects getting more credit. SETI pays high credit? (ROTFL)

[Fire$torm]

OK, that does it.....
Of all the pompous, self centered, egotistical, narcissistic, POS SOB's to walk the planet, DA takes the cake!

Out of curiosity....
*Starting at the 101 level, what is needed to learn to code something like a BOINC server app? (I am serious here, though I realize the odds of success are very slim atm)

*Are there any good free or low cost online classes available for learning most or all of what I would need to learn?

*What does the BOINC backend consist of? And is there a better way to implement a similar setup?

[Mike029]

Wow.. Thanks for the info Slicker. Have they ever reached out to your project? Too bad Boinc does not have any real competition for projects.

[Fire$torm]

Well this ----> http://boinc.berkeley.edu/trac/wiki/CreditNew <---- wasn't hard to find and must come straight from DA's fevered brain....

Credit system goals ¶

Some goals in designing a credit system:

* Device neutrality: similar jobs should get similar credit regardless of what processor or GPU they run on.
* Project neutrality: different projects should grant about the same amount of credit per host, averaged over all hosts.
* Gaming-resistance: there should be a bound on the impact of faulty or malicious hosts.

The first credit system ¶

In the first iteration of BOINC's credit system, "claimed credit" C of job J on host H was defined as

C = H.whetstone * J.cpu_time

There were then various schemes for taking the average or min claimed credit of the replicas of a job, and using that as the "granted credit".

We call this system "Peak-FLOPS-based" because it's based on the CPU's peak performance.

The problem with this system is that, for a given app version, efficiency can vary widely between hosts. In the above example, the 10 GFLOPS host would claim 10X as much credit, and its owner would be upset when it was granted only a tenth of that.

Furthermore, the credits granted to a given host for a series of identical jobs could vary widely, depending on the host it was paired with by replication. This seemed arbitrary and unfair to users.
The second credit system ¶

We then switched to the philosophy that credit should be proportional to the FLOPs actually performed by the application. We added API calls to let applications report this. We call this approach "Actual-FLOPs-based".

SETI@home's application allowed counting of FLOPs, and they adopted this system, adding a scaling factor so that average credit per job was the same as the first credit system.

Not all projects could count FLOPs, however. So SETI@home published their average credit per CPU second, and other projects continued to use benchmark-based credit, but multiplied it by a scaling factor to match SETI@home's average.

This system has several problems:

* It doesn't address GPUs properly; projects using GPUs have to write custom code.
* Project that can't count FLOPs still have device neutrality problems.
* It doesn't prevent credit cheating when single replication is used.

Goals of the new (third) credit system ¶

* Completely automated - projects don't have to change code, settings, etc.
* Device neutrality
* Limited project neutrality: different projects should grant about the same amount of credit per host-hour, averaged over hosts. Projects with GPU apps should grant credit in proportion to the efficiency of the apps. (This means that projects with efficient GPU apps will grant more credit than projects with inefficient apps. That's OK).

[DrPop]

This is a nail in the coffin to end BOINC's glory days. Why on earth should I ever upgrade any of my rigs if credit is going to suck no matter what? Come to think of it, what’s keeping me from pulling a bunch of plugs right now? Does this guy realize how much we spend on electricity alone every month for his little pet BOINC project?

[YoDude9999]

OK, that does it.....
Of all the pompous, self centered, egotistical, narcissistic, POS SOB's to walk the planet, DA takes the cake!

Out of curiosity....
*Starting at the 101 level, what is needed to learn to code something like a BOINC server app? (I am serious here, though I realize the odds of success are very slim atm)

*Are there any good free or low cost online classes available for learning most or all of what I would need to learn?

*What does the BOINC backend consist of? And is there a better way to implement a similar setup?

Didn't I mention this on the Aqua thread and others also?
I coulda swore everyone told me, it would never work, bla, bla, bla, impossible, the projects will never do it, or trying to get them to would be too daunting a task, bla, bla, bla, etc.

You'll need to learn visual studio and the C language. You can find all the client source code on the Boinc website.

[DrBob]

Well I generally try to stay out of this argument when it re-appears every 12 months or so but I need some clarification from those that are concerned…

Here’s what I’m reading, please tell me where I’m wrong.

Credit system goals

Some goals in designing a credit system:

* Device neutrality: similar jobs should get similar credit regardless of what processor or GPU they run on.
* Project neutrality: different projects should grant about the same amount of credit per host, averaged over all hosts.
* Gaming-resistance: there should be a bound on the impact of faulty or malicious hosts.

Device neutrality – Similar WUs should get the same credit no matter what type of CPU/GPU they are processed with. Faster CPUs will still get more credit/day as they process more WUs, GPUs would also get more credit/day if the code was efficient and the projects app can take advantage of the multiple streams. And of course fasted GPUs would still receive more credit than older versions as they would complete more work.

Project neutrality – Comes up all the time and yes in a perfect system a particular host should get the same credit/day no matter which project it is attached to. However I don’t see this ever happening in the “real world” and different apps on the various projects will still perform more efficiently on different system architectures. My only complaint here is some (Including DA) complain when a particular project is granting too much credit but say nothing of projects granting a fraction of what they should.

Gaming-resistance – Absolutely, if a host is turning in bad results or someone is turning in fictitious results just to gain credit the host should receive limited new work until the “problem” is corrected. IMO those proven to be purposely scamming the system should have the credit zeroed out.

Goals of the new (third) credit system

* Completely automated - projects don't have to change code, settings, etc.
* Device neutrality
* Limited project neutrality: different projects should grant about the same amount of credit per host-hour, averaged over hosts. Projects with GPU apps should grant credit in proportion to the efficiency of the apps. (This means that projects with efficient GPU apps will grant more credit than projects with inefficient apps. That's OK).

Not sure I would have any problem with the “goals” of the new credit system but doubt they will ever be achieved equitably.
As I said earlier, I try to stay out of this particular debate. If I’m reading something terribly wrong here please feel free to educate me.

If our old boards were still available we could go back and read the numerous and often lengthy threads on this particular subject.

[zombie67]

Fact: Cross project parity is impossible. It assumes static apps, no development or optimization. Here is a simple example of why it will never work. There are MANY more scenarios that would demonstrate the same thing.

Project A and B have CPU apps that have the same c/h. Then a volunteer for project B works hard and creates an app that 2x faster, and shares it with everyone. Now what? B cuts their credits in half, or has them cut in half automatically? Thanks a lot! That volunteer was stupid to try to help out the project...unintended consequences.

Now throw in things like 32 vs 64 bit apps, GPUs, MT, optimized apps that run on only a subset of machines (SSE3), etc. Oh yeah, and don't forget to throw in projects where there are more than one sub-project, some with GPUs, some without. You have to average that all out and compare the whole mess to another project and somehow mess with the credits to achieve parity? Impossible.

---

Personal opinion: This is why MMs are the true way to measure performance, both individually and as a team.

[Fire$torm]

I agree with much of zombie's way of thinking. Not that I don't respect alternate views on the subject.

The fact remains that DA set the bar years ago by ALLOWING project admins to implement an alternate credit schema. It is also a fact that he created BOINC as open source software albeit with a restricted LGPL license. Common sense dictates that he was hoping for and received a LOT of help from the DC community. And now that the BOINC project has reached the point where much (or at least a decent percentage) of the vocal DC community has motivated some projects to "Up the Ante", DA comes along and decides they have no value, hence deserve little or no respect. This is evidenced by two simple truths, one - the CreditNew schema and two - DA has never had an open discussion, round table, public hearing or whatever one might call it with the DC community at large. At least not that I have seen.

Bottom line. DA has accepted a ton of code from the community but when community members voice an opinion..... His answer is "Shut up and bend over".

[DrPop]

So, this leads us to one question: What 'er we gonna do about it?