I wonder if the great variation in run time for the P4 is due to HT. Since the FPU must be shared between the two threads, the performance of the cosmo task could vary greatly depending on what kind of task is running on the other thread.

I know the feeling. On an H/T you\'ll have quicker runs if two different projects are crunching. When you have the same project crunching on both threads they compete for the same resources at the same time.

---

me@rescam.org

HI All.

Credit is important to me. It is how I keep a record of my contribution to science. My receipt for the donation, if you like. Now if I could just convince the tax man.....

I would love to see consistency in credit calculation across projects. For now that is an \'impossible dream\' and one of the main reasons for this is the inability of the current and proposed schemes to quantify the effects of L2 cache overflow and memory demands. Both of these have a profound effect on credit/hour and neither are taken into account with benchmarking.

On an H/T you\'ll have quicker runs if two different projects are crunching. When you have the same project crunching on both threads they compete for the same resources at the same time.

This also applies to dual core and quad core, with shared L2 cache. I\'ve been studying the effect for a while now and although it is impossible to tell how much this effects \'Cosmology\' work, it can be quantified in some other projects. On SIMAP for example there is little or no effect. On projects like QMC, two Work Units the same can take as much as 210% of \'normal runtime\'.
Different projects can also clash with each other. Again it\'s difficult to tell with C@H, but early indications are that there may be a connection between sharing with QMC, for example, and the progress resetting problems and dll. initialization error which some are experiencing here.

Cheers.

---

Love is the absence of Fear...........Fear is the absence of Love

It\'s sad that just a few people who just can\'t give without receiving something back are driving this never ending debate about nothing. The vast majority of crunchers just don\'t give a damn about credits so just drop the credit system completely and lets get on with the research.

It\'s sad that just a few people who just can\'t give without receiving something back are driving this never ending debate about nothing. The vast majority of crunchers just don\'t give a damn about credits so just drop the credit system completely and lets get on with the research.

Thats a bold claim. I think you\'d be surprised how many people with high output would bail if that happened. The \"majority\" doesnt necessarily outweight the group of people who like the competitive nature of BOINC and consider it as (if not the) driving factor.

Why destroy something that makes both sides happy? The only victim would be science. Fine tuning the system makes more sense than radically change it.

It\'s sad that just a few people who just can\'t give without receiving something back are driving this never ending debate about nothing. The vast majority of crunchers just don\'t give a damn about credits so just drop the credit system completely and lets get on with the research.

Actually, the primary people driving the issue are hard-core \"things must be equal\" types. Sure, that\'s a nice goal, but simply mandating it doesn\'t make it actually \"equal\". For example, look at what just recently happened here, with some people not getting any credit at all for work performed that just happened to get squashed by the server changes. Also, what about the fact that the SETI \"standard\" doesn\'t take into account that you can exceed the \"standard\" by using the optimized clients? How about trying to compare a project like ABC against SETI while using a K6-2? Since ABC is more integer math than floating point, the integer unit in the K6 will handle ABC better than what the floating point will do for SETI, seeing how the FPU in the K6 was very poor...

---

It\'s sad that just a few people who just can\'t give without receiving something back are driving this never ending debate about nothing. The vast majority of crunchers just don\'t give a damn about credits so just drop the credit system completely and lets get on with the research.

Thats a bold claim. I think you\'d be surprised how many people with high output would bail if that happened. The \"majority\" doesnt necessarily outweight the group of people who like the competitive nature of BOINC and consider it as (if not the) driving factor.

I think you would be surprised at how few would bail. The notion that credits drives the whole thing is false doctrine. If it were true then the projects offering high pay would be seeing huge gains in donated CPU cycles. But they\'re not. That tells me the vast majority crunch for some reason other than credits. For the few who can\'t do it without credit, kiss them goodbye and abolish the credits for the credits are total bulls**t. They have been cheated and miscalculated by so many and for so long that they have absolutely no meaning and relevance anymore. They\'re a sad joke at best and they\'ll never be anything more.

Why destroy something that makes both sides happy? The only victim would be science. Fine tuning the system makes more sense than radically change it.

I believe the science is suffering already. And it ain\'t making me happy knowing devs are wasting time on this issue, time that would be better invested in improving other aspects of BOINC, and I bet a lot of other crunchers feel the same way. They can fine tune, radically change or anything in between for another 20 years and it won\'t make any difference. 20 years from now you\'ll be reading the same whines and complaints, nothing will change, because the dream of fair and equitable credits is hopeless. In 20 years you\'ll see. Fortunately, DA already sees that and that\'s why he\'s abandoned the benchmark scheme and is now putting the onus on projects. He\'s washed his hands of it all and is threatening to ask the stats sites to adjust the credits from \"bad\" projects. If the stats sites are ever foolish enough to open that can o\' worms it will explode in their face.

