What is the difference in points between AP and MB?
I hope and pray this is a PC ok question.
I am looking for a ratio like 1.5:1 or such.
danke

---

merle - vote yes for freedom of speech

Very hard to give an accurate ratio as the credits for each are highly dependent on a number of factors.
That said: In days gone by an "average" MB was worth about 100 credits and an "average" AP was worth about 800. But these days I've seen "average" MBs being awarded between 5 and 125, with APs in the range 200-800..
In terms of credi/hour you just have to look and see what your system delivers in terms of tasks per hour - looking at one of my system it delivers short run MBs in about 90 minutes on the CPU, or 8 minutes on the GPU, but tasks from both get about the same credits....

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

Well, there are large variances due to the "random number generator" (CreditNew) and how it decides how many credits to give for certain tasks, but recently, someone asked a similar question in the AP thread, to which I answered:

I just picked an absolutely random wingmate from my tasks list and they have a zero-blanked AP that was crunched in 3511 seconds and got 593.35 credits for it.

That same host, on the same GPU, an MB with an angle range of 0.377422 (I tried finding one around/near 0.41~4 (which is what I think is a "normal" or average WU), but that was as close as I could find) did it in 1152 seconds and got 117 credits for it.

AP: 593.35/3511 = 0.168997 credits/second
MB: 117/1152 = 0.1015625 credits/second

Extrapolate both of those out, and you get:

AP: 608.39 credits/hour
MB: 365.625 credits/hour

tl;dr: AP "pays" better.

I'm pretty sure when MBv7 came out, there were a lot of complaints and observations that it paid about 30% less than what v6 did, which was already ~30% less than AP at that time.

Of course, the credits/hour from both types of work should be pretty similar on the same device, but then you get into a paradoxical quandary of.. "is MB not getting enough credits/hour... or is AP getting too much?" Obviously there's a difference between them, but which one is closer to what should be ideal? Or is it both--meaning MB is ~30% low and AP is ~30% high?

There is at least one person I know of that has code-walked through CreditNew and are probably the only person that truly understands how and why it works the way it does, and they said there are some fundamental problems with it that shouldn't be hard to fix, but I don't recall if he was able to determine which type of work was closer to the expected mean (average).

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

There is at least one person I know of that has code-walked through CreditNew and are probably the only person that truly understands how and why it works the way it does, and they said there are some fundamental problems with it that shouldn't be hard to fix,

If that person was one of the volunteer developers AFAIK he was ignored by the power that is in charge.
The credit doesn't matter to me though because I'll never get enough to get a toaster.

---

There is at least one person I know of that has code-walked through CreditNew and are probably the only person that truly understands how and why it works the way it does, and they said there are some fundamental problems with it that shouldn't be hard to fix,

If that person was one of the volunteer developers AFAIK he was ignored by the power that is in charge.
The credit doesn't matter to me though because I'll never get enough to get a toaster.

No that's not the case at all. It was myself and some others that explored the nature of the problems in great detail, and there was interest and some input from Eric here, as well as access to some resources from Albert@home. A series of bad timing , and a prolonged explosion in my work commitments put a hard stop on that for now.

In addition, the nature of the root problems is fairly intricate, and so difficult to communicate and come to a consensus on what needs to be done. In general I so far failed to find a way to effectively communicate that the problems are relative, for example it looks 'fine' from some global server side viewpoints, but unstable and even broken for some end-user client purposes.

What I learned from that process is that communicating the benefits of well engineered control systems, and what they are capable of, as well as code quality, is difficult. In addition, the time investment needs to come third fiddle to the next round of XBranch development, followed by ongoing real life commitments.

One recent positive, that affects that balance greatly, is in recent moves on the Boinc dev list to using a static code analyser (Coverity scan). At least one main boinc dev reacted that he was shocked at the number and type of faults/vulnerabilities that were detected in the Boinc codebase, when I pointed out addressing those would likely reduce odd behaviour.

