We're all in this project, the only place where scores for this project have any meaning.

But the fact is that Seti is a part of BOINC. And one of the points of BOINC is that people are able to compare work done between projects. So if the granting of credits is stuffed, then one of the main points of BOINC is stuffed.

It's an artifact of the version change. Nothing broken.

The very fact that it has occured, and occured with the magnitude it has indicates that it is very, very broken. There have been version changes before, but it has never affected the granting of credits as badly as has happened this time around.

---

Grant
Darwin NT

But the fact is that Seti is a part of BOINC. And one of the points of BOINC is that people are able to compare work done between projects. So if the granting of credits is stuffed, then one of the main points of BOINC is stuffed.

I have been complaining about the credit crunch myself, but this is not exact or complete (to tell the truth, you only say that credit gauging is just one of the points).
The main purpose of BOINC is actually to provide a convenient platform for distributed computing that many projects can use.

Then, giving the same credit for the same amount of work is a nice gig, and I find that the fact that it is not happening is not good, but it is not the main issue.

Sleepy

---

We're all in this project, the only place where scores for this project have any meaning.

But the fact is that Seti is a part of BOINC. And one of the points of BOINC is that people are able to compare work done between projects. So if the granting of credits is stuffed, then one of the main points of BOINC is stuffed.

It's an artifact of the version change. Nothing broken.

The very fact that it has occured, and occured with the magnitude it has indicates that it is very, very broken. There have been version changes before, but it has never affected the granting of credits as badly as has happened this time around.

It simply points out that CreditNew is flawed. Broken. Borked.
In it's inability to cope with a radical change in a project's base processing core.
But, as I stated before......even though it may be a flaw, I have no problem with Boinc not being able to rationalize credit status between projects.
It obviously cannot, when other projects are allowed to hand out credits like they are. Unless Dr. Anderson can reign them in, and force them to use CreditNew, which he shall not, I believe, there shall not ever be any cross project comparison of credit awarding and value.

Again......I do not care. I only run Seti. Credits can be a penny a pound, and my standing amongst other Seti crunchers shall not change.
Gimme 50% of v6. 40%. 10%.
As long as everybody else here gets the same, my status will not change.

And I am just fine with that.

v7 has exposed CreditNew's flabby flanks. It is still trying to recover, and may still adjust a bit as time goes on.

I just don't see it as an issue anymore.

The kitties have moved on. The initial shock has worn off.
The sun is shining brightly on the Seti project.
The servers and the colo are bright spots now.
The bandwidth has never been better.
Time for all of you to give it a rest.


I have.
I suggest all others do the same and just keep crunching.

It's what the project is all about, really.

---

"Time is simply the mechanism that keeps everything from happening all at once."

There are four separate mechanisms at play: the performance of the V7 MB stock apps, the amount of computation in MB V7 workunits, CreditNew, and the fact that AP has not changed.

0. One axiom: RAC matters. If you have robust mental health and laugh off things like this then you would have a hard time caring about CreditNew.

1. The new stock MB apps are closer to the optimized apps in performance than they were before V7.

2. The amount of computation has been increased per MB workunit.

3. CreditNew has been implemented in such a way that credit per MB workunit processed by stock has remained constant.

4. AP processing still generates RAC at the same rate as before.

Point 1. means that either RAC generated by stock had to go up or RAC generated by optimized had to go down. Point 3. caused the latter to occur. Either alternative would have be defensible although increasing RAC for stock would have generated less of a stir.

Both choices can be defended because credit is not directly related to the number of mathematical calculations done on a wu, nor has anyone come up with a practical way to make such a link in the mixed CPU/GPU world. The only question, therefore, is how to do the abstraction. CreditNew is probably just as defensible as anything else, the problem is that it's byzantine. Speaking for myself, I can't get a feel for how it works.

The thing that's indefensible as I see it is the difference in RAC generation between the current versions of optimized MB and AP. MB v7 increased the amount of computation while maintaining (stock) or decreasing (optimized) RAC. AP has not changed.

That means you can now receive a *lot* more credit by processing AP. That's illogical. You will see people (probably with high-performance machinery) vacuuming up all the AP they can just for RAC's sake. That's bound to create hard feelings. And will probably break (or warp) CreditNew which AFAICT relies on unbiased population statistics. Skewed stats = broken CreditNew.

And your point was?