It\'s sad that just a few people who just can\'t give without receiving something back are driving this never ending debate about nothing. The vast majority of crunchers just don\'t give a damn about credits so just drop the credit system completely and lets get on with the research.

Actually, the primary people driving the issue are hard-core \"things must be equal\" types. Sure, that\'s a nice goal, but simply mandating it doesn\'t make it actually \"equal\". For example, look at what just recently happened here, with some people not getting any credit at all for work performed that just happened to get squashed by the server changes. Also, what about the fact that the SETI \"standard\" doesn\'t take into account that you can exceed the \"standard\" by using the optimized clients? How about trying to compare a project like ABC against SETI while using a K6-2? Since ABC is more integer math than floating point, the integer unit in the K6 will handle ABC better than what the floating point will do for SETI, seeing how the FPU in the K6 was very poor...

Good points all. Just a few of the thousands of reasons why it\'s impossible to award credits properly for a thousand different architectures running several different operating systems crunching over 30 different science apps. At the end of 2008 I bet there will 10 more projects each with their own idiosyncracies and hurdles pertaining to credits. A volunteer, non-profit community is going to overcome all that? Not in 20 years. Not in 100 years. You\'ll call me a pessimist today but in 20 years you\'ll know I was a realist with a firm understanding of how big the problem really is and how few resources this community has to throw at the problem. We haven\'t a snowball\'s chance in hell of seeing a good credit system, we need to admit it and waste no more time on it and get on with life and science.

I think you would be surprised at how few would bail. The notion that credits drives the whole thing is false doctrine. If it were true then the projects offering high pay would be seeing huge gains in donated CPU cycles. But they\'re not. That tells me the vast majority crunch for some reason other than credits.

I have pointed out the same thing - that the projects offering higher credits are not seeing huge gains in participants, but that fact seems to get lost in the noise.

However, I disagree that \"the vast majority crunch for some reason other than credits\". I think the better way to phrase that is:

\"The vast majority already crunch a project based on the perceived scientific merit of the project or their own interest in the project, with credits not being that large of a contributing factor in their decision.\"

Fortunately, DA already sees that and that\'s why he\'s abandoned the benchmark scheme and is now putting the onus on projects. He\'s washed his hands of it all and is threatening to ask the stats sites to adjust the credits from \"bad\" projects. If the stats sites are ever foolish enough to open that can o\' worms it will explode in their face.

Asking people to manipulate factual data goes against the fundamental principles of the Scientific Method. I would hope that the stats sites\' owners will be strong enough to stand their ground and state that they are only reporting the facts.

---

This discussion has been beaten to death on every distributed
computing project I have participated in. The trick is stop
counting the angels on the head of this pin, and concentrate
on paying your electric bill. If the bill is just right, build
another rig.

Voltron

---

If you don't build them, you can't sweat them. Got Stock?

Surely the easiest way is to drop the bottom line.
Let projects pay whatever they want, keep the stats for people to compare with each other in any project, and get rid of [in my case]
190,000 610 41,706 96.567%
I\'d prefer a nice certificate anyway.

---

Hi,
Only new to C@H.How long does it take to have the credits verified ? I have completed some WU over the last two weeks but have not had any verified.

Cheers

Hi,
Only new to C@H.How long does it take to have the credits verified ? I have completed some WU over the last two weeks but have not had any verified.

Cheers

Hi DARYL- As soon as a wingman returns a successful result you will receive credit...of the 3 results returned 2 wingmen haven\'t returned anything yet before the deadline and one failed to meet the deadline, was re-issued to a new wingman and he gets 10 days from that point.

Hi,
Only new to C@H.How long does it take to have the credits verified ? I have completed some WU over the last two weeks but have not had any verified.

Cheers

Hi DARYL- As soon as a wingman returns a successful result you will receive credit...of the 3 results returned 2 wingmen haven\'t returned anything yet before the deadline and one failed to meet the deadline, was re-issued to a new wingman and he gets 10 days from that point.

Thanks heaps for your reply.

There is a problem in BOINC (and thus in BOINCstats) :

BOINC does not measure the system time that a process produces.

That means that an application producing a high system load reports a too low CPU time to the core client.

Camb does produce a very high system load caused by a problem with the checkpoints. So if you compare credits per CPU second between different projects, you have to factor in the additional CPU time spent on system level.

You can see how much it is watching the CPU time increment per minute on the wall clock.

I have set BOINCview to query all boxes every minute and casp often increases the CPU time only by 40 seconds per minute.

So overall, the credits here are not necessarily higher than in projects like SETI or Einstein, imo. they keep about the same level.

It depends a bit on the number of Cosmology tasks running, the system load share increases if there are more Cosmo tasks, if there\'s only one Cosmo task running together with different projects the effect is not that high.

