That I was getting much better credit/work ratios with my other projects.
Case in point...
A 12,XXX sec calculation in Tanpaku granted me more credit than a Seti unit that was 27,XXX sec. more than double the length.
At first I thought it was a fluke, but even after comparing other time/credit ratio's with my other projects, Seti still came up short on every one of them when I compared similar length (or in most cases a shorter other length) to a Seti length.

I would like to know if this will be addressed...

I have already told the computer I have immediate access to to not get any more work from Seti, and will tell the only other one I have on Seti as soon as I can and switch it to a different project as well.

---

That I was getting much better credit/work ratios with my other projects.
Case in point...
A 12,XXX sec calculation in Tanpaku granted me more credit than a Seti unit that was 27,XXX sec. more than double the length.
At first I thought it was a fluke, but even after comparing other time/credit ratio's with my other projects, Seti still came up short on every one of them when I compared similar length (or in most cases a shorter other length) to a Seti length.

I would like to know if this will be addressed...

I have already told the computer I have immediate access to to not get any more work from Seti, and will tell the only other one I have on Seti as soon as I can and switch it to a different project as well.

Credit was reduced with the introduction of the new MultiBeam application with the expectation that the unequal credits/hr would be corrected by use of a correction factor in each work unit. Some work units claim much more credits per hour than others and this bit of code is supposed to correct for it. However the file containing the correction code was left out of the current application build. When the code is added and after a short time in Beta testing to see that no new bugs are introduced with the code change it will be released here. In the meantime the project has been collecting data on the credits for the various angle ranges to see exactly what correction values are needed to be added to the work units for the various angle ranges.

---

Jim

Some people plan their life out and look back at the wealth they've had.
Others live life day by day and look back at the wealth of experiences and enjoyment they've had.

I haven't followed this topic much for quite some time, but wow! What a bandaid! Correction factors, duration factors, debt factors, etc. It sounds like a house of cards, quite frankly.

Regarding credit, why can't we be "paid" simply more simply? I wish that Buck guy was still around to clarify things on the Wiki for me, and obviously others since this topic still surfaces frequently. Jim-R's explanation is a good start, but is there more meat somewhere?

Jim, nice to see that all this credit-per-hour disparity within Seti is expected to improve shortly. Recently it's been as high as 4.5 to one: about 8400 seconds for a 28-credit unit and about 6,000 seconds for some 90-credit units on my PD950s.

---

Jim, nice to see that all this credit-per-hour disparity within Seti is expected to improve shortly. Recently it's been as high as 4.5 to one: about 8400 seconds for a 28-credit unit and about 6,000 seconds for some 90-credit units on my PD950s.

I have no idea on the actual timetable for this to happen. The problem with the code has been known ever since Eric went on vacation which coincided with the rollout of the Multibeam application. Ever since he has been back he has apparently been swamped with just getting the system to run properly with the new work units. The abundance of the shorter, high angle range work units has caused server and database overloads and he has been working diligently to overcome these obstacles and get the system to run without choking. We in Beta have been promised a new app to test for quite a while but it is apparent that Eric's other commitments to just keeping the system from choking to death have postponed any work on the new application for the moment. It looks like he has just about licked the problems with the system so he might be able to compile a new app for us to test soon (we hope!).

So in short, I would just like to encourage everyone to keep crunching and be patient. Every work unit that is crunched with the system as it is now will give more information on getting the credit issues straightened out. And remember, we have seven times the data to crunch from every minute of recording, so while it may seem you have run into a never-ending supply of the low credit work, it should be balanced by a similar long run of the "sweet" work units which will even out the credit somewhat.

---

Jim

Some people plan their life out and look back at the wealth they've had.
Others live life day by day and look back at the wealth of experiences and enjoyment they've had.

I haven't followed this topic much for quite some time, but wow! What a bandaid! Correction factors, duration factors, debt factors, etc. It sounds like a house of cards, quite frankly.

Regarding credit, why can't we be "paid" simply more simply? I wish that Buck guy was still around to clarify things on the Wiki for me, and obviously others since this topic still surfaces frequently. Jim-R's explanation is a good start, but is there more meat somewhere?

Your response is all about the mechanics of granting credit, and completely ignores the fundamental idea of credit in BOINC.

The definition of a cobblestone is:

The basis for the BOINC credit system is the cobblestone named after Jeff Cobb of SETI@home. The basis of the system is the concept that 100 cobblestones would be claimed for one day of work on a computer with the following specifications:

