YoDude9999
07-22-11, 02:06 AM
I'll submit my personal opinion on this topic.....
What I see as the problem with the credit situation is that, there is no standard for any project to work from as far as how much credit should be awarded per work unit.
If a standard was implemented, then things would be even across all projects. As an example I would suggest that CPU and GPU crunching still be separated from each other. The reason is because there are so many different versions of CPUs and likewise so many different versions of GPUs available to the consumer that attempting to pool them all together into a single credit system seems impractical. The types of work units being different from each other gives good reason to keep them separated.
With this thought in mind, let us look into a standard that could be implemented for both type of crunching processors. I'll begin by starting with CPU work units as the example of a standard.
If say, there was a standard stating that all CPU work units, for all projects, can allot "X" amount of credit per work and the duration of the work unit must meet a standard in expected duration, then every project would be equal in the amount of credit that could allotted per work unit.
For instance, BOINC sets a standard that all projects are assigned an amount of 2500 credits (just as a number in our example) per work unit. This means that any work unit for any project gives the same amount of credit for any single work unit completed and validated. This in itself (partially) makes things even across the BOINC community but because the various project's work units are in various lengths of duration for completion, the time variable exists.
What this means is that if Aqua gives out work units that take a specific CPU 30 minutes to complete and SETI gives out work units that only take 15 minutes using the same CPU to complete, then, everyone will flock over to SETI because they are essentially giving out twice the credit for the same amount of time it takes to complete the one work unit. Obviously, setting only the amount of credit per task such that all projects give the same credit for every task done does not solve the problem.
If however, the various different projects were to adhere to a specific amount of expected time it takes to complete a work unit, then things would even up quite nicely for everyone.
So now if we look into this a bit more closely, by saying (for instance) that all work units for every project should be completed in a timely fashion, say 1 hour (just as number), then this brings all projects to the same playing field.
All project CPU work units give out 2500 credits and are expected to be completed in 1 hour. This means every project has the exact same potential for granting credit as any other. Suddenly, no matter what project you crunch for, the credit potential is the same. This would eliminate, "project preference" as we see it now, as in the fact that project "X" work units will no longer draw more crunchers to it simply because project "X" gives out more credits than project "Y". This would be a good thing indeed as now crunchers could crunch any project they see fit and would still be granted the same credit. Finally, no more favoritism over projects based solely on the amount of credit granted by an individual project but rather equal credit over all projects.
Now, we have to entertain another standard. Because of the competitive nature of people and the challenges we so love, being on teams and joining in on rallies, etc., having all the projects giving out the same credit per work unit and expecting the work unit to be completed within the specific amount of time, introduces yet another problem.
How does one gauge the actual amount of credit that should be awarded to crunchers that don't meet the expectations of the time frame of the work unit the project gives out?
In the suggestion of equal credit for every work unit (no matter the project), a standard could be implemented that states that from the total allotment of credit being completed (2500 credits in our example) during the expected time frame of one hour, 2500 credits are awarded. If a time verses credit multiplier was implemented, it should degrade the amount of credit awarded to crunchers that do not complete the work unit at the expected time, yet still grant a fair amount of credit to those that participate.
In simple terms, you are allotted 2500 credits for a work unit. If you complete the work unit in one hour, you get the allowed 2500 credits. If it takes you twice as long to complete the work unit as expected, you only get half the credit for it. If you have a slow cruncher and it takes you four times longer, then you get only one quarter the allotted amount of credit. On the other hand, if a cruncher completes the same task faster than the expected time (due to over clocking), the multiplier should grant credit, in proportion to the set standard, over the credit allotment given to the work unit.
This provides a means to keep the projects competitive in nature for the people that have very fast crunching abilities verses those that don't. If it turns out that a cruncher is awarded zero credits for a work unit, then they should upgrade their hardware, simple as that.
To come up with the standard for a credit multiplier based on the example I've given here, it could (and should) be done by an entity that can provide the best single CPU core available to the consumer. What I mean by single CPU core is, the best multi-core processors that are available. A work unit would be crunched by a single core of the processor running at stock clock speed. (Perhaps several work units and an average taken might be better.) From that, would become the standard for the multiplier of how well and how much credit should be awarded to the cruncher.
With these three standards implemented, I believe the credit issue could finally be put to rest. It might not be an easy thing to implement. DA and the BOINC people would have to abide by it as would the projects, but over all, I believe it could make the BOINC community a much happier place than it is now.
The same idea could be applied to GPU crunching with a different set of standards implemented.
All in all, it would take both DA, the BOINC team and the cooperation of all the projects in order to achieve such a goal. Projects would have to restructure their work units to fit within the set parameters. DA would have to quit screwing around all the time and just think, maybe he could actually take a vacation for a while and not have to fret over is so much and just let things roll along smoothly for a while if these simple standards were put into effect.
I don't know if it's even possible at all. I would tend to think however, that if everyone would take a step back and look at this proposal, perhaps something good could come of it?
Yo-
What I see as the problem with the credit situation is that, there is no standard for any project to work from as far as how much credit should be awarded per work unit.
If a standard was implemented, then things would be even across all projects. As an example I would suggest that CPU and GPU crunching still be separated from each other. The reason is because there are so many different versions of CPUs and likewise so many different versions of GPUs available to the consumer that attempting to pool them all together into a single credit system seems impractical. The types of work units being different from each other gives good reason to keep them separated.
With this thought in mind, let us look into a standard that could be implemented for both type of crunching processors. I'll begin by starting with CPU work units as the example of a standard.
If say, there was a standard stating that all CPU work units, for all projects, can allot "X" amount of credit per work and the duration of the work unit must meet a standard in expected duration, then every project would be equal in the amount of credit that could allotted per work unit.
For instance, BOINC sets a standard that all projects are assigned an amount of 2500 credits (just as a number in our example) per work unit. This means that any work unit for any project gives the same amount of credit for any single work unit completed and validated. This in itself (partially) makes things even across the BOINC community but because the various project's work units are in various lengths of duration for completion, the time variable exists.
What this means is that if Aqua gives out work units that take a specific CPU 30 minutes to complete and SETI gives out work units that only take 15 minutes using the same CPU to complete, then, everyone will flock over to SETI because they are essentially giving out twice the credit for the same amount of time it takes to complete the one work unit. Obviously, setting only the amount of credit per task such that all projects give the same credit for every task done does not solve the problem.
If however, the various different projects were to adhere to a specific amount of expected time it takes to complete a work unit, then things would even up quite nicely for everyone.
So now if we look into this a bit more closely, by saying (for instance) that all work units for every project should be completed in a timely fashion, say 1 hour (just as number), then this brings all projects to the same playing field.
All project CPU work units give out 2500 credits and are expected to be completed in 1 hour. This means every project has the exact same potential for granting credit as any other. Suddenly, no matter what project you crunch for, the credit potential is the same. This would eliminate, "project preference" as we see it now, as in the fact that project "X" work units will no longer draw more crunchers to it simply because project "X" gives out more credits than project "Y". This would be a good thing indeed as now crunchers could crunch any project they see fit and would still be granted the same credit. Finally, no more favoritism over projects based solely on the amount of credit granted by an individual project but rather equal credit over all projects.
Now, we have to entertain another standard. Because of the competitive nature of people and the challenges we so love, being on teams and joining in on rallies, etc., having all the projects giving out the same credit per work unit and expecting the work unit to be completed within the specific amount of time, introduces yet another problem.
How does one gauge the actual amount of credit that should be awarded to crunchers that don't meet the expectations of the time frame of the work unit the project gives out?
In the suggestion of equal credit for every work unit (no matter the project), a standard could be implemented that states that from the total allotment of credit being completed (2500 credits in our example) during the expected time frame of one hour, 2500 credits are awarded. If a time verses credit multiplier was implemented, it should degrade the amount of credit awarded to crunchers that do not complete the work unit at the expected time, yet still grant a fair amount of credit to those that participate.
In simple terms, you are allotted 2500 credits for a work unit. If you complete the work unit in one hour, you get the allowed 2500 credits. If it takes you twice as long to complete the work unit as expected, you only get half the credit for it. If you have a slow cruncher and it takes you four times longer, then you get only one quarter the allotted amount of credit. On the other hand, if a cruncher completes the same task faster than the expected time (due to over clocking), the multiplier should grant credit, in proportion to the set standard, over the credit allotment given to the work unit.
This provides a means to keep the projects competitive in nature for the people that have very fast crunching abilities verses those that don't. If it turns out that a cruncher is awarded zero credits for a work unit, then they should upgrade their hardware, simple as that.
To come up with the standard for a credit multiplier based on the example I've given here, it could (and should) be done by an entity that can provide the best single CPU core available to the consumer. What I mean by single CPU core is, the best multi-core processors that are available. A work unit would be crunched by a single core of the processor running at stock clock speed. (Perhaps several work units and an average taken might be better.) From that, would become the standard for the multiplier of how well and how much credit should be awarded to the cruncher.
With these three standards implemented, I believe the credit issue could finally be put to rest. It might not be an easy thing to implement. DA and the BOINC people would have to abide by it as would the projects, but over all, I believe it could make the BOINC community a much happier place than it is now.
The same idea could be applied to GPU crunching with a different set of standards implemented.
All in all, it would take both DA, the BOINC team and the cooperation of all the projects in order to achieve such a goal. Projects would have to restructure their work units to fit within the set parameters. DA would have to quit screwing around all the time and just think, maybe he could actually take a vacation for a while and not have to fret over is so much and just let things roll along smoothly for a while if these simple standards were put into effect.
I don't know if it's even possible at all. I would tend to think however, that if everyone would take a step back and look at this proposal, perhaps something good could come of it?
Yo-