The drop from 100 to 80 credits sounds like it is
political and not in the best interest of the data that is being processed. The admins of this project should not bend to the political pressures of other projects as to the amount of credits assigned to a work unit and make a just and real assignment for the credit per work unit processed based on the information returned. I would like to see the amount of data processed vs the credit assigned to the work unit. On a floating type of credits per work unit as per SETI would make more sense than just giving a credit for a work unit processed.

The drop from 100 to 80 credits sounds like it is
political and not in the best interest of the data that is being processed. The admins of this project should not bend to the political pressures of other projects as to the amount of credits assigned to a work unit and make a just and real assignment for the credit per work unit processed based on the information returned. I would like to see the amount of data processed vs the credit assigned to the work unit. On a floating type of credits per work unit as per SETI would make more sense than just giving a credit for a work unit processed.

I think to \"keep the peace\", this was not a bad move. The better move would\'ve been what I suggested, which was to revert back to version 2.05 across the board. From there, the project could\'ve done a real job of testing the changes since 2.05 in both the application and the work generator.

On the whole, as I have said recently elsewhere, the current credit system is so messed up that it is pointless to try to make corrections to the current system if the main framework remains mostly unaltered. IMO, the current credit system should be phased out and replaced with one that does give equal credit across projects.

The only somewhat reasonable objection I\'ve heard to cross-project parity is what Kevin (zeitgeistmovie) brought up about QMC; that his systems run hotter / consume more power doing QMC work. That could however be because of a poor coding implementation that needs addressing and once it is addressed the power usage / heat generation would drop.

---

The admins of this project should not bend to the political pressures of other projects as to the amount of credits assigned to a work unit

WoW, your first Post and you got it totally wrong, but your entitled to your opinion as is every one else. If you knew anything about this project @ all you would know that it has always given an exceptional amount of credit, to much in fact most of the time.

The reason for the Credit reduction is because the Wu\'s at the moment are only about 1/4 to 1/3 in length that they were, thus the credit reduction ... :)

The admins of this project should not bend to the political pressures of other projects as to the amount of credits assigned to a work unit

WoW, your first Post and you got it totally wrong, but your entitled to your opinion as is every one else. If you knew anything about this project @ all you would know that it has always given an exceptional amount of credit, to much in fact most of the time.

The reason for the Credit reduction is because the Wu\'s at the moment are only about 1/4 to 1/3 in length that they were, thus the credit reduction ... :)

I do not think so, when SETI went from the old to the new (boinc) there was a lot of changes that happened with the credits. I know as I had 4 machines crunching for SETI at that time. I have been crunching many projects and the only time that I have seen a drop in the credits is under political pressure. The admins of any project should allow the correct credits per work unit based on the time to crunch that work unit, the information coming back from a validated work unit, and the type of information vs the number of machines crunching that work unit. If a work unit takes 3 machines to have a validated result vs 2 machines or 1 machine (there are projects in alpha or beta that 1 machine is validated) should not that machine be allowed the full amount of credits as long as the result is validated? It is up to the admin of the project and only the admin as to the credit per work unit allowed. Most alpha projects allow a higher credit vs beta projects vs production projects due to the unknown factor for the application, the result return, and the validation of the result. I have a CPDN work unit that has been crunching for 45 days now, I do not care what the credit is going to be just as long as it is fair based on the time to crunch that work unit, but if I go looking at other work units that the time vs validation does not make sense I will be online asking what is going on.

I have been crunching many projects and the only time that I have seen a drop in the credits is under political pressure.

So what your saying is even if the WU Length drops to just 5 min\'s long that we still should get 100 Credits Per WU or the Project is bending to Pressure if they lower the Credits, that sounds good to me ... :)

The admins of any project should allow the correct credits per work unit based on the time to crunch that work unit

Hellooooooooooo, what do you think they are doing by dropping the Credit some, the WU Length dropped so they finally dropped the Credit to reflect that ... :)

My Kid Friendly, non obscene, none sexual explicit or suggestive post...

seriously when will i be able to fetch work when i want to? since weeks i have serious problems getting work from cosmo. Which directly affect my credits, i don\'t care how much we get, i just care that i can get work. I had a quadcore, dual core, and some more bits running dedicated on cosmo@home, now i had to divert my idle cpu time to other projects i\'m not even interested in.

Could you please make a statement on the announcement/front page when WU\'s will be issued as like 2 months ago, when i could download all the WU\'s i needed?

Sorry if this is already answered, but i\'m really unhappy, trying to do a good thing, but the good thing seems to have broken down, and i don\'t have the energy to browse through the forum.

I strongly hope that i can start crunching cosmo wu\'s soon again like before, just with 50% less credit, but that is not important. I just want to crunch crunch and crunch some more :)