• 1,000 double-precision MIPS based on the Whetstone benchmark.
  
• 1,000 VAX MIPS based on the Dhrystone benchmark.
  

All of the problems with actually doing this are caused by changes in processor architecture -- the things that make processor 'x' faster than processor 'y' that we also discuss without end.

If a given work unit is "paid" 100 cobblestones, it should take 24 hours on the theoretical benchmark machine above. If your machine does the same WU in 15 minutes, you should get 100 cobblestones for it.

For those who missed it, credit was reduced in 5.27 to bring the stock SETI application in line with the definition of a cobblestone and for no other reason.

If other projects are willing to over-pay to attract people like "boosted" then there is very little that BOINC can do about that.

... and at the same time, if people care more about credit then they can choose projects that over-pay, but would you rather have someone give you $1 or 10 pesos?

---

Credit was reduced with the introduction of the new MultiBeam application with the expectation that the unequal credits/hr would be corrected by use of a correction factor in each work unit. Some work units claim much more credits per hour than others and this bit of code is supposed to correct for it. However the file containing the correction code was left out of the current application build. When the code is added and after a short time in Beta testing to see that no new bugs are introduced with the code change it will be released here. In the meantime the project has been collecting data on the credits for the various angle ranges to see exactly what correction values are needed to be added to the work units for the various angle ranges.

Good answer, but I think the original post was more about cross-project credit.

In my opinion, most projects devote very little thought to making sure their project pays the same as others, or even follows the original definition of a cobblestone.

---

For those who missed it, credit was reduced in 5.27 to bring the stock SETI application in line with the definition of a cobblestone and for no other reason.

Agreed, but my answer was pointing out that adjustments to the credit granting are planned, but just haven't been introduced yet. The present state is that some work units pay much less credits per amount of time spent on them, and others pay much more. When the new application is introduced which uses the per-work unit credit multiplier the playing field should be much more in line with the other projects and not vary as much from work unit to work unit. The original poster *might* have gotten hold of a batch of the low paying work units and gotten a skewed perspective of the credit equality. The project administrators (Eric, Matt and possibly others) are responsible for the credit equasion to insure cross project compatability so I can't say whether the general credit rate will increase, decrease, or stay the same when the per work unit adjustments are made active, but I do know that we will see a lot less variation between work units and a general leveling of the parity between projects. The work units come in "runs" so someone new might receive a bunnch of the low paying wu's and say "SETI pays much less credit per hour than the other projects", while another user might start crunching a bunch of the high paying wu's and say the exact opposite. We just need to wait and see what the situation is when the new application is released, and anyone doing such comparisons now should take the variation in work units into account before saying definately that we either underpay or overpay.

---

Jim

Some people plan their life out and look back at the wealth they've had.
Others live life day by day and look back at the wealth of experiences and enjoyment they've had.

I haven't followed this topic much for quite some time, but wow! What a bandaid! Correction factors, duration factors, debt factors, etc. It sounds like a house of cards, quite frankly.

Regarding credit, why can't we be "paid" simply more simply? I wish that Buck guy was still around to clarify things on the Wiki for me, and obviously others since this topic still surfaces frequently. Jim-R's explanation is a good start, but is there more meat somewhere?

Your response is all about the mechanics of granting credit, and completely ignores the fundamental idea of credit in BOINC.

The definition of a cobblestone is:

The basis for the BOINC credit system is the cobblestone named after Jeff Cobb of SETI@home. The basis of the system is the concept that 100 cobblestones would be claimed for one day of work on a computer with the following specifications:

• 1,000 double-precision MIPS based on the Whetstone benchmark.
  
• 1,000 VAX MIPS based on the Dhrystone benchmark.
  

All of the problems with actually doing this are caused by changes in processor architecture -- the things that make processor 'x' faster than processor 'y' that we also discuss without end.

If a given work unit is "paid" 100 cobblestones, it should take 24 hours on the theoretical benchmark machine above. If your machine does the same WU in 15 minutes, you should get 100 cobblestones for it.

For those who missed it, credit was reduced in 5.27 to bring the stock SETI application in line with the definition of a cobblestone and for no other reason.

If other projects are willing to over-pay to attract people like "boosted" then there is very little that BOINC can do about that.

... and at the same time, if people care more about credit then they can choose projects that over-pay, but would you rather have someone give you $1 or 10 pesos?

Well if it were just one project that was 'over paying' in your terms, that would be one thing. But it is not.
The other 3 projects I run constantly give more credit per work time than Seti.
That says to me that something is wrong with how Seti grants and compares credit time.