In reference to Seti.

What was your point, exactly?

What does it matter if Seti grants a million credit points or one?

It is simply not an issue anymore.

Let it go.

I respectfully shall request that this thread be closed, as it's original intent has now been fulfilled.

---

"Time is simply the mechanism that keeps everything from happening all at once."

The point which I thought was clear is that people are encouraged to run AP at the expense of MB. This will result in an inequitable distribution of credit. I doubt this outcome was intended by the developers.

I will assume people find credit (and presumably the fair assignment thereof) to be noteworthy if they go so far as to put it in their sig.

Thread has been requested to be closed.

It's time is done.

Please?

---

"Time is simply the mechanism that keeps everything from happening all at once."

I wonder why I'm having so much trouble finding AP wu's to run?

What could be causing that? Hm.

AP queue on the server ran dry and creation of new AP is on the low side. It's finally starting to filling up the queue again but it's still tiny compared to it's "filled" level of 25K (4K right now).

Also if you have MB and AP enabled on your rig, if the server is out of MB, you get AP so there are times when suddenly the AP queue is sucked dry soon after the MB.

When I look at my AP wingmen I've only spied a few that only process AP units and sadly they are also the ones that haven't dialed in for weeks.

I understand what you were trying to say. AP, since the app didn't change, is the only stable app in terms of credits per hour while V7 MB with all the systemic changes that you outlined is in flux and since some among us seem to have tied up some bit of their self into crunching feel hurt with the reduction of their RAC.

But there's nothing to be done about it.

---

"Life is just nature's way of keeping meat fresh." - The Doctor

...

0. One axiom: RAC matters. If you have robust mental health and laugh off things like this then you would have a hard time caring about CreditNew.

1. The new stock MB apps are closer to the optimized apps in performance than they were before V7.

2. The amount of computation has been increased per MB workunit.

3. CreditNew has been implemented in such a way that credit per MB workunit processed by stock has remained constant.

4. AP processing still generates RAC at the same rate as before.

Point 1. means that either RAC generated by stock had to go up or RAC generated by optimized had to go down.

Point 3. caused the latter to occur.

... nor has anyone come up with a practical way to make such a link in the mixed CPU/GPU world. ...

The thing that's indefensible as I see it is the difference in RAC generation between the current versions of optimized MB and AP. MB v7 increased the amount of computation while maintaining (stock) or decreasing (optimized) RAC. AP has not changed.

That means you can now receive a *lot* more credit by processing AP. ...

Thanks for a very good summary!

"Point 0" means a lot of heat generated on the forums. That likely also indicates that a lot of the people on the forums are the ones sensitive about credit/reward/recognition.

"Point 3" means that all the high energy optimised apps crunchers are now knocked back down into the realms of being averaged out with everyone else. Hence the angst?

The skew between MB and AP is bound to be a problem being as the MB application has changed whereas AP hasn't... Yet the credit calculations are changing as the CreditNew system catches up to the sudden stepwise change to the system inputs.


As to what to do?...

Well, the credits are pretty much arbitrary in any case. Hopefully, this event will spur some interest to look at CreditNew anew to allow a more sympathetic response to changes in the Boinc applications and to try to be more consistent in how credit is totaled.


Some time for the near future, I anticipate a huge upset for everyone with CreditNew once a GPU host (or even an APU host) encroaches to become the median machine...

Happy faster crunchin',
Martin

---

See new freedom: Mageia Linux
Take a look for yourself: Linux Format
The Future is what We all make IT (GPLv3)

Well, the credits are pretty much arbitrary in any case.

And that is the problem.
They are meant to be representaive of the amount of work done across projects. They're not.
So the problem needs to be fixed.


BTW- RAC is still falling on my faster system. It seems to have bottomoed out on the slower one.

---

Grant
Darwin NT

I wonder why I'm having so much trouble finding AP wu's to run?

What could be causing that? Hm.

Dunno........I have lots.

---

"Time is simply the mechanism that keeps everything from happening all at once."

My RAC dropped from 13300 (end of May 2013) to about 7100 (15th June 2013) at more or less constant speed.
Then it started increasing again but only at half the speed it was decreasing.
Will watch it carefully!

It seems to stabilize at about 60% of my "old" (13300) value, i.e. at about 8000. So "earnings" are 40% lower than in the good old days!
I'll leave it running like that!