All your views have been heard as I am now getting ZERO credit for my current 6 HOUR work units.... .

Great, one of your results has this : errors Too many success results

That\'s about the weirdest BOINC bug ever - I will better not tell what I\'m currently thinking about the BOINC developer, who invented max_success_results

All your views have been heard as I am now getting ZERO credit for my current 6 HOUR work units.... .

Great, one of your results has this : errors Too many success results

That\'s about the weirdest BOINC bug ever - I will better not tell what I\'m currently thinking about the BOINC developer, who invented max_success_results

Must\'ve been a Liberal Democrat... They tend to like to punish success....

---

Attn: Saenger

You had brought up how it was \"a lie\" that Cosmology has a payout less than WCG. I cannot get into discussing who is right and who is wrong in that argument, but I can tell you that from the perspective of my computer, Cosmology now has a payout of either the same or only slightly better than LHC.

Over there, I have a result that ended up like this (time/claim/grant):

17,894.03 76.52 67.39

You can\'t look at the workunit right now because of a bug they have with their server-side code update. However, that looks very similar to what will end up being the case here...

If one looks at the illustrious chart at BOINC Combined Statistics that David Anderson (and you, via proxy) loves to reference to justify the Great Credit Crusade, this is what you find for LHC:

Horizontal row: SETI@home 1.000 (333425) LHC@Home 1.451 (2156)
Column: LHC@home 0.689 (2156)

So while you think things are \"just right\", from my vantage point, I\'m now contributing to a project that has a payout considerably less than SETI.

Oh, and while I\'m thinking about it, benchmarks are the wrong thing to be focusing on. I was very dense over the past couple of days (lack of sleep will do that), so I wasn\'t comprehending that the benchmarks are going to slide down for the rest of the K7/K8 line as the cpu/mem clock goes down. This is what explains Ananas\' K7 having similar claimed credits to my K8, although my system is obviously faster.

The real metric to look for is cr/hr. My K8 is in the low teens. I would guess that slower K8 systems and K7 systems will be 5-10 cr/hr as far as credits over real cpu time.

This is exactly why these stupid credit parity crusades irritate various users. Your view of \"just right\" means that a great many of us, who are not your \"traditional credit hounds\" get shafted.

---

Sorry to be the one continually posting here, but it\'s my day off, so in lieu of a real life, here I am...

Anyway, that beautiful short-running task is apparently in the midst of being totally offset by a long-running task. Current estimates of the WU I\'m working on now show it at 7 hours. If that holds, claimed credit will be around 105, but only granted 70, for a cr/hr rate of 10, or 33% less than claimed.

---

Sorry to be the one continually posting here, but it\'s my day off, so in lieu of a real life, here I am...

Where do you work, we\'ll see if we can\'t get that day off canceled in the future ... :)

Where do you work, we\'ll see if we can\'t get that day off canceled in the future ... :)

It\'s his only day off for the rest of the month, done so he can show he has a personal life and is able to see his loved ones. That that\'s us is scary, but can\'t be helped. :)

---

{cough}

From Eric J. Korpela:

SETI@home has been granting about 15% more credit per cpu second than comparable projects. Other projects have threatened to increase their own credit multipliers to compensate. The problem is that they all have different ideas about how much credit we should be granting. One project has threatened to give 50% more credit per second than the benchmarks would indicate they should. So to avoid the coming credit war, BOINC is implementing this credit multiplier BOINC wide. This will be an objective way to make sure that projects don\'t grant too much credit. In other words, this will (probably) be happening at most every cpu intensive BOINC project.

Read the rest yourself, just pointing out the obvious. ;-)

{cough 2}

From the same post:

Q. Does this mean SETI@home will grant my machine fewer credits than <other BOINC project>?
A. Probably not. SETI@home currently grants more credit than most other BOINC projects. This multiplier will level the playing field somewhat. When other projects start to use this multiplier, the playing field will be very level.

waits...

---

SETI@home has been granting about 15% more credit per cpu second than comparable projects. Other projects have threatened to increase their own credit multipliers to compensate.

Wasn\'t that the other way around ? DA threatened other projects to manipulate stats ;)

I wonder how long it will be before some of the BOINC Projects tell Dr. A where he can shove the BOINC Platform & go the DC Route ... ???

I wonder how long it will be before some of the BOINC Projects tell Dr. A where he can shove the BOINC Platform & go the DC Route ... ???

They don\'t have to go the DC Route .... it\'s quite simple.
How will they force the projects to update the server software ? They can\'t.

Second thing is a bit harder though... make the participants aware/realize that there\'s no need to upgrade to boinc 6.2.x...

S@H can have it\'s thing and will die peacefully along with arecibos shutdown.
Problem solved.

He says this is to avoid a war? From where i\'m sitting it looks like it just began.
My favorite quote from the article:
\"SETI@home would then \'legitimately\' be able to claim more credit per CPU second than everyone else.\"
Don\'t take that out of context, read the whole post.
However, I think that does gives an interesting insight into the psychology over there. Doublespeak anyone? Where\'s Zeitgeist?

*immediately downgrades all hosts to 5.10.45*

---

I wonder how long it will be before some of the BOINC Projects tell Dr. A where he can shove the BOINC Platform & go the DC Route ... ???

They don\'t have to go the DC Route .... it\'s quite simple.
How will they force the projects to update the server software ? They can\'t.

Second thing is a bit harder though... make the participants aware/realize that there\'s no need to upgrade to boinc 6.2.x...

S@H can have it\'s thing and will die peacefully along with arecibos shutdown.
Problem solved.

There is still the stats sites manipulation threat lets not forget....they seem to have all the bases covered.

---

{cough}

From Eric J. Korpela:

SETI@home has been granting about 15% more credit per cpu second than comparable projects. Other projects have threatened to increase their own credit multipliers to compensate. The problem is that they all have different ideas about how much credit we should be granting. One project has threatened to give 50% more credit per second than the benchmarks would indicate they should. So to avoid the coming credit war, BOINC is implementing this credit multiplier BOINC wide. This will be an objective way to make sure that projects don\'t grant too much credit. In other words, this will (probably) be happening at most every cpu intensive BOINC project.

Read the rest yourself, just pointing out the obvious. ;-)

{cough 2}

From the same post:

Q. Does this mean SETI@home will grant my machine fewer credits than <other BOINC project>?
A. Probably not. SETI@home currently grants more credit than most other BOINC projects. This multiplier will level the playing field somewhat. When other projects start to use this multiplier, the playing field will be very level.

waits...

How about the optimized apps there that allow higher CPCS? How about the fact that people like DA and cohorts like Saenger seem to think that the chart at BOINC Combined Statistics is \"Gospel\", when it is not? How about the fact that my AMD system, one of the fastest single-core systems in use in BOINC, cannot process tasks here fast enough to even be rewarded at approximately benchmark * time level, yet if DA & Co. are to have any say about it, this will drop the credit EVEN MORE?

This is stupid...

---

SETI@home has been granting about 15% more credit per cpu second than comparable projects. Other projects have threatened to increase their own credit multipliers to compensate.

Wasn\'t that the other way around ? DA threatened other projects to manipulate stats ;)

No, he threatened to have the statistics sites manipulate the stats. I sent him an email about it, questioning why as a \"scientist\" he was advocating violating a fundamental principle of the Scientific Method by manipulating the actual data. He declined to answer, instead telling me I \"didn\'t understand\".

It\'s too late to do it tonight, but when I get home tomorrow I\'m pulling my Intel off of SETI and I guess putting it onto Einstein...

:shrug:

---

The 7-hour monster that I thought I had has jumped in processing significantly. There must be a point in the processing where the intensive portion stops. It is now on track to finish in about 5.25 - 5.5 hours...

I\'m off to bed...

---

Over 6,5 hour WUs now on C@h and only 70 CS in credits per unit.

It\'s a lousy credit, Cosmology have always before had very fair credits, but not now ...

I\'m at least taking a break from C@H now ...

---

I will not be getting any additional projects from here. There new improved credits are way to low. What were they thinking???

Yeah, no credit degradation in this project, nope, none indeed...

http://boincstats.com/charts/chart_uk_cosmology_project_new_credits.gif

16% of the recent trend in credits. A six-fold decrease.

Now, let\'s be fair - a couple of possible factors, including longer times to crunch means there is a gap from 2.12 to 2.14. Fair enough. That was a week ago, so we should be moving past that, but in fact we are DECREASING further. Perhaps crunchers are leaving the project? Fair enough - might be due to a lower burn rate per hour, might be due to longer crunch times per WU. Might even be due to the fact that grants are [often] lower than claims.

Look on the bright side here - fewer crunchers for an ALPHA project will result in lower server loads, fewer bottlenecks, etc. etc. etc.

It\'s been fun, but for all the frustration, one thing that make it worth sticking around for was fair credit allocation, maybe even generous to a fault. Yet I, for one, find this project has easily moved down to #3 (or LOWER) on each of my clients\' mix of projects.

Sorry, but the frustration coupled with credit PENALTIES no longer make it worth the kwh for me to invest further.

Rgds
XB

Now, let\'s be fair - a couple of possible factors, including longer times to crunch means there is a gap from 2.12 to 2.14.

What happened is the instant a host completed a wu with lensing enabled, their Duration Correct Factor went through the roof. This is having an effect on the time that BOINC thinks it needs to report to get more work. For my system, I downloaded about 1 days worth, but at an estimated rate of 1-1.5 hours per task. Instead, tasks are taking 4.5-5.5 hours (on average), thus what I downloaded was actually enough for 4-5 days worth. This will also likely cause BOINC to go into \"High Priority\" mode (formerly called Earliest Deadline First) and will likely cause allocation issues with other projects, potentially with various people missing deadlines and not getting credit, as well as the impact here for reissued tasks once the deadlines are exceeeded.

Another thing to watch out for here are those people who are caught up in the \"too many error results\" / \"too many success results\" situations where they received 0 credit. It is entirely possible with the mostly-absent project staff here that those results will purge from the database.

All in all, this was very poorly thought out and very poorly implemented, much like the \"New Deal\" (the new credit proposal from SETI & Co.).

---

Although I do not disagree with you, I would postulate that given sufficient time (say, for laughs and giggles, another seven days) that the graph listed below does not *materially* improve. Then you are back to the big three possible reasons why - crunchers leaving the project, results hung in the pending queue waiting a round or two for a wingman, or the third reason - overall credit grants are materially lower than they should be / need to be.

When the clients in my farm now take 250% ~ 600% of the original time to crunch a WU, but are only granted 140% of the prior credit, this results in a net of 23% to 56% of prior credit. And while I can probably live with 56% consistently across all my clients, I cannot justify 23% - this takes the project (for those particular clients) down to number 4 of 5 projects on the list.

I was with the project when lensing was a part of the work cycle, but even then, my lowly AMD Duo-Core never took 14 hours to complete a workunit! Now, 14 hours for this client is the norm, and not the exception.

This is resource reallocation, plain and simple. If the project felt they had too many crunchers, they would have done themselves a service by saying as much. There are other ways to throttle back the project, than to piss off a lot of people for no good reason.

JMHO, and my $0.03 (increased for inflation, decreased for currency devaluation - but at least not deflated by this project!)

Rgds
XB