I guess I will just continue to stay away from Seti for the time being, for no other reason than I think the other projects that I crunch for does more for the immediate need of humanity than interpret possible radio signals from space.

And yes I do care more than just gaining credit for crunching , but that does not mean I want to crunch numbers for a project that does not give credits either.
(and I did not care for that insinuation from you either)

---

To "nutshell" this as briefly as possible. Seti was the first Boinc project. Boinc set up the "cobblestone" methods as THE Standard used to establish payment for work done. Other projects (protein prediction, etc) came on the scene and used the already established cobblestone method. THEN, because boinc was open source and the benchmark algorithym was housed within the boinc client. Third party optimizers began both optimizing the seti application, and then later the boinc client itself to give more credit. Unfortunately, the third party optimizers didn't do anything to prevent the use of their product on other projects. Rosetta came along and didn't need to run the same wu multiple times to validate the work, so whatever the client claimed is what was paid. The most famous of these boinc CC's claimed 3 times what it should have at other projects (since if it was used at seti and with a corresponding seti app, the claims were only minorly higher than they should have been). So now, we have Third party boinc CC users getting 3X credit at Rosetta and also at Seti for the same time used (although at seti they were actually doing more work/time)(note: the Rosetta project switched to fixed credit just over a year ago,as did Einstein)(Seti switched to flops counting to stop the use of those optimized CC's ). Then even more projects came along and the people said "why should I run your project? I get more at Seti". So some other projects raised the payments to users. Now we're coming full circle and since seti has lowered credits in an effor to achieve parity, users are saying "why should I run seti? I get more at X project". It's all a user driven circle, that has happened over and over ad nauseum.

Oh, and for Tanpaku, last I heard they still allowed these over claiming boinc clients to be used, and that's most likely why you get more at tanpaku.

I haven't followed this topic much for quite some time, but wow! What a bandaid! Correction factors, duration factors, debt factors, etc. It sounds like a house of cards, quite frankly.

Regarding credit, why can't we be "paid" simply more simply? I wish that Buck guy was still around to clarify things on the Wiki for me, and obviously others since this topic still surfaces frequently. Jim-R's explanation is a good start, but is there more meat somewhere?

Your response is all about the mechanics of granting credit, and completely ignores the fundamental idea of credit in BOINC.

The definition of a cobblestone is:

The basis for the BOINC credit system is the cobblestone named after Jeff Cobb of SETI@home. The basis of the system is the concept that 100 cobblestones would be claimed for one day of work on a computer with the following specifications:

• 1,000 double-precision MIPS based on the Whetstone benchmark.
  
• 1,000 VAX MIPS based on the Dhrystone benchmark.
  

All of the problems with actually doing this are caused by changes in processor architecture -- the things that make processor 'x' faster than processor 'y' that we also discuss without end.

If a given work unit is "paid" 100 cobblestones, it should take 24 hours on the theoretical benchmark machine above. If your machine does the same WU in 15 minutes, you should get 100 cobblestones for it.

For those who missed it, credit was reduced in 5.27 to bring the stock SETI application in line with the definition of a cobblestone and for no other reason.

If other projects are willing to over-pay to attract people like "boosted" then there is very little that BOINC can do about that.

... and at the same time, if people care more about credit then they can choose projects that over-pay, but would you rather have someone give you $1 or 10 pesos?

Well if it were just one project that was 'over paying' in your terms, that would be one thing. But it is not.
The other 3 projects I run constantly give more credit per work time than Seti.
That says to me that something is wrong with how Seti grants and compares credit time.

I guess I will just continue to stay away from Seti for the time being, for no other reason than I think the other projects that I crunch for does more for the immediate need of humanity than interpret possible radio signals from space.

And yes I do care more than just gaining credit for crunching , but that does not mean I want to crunch numbers for a project that does not give credits either.
(and I did not care for that insinuation from you either)

Then you missed my point entirely.

SETI has a choice.

