credit per unit dropped a second time

Chris397
Chris397
Joined: 25 Aug 05
Posts: 5
Credit: 1423209
RAC: 0
Topic 191701

In my results list I noticed that the credit per (short) WU dropped from 15.98 to 13.16.
Is there anything wrong with the server? Or was this a planned action?

The first credit drop a couple of days ago (in my case from 19.27 to 15.98, when the new faster apps were released) was understandable for me - to keep the credits per hour on an equal level between the different boinc projects. What is the background for this second drop (when its not an error)?

I'm a bit puzzled...

DanNeely
DanNeely
Joined: 4 Sep 05
Posts: 1364
Credit: 3562358667
RAC: 1580

credit per unit dropped a second time

At a guess the first drop wasn't large enough and project wide RAC spiked, necesitating a second reduction to maintain cross project equivilance.

Crunch3r
Crunch3r
Joined: 22 Jan 05
Posts: 90
Credit: 30237616
RAC: 0

RE: At a guess the first

Message 44167 in response to message 44166

Quote:
At a guess the first drop wasn't large enough and project wide RAC spiked, necesitating a second reduction to maintain cross project equivilance.

Depends on what you call "large enough"... and if this is really what the project needs to go.

Personlally i don't see any reason for the whole cross project calibrating at all.

Reasons:

1. I don't care about other projects...

2. why adjust credits to something common ... i don't do any other projects... and don't care what they do...

3. as long as not all projects use a matching quorum, there's no need to go that way...

4. it's useless

5. i don't do BOINC i do Einstein... not S@H etc... if S@H thinks credits are to high ...why should i care ...

6. if it all depends on boinc( the whole cross project crap) ... well into trash with it and develop an indeppendant app...

tullio
tullio
Joined: 22 Jan 05
Posts: 2118
Credit: 61407735
RAC: 0

Went down again to 13.39 from

Went down again to 13.39 from 16.26 from 19.61 on my Pentium II running SuSE Linux 9.3, BOINC 5.4.9, app.4.16 on a short WU. CPU time remained equal.This just for the record, I am not complaining.
Tullio

DanNeely
DanNeely
Joined: 4 Sep 05
Posts: 1364
Credit: 3562358667
RAC: 1580

That's about the right level

That's about the right level of scaling assuming non sse boxes are a negligable portion of the total cruncherbase at present.

tullio
tullio
Joined: 22 Jan 05
Posts: 2118
Credit: 61407735
RAC: 0

RE: That's about the right

Message 44170 in response to message 44169

Quote:
That's about the right level of scaling assuming non sse boxes are a negligable portion of the total cruncherbase at present.


OK, but people with much faster CPUs are getting exactly the same credit I get. Of course they get it in a shorter CPU time, so their credit/hour rate is higher than mine.
Tullio

Chris397
Chris397
Joined: 25 Aug 05
Posts: 5
Credit: 1423209
RAC: 0

RE: At a guess the first

Message 44171 in response to message 44166

Quote:
At a guess the first drop wasn't large enough and project wide RAC spiked, necesitating a second reduction to maintain cross project equivilance.

This sounds logical to me, thank you.

I am a bit disappointed though. Not about your answer - don't worry :-).

But about the fact that there is no official statement or something similar about this change in the credit system. Or did I miss anything?
I have to read through the forum and "between the lines" to find out what is going on here.
So after successfully optimizing the project clients an optimization of the user information would be very much appreciated :-).

Thank you, Chris397

Matt3223
Matt3223
Joined: 22 Jan 05
Posts: 54
Credit: 448298
RAC: 0

dropping credit granted with

dropping credit granted with a faster app just makes sense to me. The goal of unified credit/hour makes sense too.........regardless if you crunch other individual projects..........all the individual projects are joined under the same system.......BOINC.........to have the credit/hour under that system unified then BOINC appears cleaner, tidier, and a better developed system.

We are one group running different projects within the same management and tracking system.........we aren't isolated completely even if we run just one project. There are different levels one has to look at. Yourself, your project, your team members perhaps, the projects they might run, ........the BOINC system as a whole.

Equalizing BOINC makes sense......there's simply no other way to look at it. whether one likes it or not.

And people won't, the change is difficult, but the end result for the system as a whole is better. I feel arguments against that are not addressing the big picture and are essentially not applicable.

bit like politics eh??........individual wants vs. community wants vs. national wants vs. cultural wants vs. humanities wants.........

just depends on which level one is willing to look at as to which arguments and viewpoints apply.....

ErichZann
ErichZann
Joined: 11 Feb 05
Posts: 120
Credit: 81582
RAC: 0

The problem is that not all

The problem is that not all projects care about that so much....

Matt3223
Matt3223
Joined: 22 Jan 05
Posts: 54
Credit: 448298
RAC: 0

yep...

yep...

Rockhount
Rockhount
Joined: 12 Dec 05
Posts: 12
Credit: 56195921
RAC: 3492

First we crunched Time X für

First we crunched Time X für a WU and get Y Credits. This was the default credit level. Then the optimized (beta) client speed up the chrunching up to 20% and the credit per hour went up with this.
Now we are crunching more data in the same time due to this optimized apps. This means more mips/flops per time?
If yes this increase in Credit is justified against all other projects.
If not why the use of optimized apps is helpfull for the project?
The optimized clients are a step ahead in science, but why we are punished with the decrease in credit?
Then could I use the old client just as well, but what sense make the optimized client at all?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.