So anyway, that makes a possible future attempt at more effectively communicating the design flaws in CreditNew, with possible fixes, a bit easier with a possibly greatly improved foundation underneath it. It doesn't solve my own logistical problems, or how to effectively communicate the importance of the CreditNew mechanism to work properly as a complete control system. That's probably something that could warrant assembling a fully resourced spin-off project to refine.

You can view a somewhat disjointed summary of the nature of the problems at
https://wiki.atlas.aei.uni-hannover.de/foswiki/bin/view/EinsteinAtHome/BOINC/EvaluationOfCreditNew

Solutions aren't given there, though a number of resources describing different techniques are given in the resources section. In general though, suffice it to say that for reasonably sized projects (say 1000+ active users) replacing the poorly defined pfc_scale metric that CreditNew uses, with a better defined computation_efficiency one, using proper stochastic control systems techniques at multiple levels spread in time, would formalise and refine the process enough to make adding new hosts/applications or changing hosts a dream by comparison to today. Classic control system alternatives exist, just not as powerful and need hand tuning. The current mechanism comes out to be pretty naive in engineering terms.

---

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

Merle the answer is yes AP's give about 5-8 times what MB's do . When I work out what I should get I use 55 for MB and 475 for AP's as a average .

---

Jason thanx.

No that's not the case at all. It was myself and some others that explored the nature of the problems in great detail, and there was interest and some input from Eric here, as well as access to some resources from Albert@home. A series of bad timing , and a prolonged explosion in my work commitments put a hard stop on that for now.

That is a good thing for you

---

Jason thanx.

No that's not the case at all. It was myself and some others that explored the nature of the problems in great detail, and there was interest and some input from Eric here, as well as access to some resources from Albert@home. A series of bad timing , and a prolonged explosion in my work commitments put a hard stop on that for now.

That is a good thing for you

Certainly taught me a lot about people and having the right resources to approach something :) One-day, fingers crossed, we can tackle the design issues.

---

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

Jason IMO getting credit new right would be a big thing for DC as we do it.

---

Jason IMO getting credit new right would be a big thing for DC as we do it.

Yeah, I agree. One of the stumbling blocks (there are others) has been the idea that it's just about Credits/RAC. In fact it's tightly interwoven with the scheduling and control of tasks at all levels from server through client. At a project level, having meaningful numbers can be a powerful tool also, as well as for optimisation. There's little incentive to improve anything, if the measuring stick just says 'meh', lol

---

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

At a project level, having meaningful numbers can be a powerful tool also, as well as for optimisation.

Or a powerful disincentive to participate for those who care about such things and who have been provided with nothing else to care about.

At a project level, having meaningful numbers can be a powerful tool also, as well as for optimisation.

Or a powerful disincentive to participate for those who care about such things and who have been provided with nothing else to care about.

That is probably the clearest explanation for the double-edged sword that is credit/RAC.



I was thinking about this a little while ago after reading Jason's input and quite honestly, we wouldn't even be discussing this mess of CreditNew and the complaints about credits not being fair and balanced.. if we didn't even have credits in the first place. They realistically serve no purpose at all.

The whole point of distributed computing is to volunteer processing time for scientific endeavors that the researchers themselves don't have the processing power for, or can't afford to have the processing power. In a way, we're all contributing to science without having to actually know anything about the science we're helping to discover. That's what these projects are all about.. is the science.

Adding credits into the mix ended up causing more problems than are necessary, mostly because of the people who honestly don't care about the science at all, they just want the bragging rights to show that they have more money to spend on hardware (or access to server farms) than someone else. I know it was originally intended to be harmless fun, but it ended up spiraling into something way far beyond harmless or fun.

I think we could probably just abolish the whole credit system and possibly switch over to a measure of FLOPs instead. For instance, I'm on the verge of 10M credits, but what does that even mean? That doesn't amount to anything, really. But if I was nearing 10 TeraFLOPs of total computations.. that is something that is measurable and comparable to other things, since many other computing tasks are also measured in either how many FLOPs they need, or the rate of FLOPs to do something. And as far as I know, the tasks and the applications have pretty reasonable and low-overhead ways of counting the FLOPs needed for that task, so why can't we just use that instead? It would be universal across all projects, too.

Of course, then it would still end up with a very similar situation that we're in now with the credits, because some projects' tasks have more FLOPs in a given period of time than others, so everyone would flock to that project to get their totals higher.

So even that wouldn't be a great idea. And it's not like you can just do like Classic did where you count how many WUs you've done, because then nobody would ever want to touch APs again. And you can't count by how much processing time you've contributed, because then people would come up with ways to de-optimize as much as absolutely possible so that tasks take longer to crunch rather than less time.

There's just no good solution other than to just get rid of credits altogether. But no matter what ends up happening, there's always going to be someone who complains about the decision that was made. There's people that complain about credit disparity between projects as it stands right now. Going back to what I said earlier about figuring out if MB is under-credited, or if AP is over-credited--or both simultaneously, if fixing the problem results in APs getting less credits, people will complain. If MBs get more credits, the AP-only people will likely complain because they don't have such an advantage anymore, and in addition to that, other projects may start to complain because the overall RAC for this project will then increase and the others will feel that is unfair, so then they'll make their own tweaks and adjustments to artificially inflate their credit rewards.. and then we're still at a disparity of cobblestone values between projects.

See? In the paragraphs I've just typed, there are at least a dozen problems, and almost nothing positive about credits. There's just no good solution, and that's the troubling thing about this is that it's all supposed to be about the science and that's it. I'm actually kind of starting to understand why Eric and DA don't really seem to want to give any kind of priority or focus toward fixing the credit system, because in the end.. the credits are entirely meaningless and are not useful in any way, shape, or form, as long as good science is getting done. Anyone who understands not only the science, but the programming involved to analyze the science better, should be focusing on precisely those two things--the science, and processing it better.

So.. there's my thoughts on that. Maybe this fits in this thread, maybe it doesn't, but I think it is an entirely valid set of opinions.

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

They realistically serve no purpose at all.

They are an indicator of work done.
It's just a shame that the indicator is so wildly inaccurate.

---

Grant
Darwin NT

...We could probably just abolish the whole credit system and possibly switch over to a measure of FLOPs instead....

Well that's just it, underneath it is using 'Flops. and that's where the insrabilities have been introduced. Whether you issue Credits, cobblestones or schmobblestones, the underlying estimation & control system is the bit that is causing the trouble from my perspective, not the meaningless smiley faces attached to them.

---

"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's probably pretty close IMO Chris, not that I know about all the intricacies either, Lol

---

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

I just want to say that nobody does it just for the points in seti or in Einstein. If you just wanted points you would go to something like collatz and feel like uncle McScrooge counting his moola (for Donald duck fans).

---

merle - vote yes for freedom of speech

As the OP posed the question of relative credits for AP vs. MB, I can offer my own observed data point. Bearing in mind all that has been said about the imprecision of the credits and differences in performance of various hardware and software versions here is what I see (on an Nvidia GTX 650):
AstroPulse, 400 credits per hour
[astropulse_7.08_x86_64-pc-linux-gnu__opencl_nvidia_100]
MultiBeam, 190 credits per hour
[setiathome_x41g_x86_64-pc-linux-gnu-cuda32]

The AP/MB ratio is 2.1:1.

YMMV

---

My 780/980 mixture gets for each GPU little over 2000 points per hour when doing AP. Running two of those at a time.
The MB shorties(ar 2.7) give 43 points every 2 minutes per card so it is 43*60/2 = 1290 pph.
The MB midrange(ar 0.41) gives 100 points every 250s so it is 100*3600/250 = 1440 pph.
The MB is run one at a time.

The results may differ from standard applications.

---

To overcome Heisenbergs:
"You can't always get what you want / but if you try sometimes you just might find / you get what you need." -- Rolling Stones

The MB is run one at a time.

2 at a time would give a nice boost to your output.

---

Grant
Darwin NT