• They can hold the line on credit, and work to make sure credit is based on the definition of a cobblestone (1/100'th of a day on a machine with a specific performance level).
  
  
• They can follow the "lead" of projects that over-pay, and they can also grant credit at a higher rate -- triggering another round of inflation when the other projects realize that they're no longer offering a "premium."
  

What you are arguing for is inflation.

It's not like we're actually getting paid: the only thing that credits show is a measure of progress. If the scale changes, then we can't use credits to compare the present with the past.

I'm in full agreement with Jim, the credit "line" should be flat, and it isn't very flat at this time. The "magic" fix is to go back to the relatively inaccurate benchmark * time method and grant the middle credit.

I know you don't like the insinuation that you are just here for the credits, but I read Tanpaku pages, and I can't see what benefit they're trying to achieve, other than develop a way to look at how proteins fold.

I crunch SETI because I'm genuinely interested in the search. I crunched for HashClash because their project was genuinely interesting. I can't get that excited about CPDN (in my opinion there are simply too many variables to get a meaningful result).

I'm not criticizing those who like CPDN, or Tanpaku, but you should be choosing projects based on your personal values, not on granted credit.

If you are interested in SETI, you should crunch SETI. If you aren't, you shouldn't.

---

I like the inflation counter argument. Keep the credit as far and metric-based as possible. Other projects will follow or at least not stray farther. Also, make sure BOINC developers do not create any backdoors or hacks to mislead credit granting (e.g., benchmark tweaks, etc.)

I think i have a ant in my pants and it buggers me.:)......... But don't kick me there to help me

[sarcasme]
Maybe the projects who give to much credit can make a slow official app wich claim lower credit and make it open cource so third party optimized app's can be created to crunch the units faster.
[/sarcasme]

My point is: Seti should not alow third party app's to inflate the output.
And
At the same time compare other official project app's with the official Seti app who's claiming to give a standard credit.

Yes i also run optimized app's and i like them but i think Seti should implement this code in a official app like Einstein@home did.
Or use the Seti optimized app credits to compare between projects.

I think I have an ant in my pants and it bugs me.:)......... But don't kick Me there to help Me.

[sarcasm]
Maybe the projects who give to much credit can make a slow official app which claim lower credit and make it open course so third party optimized apps can be created to crunch the units faster.
[/sarcasm]

My point is: Seti should not allow third party apps to inflate the output.
And
At the same time compare other official project apps with the official Seti app who's claiming to give a standard credit.

Yes I also run optimized apps and I like them but I think Seti should implement this code in a official app like Einstein@home did.
Or use the Seti optimized app credits to compare between projects.

The optimized Seti apps don't inflate anything, WU for WU all they do is do work faster and per WU they claim the same amount of credit as any other would as long as their paired with a Boinc Client that does flop counting(5.2.6 and Newer) and not benchmarking(5.2.5 and earlier claim less per WU than is normal and acceptable).

---

The T1 Trust, PRR T1 Class 4-4-4-4 #5550, 1 of America's First HST's

I think i have a ant in my pants and it buggers me.:)......... But don't kick me there to help me

[sarcasme]
Maybe the projects who give to much credit can make a slow official app wich claim lower credit and make it open cource so third party optimized app's can be created to crunch the units faster.
[/sarcasme]

My point is: Seti should not alow third party app's to inflate the output.
And
At the same time compare other official project app's with the official Seti app who's claiming to give a standard credit.

Yes i also run optimized app's and i like them but i think Seti should implement this code in a official app like Einstein@home did.
Or use the Seti optimized app credits to compare between projects.

Just to clarify.......
1. Seti HAS implemented some of the code which was not platform specific from the various Chicken apps into the current stock app. Which is why the current stock app is much better than the old ones.
2. The 3rd party apps do NOT inflate the output. Credit claims on current optimized apps conform to the credit multipliers that have been specified for the stock app. They simply allow a little more work to be done in a little less time than the stock app. It is really not much different than using a faster computer. The credit claimed for each WU completed is the same.
3. The desire of the Boinc admins is to try to keep as much parity between projects in the terms of credit per unit of cpu time as possible, but they do not control what each individual project does. Seti is the benchmark project, being the most closely tied with Boinc, so they try to set the example for other projects to follow. I am not sure if they have any enforcement power over the other projects that come under the Boinc umbrella to force them to lower their credit awards. There are so many variables involved in what kind of processing the work from other projects involves that it is very hard to bring them all into line, even if Boinc had that inclination or power to enforce.

I am not kicking your ants in the pants, I just wanted to make a few points to consider.

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

I run the latest Boinc crunch program. I have also only used the main Boinc clients.
I do not run,nor endorse these 'optimized' ones that, I do not care what you say inflate numbers.
I 8200 sec work unit takes, 8200 sec. Hense the time frame of the unit. To do it any faster means you are not doing all the work.

Either way I am done here and with Seti.

---

I run the latest Boinc crunch program. I have also only used the main Boinc clients.
I do not run,nor endorse these 'optimized' ones that, I do not care what you say inflate numbers.
I 8200 sec work unit takes, 8200 sec. Hense the time frame of the unit. To do it any faster means you are not doing all the work.

Either way I am done here and with Seti.

Well!!! You just can't argue with logic like that...

*****

F.

---

I run the latest Boinc crunch program. I have also only used the main Boinc clients.
I do not run,nor endorse these 'optimized' ones that, I do not care what you say inflate numbers.
I 8200 sec work unit takes, 8200 sec. Hense the time frame of the unit. To do it any faster means you are not doing all the work.

Either way I am done here and with Seti.

I think you might be a little confused.
There is the BOINC client, which manages the BOINC projects, deciding which project to download and run, when to switch projects etc. It also runs the benchmarks, which never give the same result twice. BOINC does not do any crunching.
There are third party versions of the BOINC client which offer some benefits, some of which may not be so benificial, like report result immediately.
Some also inflate the benchmarks, in an attempt to obtain the correct amount of work downloaded and the claim the correct credits when the project uses the old method of benchmark * time. If used incorrectly this can produce excessive claims, which is what I think you are refering too.

Then there are the projects application(s). For most projects the applications, for whatever reasons are closed source, and therefore for 99.99% of us impossible to optimise.
But Seti's applications, like BOINC, are open source, and therefore if you follow the rules, you can modify, the only problem being the modified code must produce almost exactly the same result, or it will not validate.
If as a modifier of code, you can speed up the process then good for you, as you can do more work in a day and therefore get more credits. It is also good for the Project as more scientific work gets done.
Some of the speed up gained by the users of the modified applications is achieved by using a better compiler, e.g. Intel's expensive one with different libaries, rather than the open source one available to the Seti scientists.
Modified applications are actively encouraged by the Seti staff, because of the speed ups and porting for more platforms.
Also the good working relationship between the optimisers and Seti staff a lot of generic optimisation is now in the 'official' seti application.
Most of the speed up available in the optimised applications now is cpu specific i.e. MMX, SSE2, SSE3 etc. which cannot be put in a generic version. And therefore, if you care to look, are specific to cpu type, e.g. AMD, P4, PM and core2 or 32 and 64 bit versions.

I run the latest Boinc crunch program. I have also only used the main Boinc clients.
I do not run,nor endorse these 'optimized' ones that, I do not care what you say inflate numbers.
I 8200 sec work unit takes, 8200 sec. Hense the time frame of the unit. To do it any faster means you are not doing all the work.

Either way I am done here and with Seti.

Given of course that BOINC does not crunch (at all).

Again, you're advocating the wrong scale.

You have a processor running at 1 GHz. I have the same processor, except mine is running at 3 GHz. You do 8200 seconds of work, and I do the same work unit in 2800 seconds because my machine is three times faster.

I should get the same credit, because you and I have done the same work.

Optimized clients are like faster processors, and the folks who do the optimizations are very, very careful to make sure they return the same results.

A good example: SETI uses a lot of trigonometry, and calculating SIN() or COS() is expensive -- yet the old SETI client took the SIN() or COS() of the same angle over and over. Enough so that one optimization kept a "cache" of answers, and checked the cache (relatively cheap) instead of calculating the same number twice.

Is that cheating?? No, it's taking advantage of a property found in the calculation and the data.

I agree with you when you say that an hour of SETI and an hour of Tanpaku should grant the same credit.

Where we part company is when you say "SETI pays the lowest, so they should fix it." I say, "There is a standard, and every project should follow the documented standard."

The concept is good, the actual implementation is harder.

You claim that in your opinion, SETI won't provide the same benefits to society as the other projects you crunch -- and if you feel that way, you should not crunch SETI. If you don't care about SETI, why bother about valueless credits.

---

I run the latest Boinc crunch program. I have also only used the main Boinc clients.
I do not run,nor endorse these 'optimized' ones that, I do not care what you say inflate numbers.
I 8200 sec work unit takes, 8200 sec. Hense the time frame of the unit. To do it any faster means you are not doing all the work.

Either way I am done here and with Seti.

Sorry to see you go, but the optimized clients do the work faster because they are using mathematical programming code that runs faster on certain cpus, and using coding techniques that take advantage of each processor's built in features. They are doing all of the work, just doing the processing in a manner that allows the cpu to process the data in less time.
If you do not agree, that is fine. And do please consider sticking around and crunching with the rest of us. You are quite welcome here regardless of your opinions!
Regards,
Mark.

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster