It's been a while again. One of my new year's resolutions is to post more frequently. A lot has happened since the last time I posted. The winter funding drive, working on the version 6.0 SETI@home application (which is in beta with few problems), continued work on adding the database structures to support the NTPCKR, etc. I went to a depressing American Astronomical Society conference in Austin (depressing because of the NASA and NSF funding situations) where I picked up a nasty flu which had me laid out for a week, and from which my lungs are still recovering. And the information cascade failure we call the U.S. presidential primary system has begun. To top it all off, last weekend one of our cats died. But, by request, I'm going to talk about something else entirely. This is also going to be long-winded. There's a lot of back-story and more issues than can really be fully explored, but I want to get it all down somewhere accessible.

There was a bit of a uproar in the last couple weeks about BOINC credit system and possible changes to it. It's not the first time, and it won't be the last time it comes up. And every time it comes up, there will be people who get angry because they feel the change will be bad for them.

The BOINC credit system is a sort of artificial economic system. I'm not an economist, and I've never taken a class on economics, so I know very little about economic systems. So I may get some details of this wrong.

In the BOINC credit system, credits take the place of money. Projects pay you for your CPU time in credits, and with your credits, you buy bragging rights or ranking in a list. It seems somewhat odd to me, but there are people who run BOINC only for the purpose of earning credits and who will change projects to maximize their earnings.

In an ideal world, a BOINC credit would be equal to a fixed amount of work actually done. This would be the equivalent of the Gold standard, where the supply of money is fixed by the amount of gold. In this case the amount of BOINC credit is set by the amount of work that the machines running BOINC do. But of course the world isn't ideal. It's actually very difficult to measure the actual amount of work done by an application program. It's also difficult to define exactly what work is. On the other hand it's fairly easy for the BOINC application to approximate the maximum amount of work that a processor is capable of doing.

So when BOINC started, the general means of granting credit was to multiply the measurement of maximum work capability time the CPU time used. This has several problems... Different versions of BOINC give different estimates of maximum work capability and processors have different efficiencies. That means that different machines would claim different amounts of credit for the same amount of work. That's the equivalent of using gold coins with an unknown percentage of gold in them. The other problem is that some people use applications optimized for their specific processor, which can be much faster than a generalized application. These machines would ask for less credit than they were owed. It led to a lot of complaints about people being granted too much or too little credit.

There was also a problem when we released updated, more highly optimized applications. Run times decreased and therefore granted credits decreased for the same amount of work. For people running the stock application, this was hardly noticed, since they got roughly the same amount of credit per day. People running optimized applications which had been 8X as fast as the generic stock application were now only running applications that were 2X or 3X as fast as the stock application. Their rate of credit accumulation went down because of it and some of them got angry and left the project. Let that sink in... Some people left the project because the project had become more efficient. In economic terms, optimizing the stock application when granting credit based upon CPU time is deflationary. Less credit is granted for the same amount of work. Deflation is considered a "bad thing" for multiple reasons.

So we modified the application to grant a specific amount of credit for each floating point operation in the application, essentially moving back toward the gold standard. To keep the rate of granted credit roughly constant for the same machine, we instituted a multiplier that would set the number of credits each floating point operation generated. That was released without much problem, aside from some complaints from people whose rates went down by 10 to 20%. There were as many people whose rates went up by 10 to 20%, but they didn't complain.

But more optimizations were incorporated into the application. At first, in the beta project, we didn't change the credit multiplier. That made the rate at which credits were being granted go up. I started to see complaints from other projects, and users that ran multiple projects that the SETI beta was granting more credit per day than other projects on the same machine. When granting constant credit per unit work, optimizing the application is inflationary. If something wasn't done, other projects would start increasing the amount of credit they granted to match.

An even worse possibility is that projects would start increasing the amount of credit they grant as a means of attracting crunchers. In this case the "money supply" is not fixed by any mechanism. There is nothing that physically prevents a project from granting 10X, 100X, or a million times as much credit per CPU second as SETI@home does. To combat this potential for hyper-inflation, there is an unwritten agreement among BOINC projects that we will strive to achieve credit parity. That is to say, a specific machine should generate the same number of credits per day whether it runs SETI@home, Einstein@home, or Rosetta@home. That allows volunteers to base their decisions of which projects to support based upon the goals of the project, rather than the amount of credit they grant.

Of course this isn't perfect either. Every time we release a new version of SETI@home, we need to adjust the credit multiplier. That takes quite a bit of work, and even then it isn't perfect. Right now SETI@home is granting 10 to 15% more credit than it should. The credit granted per CPU time also varies depending upon the details of the work unit. Neither of these problems will be solved before SETI@home version 6 is released. Maybe not even then. It would be nice if there were some sort of automation for determining the credit multiplier on the fly.

A couple weeks ago, David posted a message to the boinc_projects mailing list requesting that projects normalize the amount of credit they grant to SETI@home. Some of the projects were granting 75% of the credit SETI@home does. Others were granting up to 3 times as much credit as SETI@home does. Since new BOINC projects come along all of the time, the managers of these projects may not have been aware of the informal agreement to maintain credit parity. It appears that most, if not all projects, will do so. I think all of the project managers understand the potential for credit inflation, and understand that it would be damaging to the projects and to BOINC overall. Some people, especially those that had migrated to high credit projects in order to maximize the number of credits they earn, felt that David's request was an unwarranted ultimatum intended to coerce projects into compliance. While I understand that David could have used more diplomatic language, I don't think that the message was an ultimatum, because David really doesn't hold enough power to drive compliance.

I ask those that have complained that previously high credit projects will reduce their credit multipliers to understand that BOINC credits have value because they represent an amount of work that can be compared. Credit inflation destroys that value. If I were to raise the SETI@home credit multiplier by a factor of 10, the credits you have earned so far will lose 90% of their value. Someone could earn the same number of credits in a tenth of the time. Other BOINC projects would probably be forced to raise their credit multipliers, in order to retain the "I crunch for credit" crowd. Of course some projects will attempt to retaliate against SETI@home by increasing theirs by a factor of 20. Very soon after that, BOINC credits would lose all value and meaning. Cross project comparisons become impossible.

Shortly after his first message, David released a credit proposal that would address some of these issues. Like all proposals, it has good features and it has bad features. I doubt that it will be implemented in anything close to its present form. The essence of the proposal is "In any project, the average machine should receive 100 credits per day if it participates full time."

There are some benefits to this proposal. First, a project can determine its credit multiplier without referencing other projects. All that needs to be done is to figure out how many credits per day the average machine gets and adjust the multiplier higher or lower to achieve 100. This could even be automated in the BOINC server software. That's less work for me to do manually, so I'm all for that.

The proposed scheme contains incentive to work on non-competing projects as they become available. For example an average machine could earn 100 credits per day running a CPU intensive project like SETI@home, while simultaneously earning 100 credits per day running a storage project, and 100 credits per day running a network intensive project.

There are also some fairly major drawbacks, and that is why I think it won't be implemented as is. First, it's immediately deflationary. The average host that connected to SETI@home today earns 292 credits per day, which is significantly more than 100. There would be strong (perhaps irresistible) demand for projects to keep their current credit scheme for as long as possible.

Second, it's deflationary over time. If Moore's law holds, the average host a year from now will earn 470 credits per day. So under the proposed credit scheme a host that earns 100 credits per day today would earn about 62 credits per day a year from now. It violates the idea that was implicit in earlier credit schemes, equal credit for equal work.

But in order to have an better scheme implemented, its incumbent upon the projects, and therefore me, to propose something that has the same benefits without the drawbacks. I'm thinking about it now. Ideas are welcomed.

EDIT: I forgot to include number of processors in my average credit per day calculation. The average host currently earns 535 credits per day not 292. The average host has 1.65 processors.

---

@SETIEric@qoto.org (Mastodon)

oh mi lord - well as far as i can tell - you've explained things quite 'clearly'

and it's much appreciated that you've gone to certain parameters to do so Sir

Thank You for said explanation Eric . . .


Respectfully,

richard

---

BOINC Wiki . . .

Science Status Page . . .

The average host has 1.65 processors.

I think that's dead-on for a H/T. :) Thanks for all the info!

---

me@rescam.org

The average host has 1.65 processors.

Ok, Lets all buy fractions of a processor so we can be "average"!

"I is strange. It is fun!"

... There was a bit of a uproar in the last couple weeks about BOINC credit system and possible changes to it. It's not the first time, and it won't be the last time it comes up. ...

The BOINC credit system is a sort of artificial economic system. ...

In an ideal world, a BOINC credit would be equal to a fixed amount of work actually done. This would be the equivalent of the Gold standard, where the supply of money is fixed by the amount of gold. ...

Very good apt summary.

The proposed scheme contains incentive to work on non-competing projects as they become available. For example an average machine could earn 100 credits per day running a CPU intensive project like SETI@home, while simultaneously earning 100 credits per day running a storage project, and 100 credits per day running a network intensive project.

I think that is an excellent idea, and long overdue for acknowledging the CPU/FPU/IO/HDD/Network performance differences between the very different systems contributing resources to BOINC.

There are also some fairly major drawbacks, and that is why I think it won't be implemented as is. First, it's immediately deflationary. The average host that connected to SETI@home today earns 292 credits per day, which is significantly more than 100. There would be strong (perhaps irresistible) demand for projects to keep their current credit scheme for as long as possible.

Second, it's deflationary over time. If Moore's law holds, the average host a year from now will earn 470 credits per day. So under the proposed credit scheme a host that earns 100 credits per day today would earn about 62 credits per day a year from now. It violates the idea that was implicit in earlier credit schemes, equal credit for equal work.

But in order to have an better scheme implemented, its incumbent upon the projects, and therefore me, to propose something that has the same benefits without the drawbacks. I'm thinking about it now. Ideas are welcomed. ...

This has been discussed at extreme length previously. Many pages of words were generated, passions raised, yet not enough interest to implement a system... At the time, the 'credits problem' wasn't a big enough problem and the counting fp-ops was a good enough quick fix which is indeed working well enough for now.


The "gold" standard works well enough for economics and also for science alike.

One idea is to avoid the theoretical turgidness of trying to model or count up what resources BOINC uses. Instead, why not directly (and continuously) measure what actually happens in the project to then calibrate against a live 'gold standard'?

The 'gold standard' could be a dedicated lab machine. Or it could be some statistical average of all current active machines (but adjusted to avoid deflation due to Moore's Rule).

All users' machines in BOINC get calibrated against the 'gold standard' for each WU or for at least a regular sample of WUs. The calibration is done serverside during the quorum checks, and is propagated similarly to the way NIST calibration standards are propagated. That is, the calibration is made whilst doing useful real work. No 'dummy' or 'test' WUs are used.

In this way, the calibration can be a multiplier against the fp-ops count or against CPU + IO time even.

Note that the WUs used for calibration are normal WUs, and that a host is calibrated for running that type of WU. There then is to be a calibration path through the project database (possibly via multiple other machines/WUs) back via other calibrated hosts/machines to one of the WUs calibrated directly against the 'gold standard'.

For this to work with no extra calibration WU overhead, a BOINC project must have a quorum of two or more to allow the calibrations comparisons to propagate. Projects with a quorum of only one will suffer an overhead (small) for running a proportion of redundant WUs for calibration.


The coding required: Alongside the WU credit score, also required will be a calibration factor, calibration hierarchy level, and possibly a link to trace back to the 'gold standard' for that WU for checks/documentation.

Just one idea, but one that won out in past discussions on and off the forums as being the most flexible and effective yet easy enough to implement.

Regards,
Martin

---

See new freedom: Mageia Linux
Take a look for yourself: Linux Format
The Future is what We all make IT (GPLv3)

There was a bit of a uproar in the last couple weeks about BOINC credit system and possible changes to it. It's not the first time, and it won't be the last time it comes up. And every time it comes up, there will be people who get angry because they feel the change will be bad for them.

...

A couple weeks ago, David posted a message to the boinc_projects mailing list requesting that projects normalize the amount of credit they grant to SETI@home. Some of the projects were granting 75% of the credit SETI@home does. Others were granting up to 3 times as much credit as SETI@home does. Since new BOINC projects come along all of the time, the managers of these projects may not have been aware of the informal agreement to maintain credit parity. It appears that most, if not all projects, will do so. I think all of the project managers understand the potential for credit inflation, and understand that it would be damaging to the projects and to BOINC overall. Some people, especially those that had migrated to high credit projects in order to maximize the number of credits they earn, felt that David's request was an unwarranted ultimatum intended to coerce projects into compliance. While I understand that David could have used more diplomatic language, I don't think that the message was an ultimatum, because David really doesn't hold enough power to drive compliance.

I'm not angry because I feel the change would be "bad" for me. I'm not even really "angry", per se. I reacted strongly to the wording of David's message. I find it very troubling that he would even consider asking the factual data to be manipulated at the stats sites. That, at least to me, seems to go against the foundation of the Scientific Method. I asked him in email to clarify and retract that statement if it wasn't what he meant. After 2 emails that danced around the issue, I asked point-blank. I never received a reply...

Anyway, the notion of equivalent credit per cpu second is a good notion. However it takes more work than just stating that Project X is the baseline and you must rig your credits to be 0.8X - 1.2X the value of Project X. All you're doing is rigging credits. You're not addressing the performance of a processor on various projects, like how some projects appear to use more L2 cache than others.

Additionally, Cosmology, one of the "bad" projects (per David), is in Beta. They just had a situation where they tried to run a script to grant credit when, IMO, they should've just invalidated all work and dealt with people that complained stating it was a risk of running a beta project. However, the script was run and it made a mess. Some people received more credit than what they were supposed to, others received less, and some people received nothing.

Another interesting aspect is that since the science application here is Open Source, people have been free to work on optimizations, including processor architecture optimizations. Other projects do not have open source applications nor do they have resources to put into optimization. As such, one likely outcome of mandating SETI as the standard will mean that those who you "fear" that run to projects on the amount of credits granted would realize that cr/sec would be higher than the "1.0" baseline if one were to use the optimized application. As such, a mandate by the Director of this project that all projects must conform to this project is at best a conflict of interest.

To that point, since I was using the 2.4 Optimized app here, my cr/sec has always been lower at Einstein than here since their S5R2 app (massively less). S5R3 up to now ("power users app") has also been significantly less, despite the Boinc Combined Stats page claiming that they were within 3% or so MORE than here. S5R2 had a penalty built in for an AMD/Windows combination due to the compiler. The only way to gain some performance back was for the end-user to hack the binary and get rid of the "AuthenticAMD" string in the binary, and even then it did not compare to identical hardware using Linux... Only now with "Power Users" Windows S5R3 version 4.26 is my system about even with a Linux system running code that should be slower.

Let that sink in: A linux application on the same hardware that has less optimization and should run slower, actually runs at about the same speed. Bernd has some issues to address there... However, this is one of the many reasons why simply mandating is not a good thing, because it can mask the problems of "a few" by having more data points of "the many" that don't have some sort of penalty and thus are more "normalizable"...if that makes sense.

Finally, you'll note that I have stopped participation in doing tasks for this project. At this point I do not know if I will return. I had already started feeling that this project has less immediate scientific merit than the projects I am currently working on (Einstein, LHC, and Cosmology). This noise, and in particular David's behavior, turned me away...

---

I'm not angry because I feel the change would be "bad" for me. I'm not even really "angry", per se. I reacted strongly to the wording of David's message. I find it very troubling that he would even consider asking the factual data to be manipulated at the stats sites. That, at least to me, seems to go against the foundation of the Scientific Method.

I guess the question in my mind is not whether the factual data at the stats sites is going to be modified, but if some projects are granting too much or too little credit, can we consider the stats sites to be "factual data".

Anyway, the notion of equivalent credit per cpu second is a good notion. However it takes more work than just stating that Project X is the baseline and you must rig your credits to be 0.8X - 1.2X the value of Project X. All you're doing is rigging credits. You're not addressing the performance of a processor on various projects, like how some projects appear to use more L2 cache than others.

The problem is that there is no objective way to compare this across projects. Right now it is entirely subjective, as in "I feel my project is more efficient than others so I am going to grant more credits." It's possible to determine this within a project, for example it can be measured that SETI@home 5.27 is 68% faster than SETI@home 5.12 since they do the same thing. I could not tell you whether SETI@home is more efficient at using processor resources than, say, climateprediction.net. I can believe it is, for a variety of logical reasons. But someone else can believe it isn't for a different variety of logical reasons.

As far as L2 cache goes, the reason people assume some projects use more than others is that their run time is highly dependent upon the size of L2 cache. That doesn't necessarily mean they are more highly optimized, although it could be. Then again, they could just be inefficient in the manner in which they use L2 cache which causes more spills than necessary on machines with small L2 caches. Given what simple things, like reordering routines in memory, can do to run times I'm not prepared to make anything like a definitive answer to why these the differences are there.

Another interesting aspect is that since the science application here is Open Source, people have been free to work on optimizations, including processor architecture optimizations. Other projects do not have open source applications nor do they have resources to put into optimization.

That is true, and it's also one of the reasons it's impossible to compare relative real work done by the different projects.

I encourage any project that is able to release its application as open source to do so. SETI@home actually has less financial resources than many (or even most) other BOINC projects. Releasing open source applications is the only way we were able to get optimized applications. People volunteered to do the optimizing for us. (Thank you to Ben, Joe, Tetsuji, Alex, Simon, Crunch3r, and others for helping and pushing on the optimizations.) Using the GPL was the only way were able to get many of these optimizations back into our stock application. Of course a CPU specific app still beats the generic stock application, but it's not as big a margin as it used to be.

As such, one likely outcome of mandating SETI as the standard will mean that those who you "fear" that run to projects on the amount of credits granted would realize that cr/sec would be higher than the "1.0" baseline if one were to use the optimized application.

Definitely true. Because of this, someone crunching for credits is better off going to an open source project where they can find an optimized application. That makes it a benefit for an application to be open source, and I personally think that's a plus, although projects with closed source apps might find it to be a minus. On the minus side, being open source will also drive some people crunching for credits to find the project with the most poorly optimized stock application, since that's where they would get the most credit. (IOW, an optimized app can run 10X the speed of a poorly optimized stock app and generate 10X the credits, whereas if the stock app is well optimized, a processor specific app might only be able to go 2X as fast and generate 2X the credits.) I really don't know how to fix this problem, and that's part of the reason why we're having this discussion.

As such, a mandate by the Director of this project that all projects must conform to this project is at best a conflict of interest.

You'll get no argument from me that David's position as BOINC Director and SETI@home Director puts him in a conflict of interest. Recent experience has show that given a conflict, David will act in what he perceives as the best interests of BOINC, even if that is to the detriment of SETI@home. This edict is one example. By acting in the best interest (as he sees it) of BOINC (trying to make a uniform credit standard) he has angered some people who run SETI@home and driven them away from the project. This has been detrimental to SETI@home both in loss of crunching power and in tarnishing the image of the project.

It is logical for him to act this way, since all of his funding is directed toward BOINC as are his main interests. Currently SETI@home receives no funding from David's BOINC development grants, and SETI@home funds pay none of David's salary or expenses. In his position, I would do the same. In my position I will speak for the interests of SETI@home, even when they conflict with the interests of BOINC. Again, it's only logical that I do so.

David's position as Director of SETI@home has been largely symbolic of late. He does no direction of the day to day operation or of the science goals of the project. His main interest in SETI@home currently is as the most visible BOINC project and the primary large testing ground for new BOINC features.

The term Director itself is also misleading. Even when David was actively being "Director" of SETI@home (apart from the initial development period and early in the public release), there were very few decisions that required direction. Even then most decisions regarding the direction of SETI@home were made by Matt, Jeff, and myself with some input from Dan.

I also agree that it was unwise for David to approach credit normalization as a mandate from above. The informal agreement to have approximate credit parity is an agreement among the project leaders, not an edict from the BOINC project. The correct way to approach the matter would have been to have an open discussion of the issue rather than a curt message that seemed to demand compliance. Since then I have been discussing the issues with some of the other projects and I think that we will come to a workable (and reasonably fair) solution in a short time, but no perfect solution is anywhere on the horizon.

This in not to underestimate David's contributions to SETI@home. He still contributes to the development of the application (most recently the graphics in the version 6.0 application that is in beta now) and the design and development of the web site. And SETI@home wouldn't be where it is now without David's work on BOINC. But occasionally BOINC and SETI@home will be in conflict.

Finally, you'll note that I have stopped participation in doing tasks for this project. At this point I do not know if I will return. I had already started feeling that this project has less immediate scientific merit than the projects I am currently working on (Einstein, LHC, and Cosmology). This noise, and in particular David's behavior, turned me away...

I hope you will continue to focus on the scientific merit of projects when choosing what to crunch. It's the way I choose. Regarding David's behavior, at the time he was speaking for BOINC, not for SETI@home. Sometimes it's hard to see the difference, but it is there.

---

@SETIEric@qoto.org (Mastodon)

I'm not angry because I feel the change would be "bad" for me. I'm not even really "angry", per se. I reacted strongly to the wording of David's message. I find it very troubling that he would even consider asking the factual data to be manipulated at the stats sites. That, at least to me, seems to go against the foundation of the Scientific Method.

I guess the question in my mind is not whether the factual data at the stats sites is going to be modified, but if some projects are granting too much or too little credit, can we consider the stats sites to be "factual data".

A favorite saying of mine is... "it is what it is"

You can debate all day long about whether or not the stats and standings are meaningful at all from a cross-project perspective, but the instant you start playing around with modifying the data, then you are just as guilty as someone who you think is granting excessive credit to entice users to join their project, as you are attempting to rig that data to make it look like your project is equivalent to theirs... ("you" and "your" in the general sense, not you specifically)...

Two wrongs do not make a right. (...but three lefts do...)

Another interesting aspect is that since the science application here is Open Source, people have been free to work on optimizations, including processor architecture optimizations. Other projects do not have open source applications nor do they have resources to put into optimization.

That is true, and it's also one of the reasons it's impossible to compare relative real work done by the different projects.

...

As such, one likely outcome of mandating SETI as the standard will mean that those who you "fear" that run to projects on the amount of credits granted would realize that cr/sec would be higher than the "1.0" baseline if one were to use the optimized application.

Definitely true. Because of this, someone crunching for credits is better off going to an open source project where they can find an optimized application. That makes it a benefit for an application to be open source, and I personally think that's a plus, although projects with closed source apps might find it to be a minus. On the minus side, being open source will also drive some people crunching for credits to find the project with the most poorly optimized stock application, since that's where they would get the most credit. (IOW, an optimized app can run 10X the speed of a poorly optimized stock app and generate 10X the credits, whereas if the stock app is well optimized, a processor specific app might only be able to go 2X as fast and generate 2X the credits.) I really don't know how to fix this problem, and that's part of the reason why we're having this discussion.

I don't know how you'd deal with it either, but a general mandate that Project X is now the "standard" is, IMO, not the right way. I don't know what is the actual "right way", and there is a large contingent of people out there who would state that "something is better than nothing", but I disagree...

As for the rest...time will tell...

---

You can debate all day long about whether or not the stats and standings are meaningful at all from a cross-project perspective, but the instant you start playing around with modifying the data, then you are just as guilty as someone who you think is granting excessive credit to entice users to join their project, as you are attempting to rig that data to make it look like your project is equivalent to theirs... ("you" and "your" in the general sense, not you specifically)...

Credits aren't data, they're just credits.
They are of no value or meaning other than as an indicator of work done.

As was posted initially, the idea of equal credits for a given period of work is so that people base thier decision on which projects to support or not on the actual project itself- whether or not it is or isn't of importance to them- and not on whether they get more credits per hour than if they were to do a different project.
There is no way to comapre the value of different projects, as each person will have a different idea of what is or isn't of vaule. All the evening out of credits granted per hour per project does is make it so that people don't decide to do a project just because they'll get more credits than if they did another project.

To perceive attempts to make such a situation (projects give equal credit per hour) as rigging or manipulating data is very strange indeed.

---

Grant
Darwin NT

[S]omeone crunching for credits is better off going to an open source project where they can find an optimized application. That makes it a benefit for an application to be open source, and I personally think that's a plus, although projects with closed source apps might find it to be a minus. On the minus side, being open source will also drive some people crunching for credits to find the project with the most poorly optimized stock application, since that's where they would get the most credit. (IOW, an optimized app can run 10X the speed of a poorly optimized stock app and generate 10X the credits, whereas if the stock app is well optimized, a processor specific app might only be able to go 2X as fast and generate 2X the credits.) I really don't know how to fix this problem, and that's part of the reason why we're having this discussion.

To the extent that BOINC developers form a community, collaboration has the potential to help with the application-performance aspects of interproject parity. At least some closed-source projects already appear to be open to assistance from volunteers, and I hope there’s at least a little communication among project admins & devs over more interesting questions than credit. Of course much of the experience gained from one working on a particular science app won’t be transferable directly to others, but there must be some that can, so I would expect pooling of expertise, and perhaps some voluntary standardization of techniques, to have a levelling effect.

I hope you will continue to focus on the scientific merit of projects when choosing what to crunch. It's the way I choose.

I try to; I’ve certainly persisted with some ‘poorly paying’ projects because their goals appeal to me. OTOH I’m inclined to lose patience with sloppily administered or uncommunicative ones … Not that I’m any judge of “scientific merit” as such, but I know where my interests lie: certainly for me it’s about (vicarious) participation in the research much more than it’s like a game.

BTW, my condolences to all in your household for the departed furry companion.

---

Credits aren't data, they're just credits.
They are of no value or meaning other than as an indicator of work done.

If that was indeed the case, then we wouldn't be having this discussion, as David and/or Eric wouldn't care either.

To perceive attempts to make such a situation (projects give equal credit per hour) as rigging or manipulating data is very strange indeed.

You clearly have not read and/or understood all of what has transpired... If you would like to have a polite discussion in regards to where you are missing pieces of information, you can send me PM. Otherwise, it's not worth getting into it...

Credits aren't data, they're just credits.
They are of no value or meaning other than as an indicator of work done.

If that was indeed the case, then we wouldn't be having this discussion, as David and/or Eric wouldn't care either.

Just because people perceive they have value, doesn't mean they have; but unfortunately it does mean that they have to be treated as though they do.
And as people consider credits to be of importance it does mean that unequal granting of credits will impact on projects, to the credit of some & the detriment of others- which would be to the detriment of all BOINC projects.

I do Seti work because it's a project i consider important; without BOINC, Seti@Home would have closed up shop years ago so the success of BOINC is important to me. Unequal granting of credits between projects could lead to BOINC's demise and as a result Seti@Home.
Hence the need for parity between projects.

To perceive attempts to make such a situation (projects give equal credit per hour) as rigging or manipulating data is very strange indeed.

You clearly have not read and/or understood all of what has transpired... If you would like to have a polite discussion in regards to where you are missing pieces of information, you can send me PM. Otherwise, it's not worth getting into it...

I've read it, and no i don't understand why you think that having all projects grant credit equally is a bad thing.
As for discussing it further; thanks but no thanks. I've been involved in these discussions many times over the years. (Way too many times).


EDIT- fixed up messed up quotes.

---

Grant
Darwin NT

BTW, my condolences to all in your household for the departed furry companion.

Thanks. She was a sweet cat and she is missed. But we're getting used to life without her. Have I mentioned that death sucks?

---

@SETIEric@qoto.org (Mastodon)

Just because people perceive they have value, doesn't mean they have;

Again IANAE, but isn't the lesson of economics that things only have value because people perceive that they have value? A transaction is where people exchange something they value to get something they value more. In the case of BOINC projects, people give up their excess computing power in exchange for a combination of advancing the science, earning credits, and being part of a community. Each person will place a different value on each of those three items, but it's important that the projects recognize that all three are of value to some of their participants.

---

@SETIEric@qoto.org (Mastodon)

Again IANAE,

What does IANAE mean?

but isn't the lesson of economics that things only have value because people perceive that they have value? A transaction is where people exchange something they value to get something they value more. In the case of BOINC projects, people give up their excess computing power in exchange for a combination of advancing the science, earning credits, and being part of a community. Each person will place a different value on each of those three items, but it's important that the projects recognize that all three are of value to some of their participants.

Very true. But just because something can have value, doesn't mean it should have value (or as much value as people put on it).

I realize there's a whole metaphysical argument that can be made about people and the crazy things they value, and I would fall into that category to an extent with some of my physical belongings that are valueless to everyone else. But I guess what I'm trying to say is that I look at credits like video game points: they're fun to collect but I wouldn't cry about them if they're gone, and I wouldn't try to turn them into a big deal that consumes so much of my time on a message board or any other aspect of my life.

---

@OzzFan
Shame on you. Google....
IANAE

---

Boinc V7.2.42
Win7 i5 3.33G 4GB, GTX470

Again IANAE,

What does IANAE mean?

Compare with IANADBIPOOTV*. ;)

No help? “I Am Not An Economist.”
* “I Am Not A Doctor But I Play One On Television.”

To perceive attempts to make such a situation (projects give equal credit per hour) as rigging or manipulating data is very strange indeed.

You clearly have not read and/or understood all of what has transpired... If you would like to have a polite discussion in regards to where you are missing pieces of information, you can send me PM. Otherwise, it's not worth getting into it...

I've read it, and no i don't understand why you think that having all projects grant credit equally is a bad thing.
As for discussing it further; thanks but no thanks. I've been involved in these discussions many times over the years. (Way too many times).

As I said, you clearly have not read and/or understood things. You are confusing my disagreement with "the means" as a disagreement with "the ends".

I don't mind real efforts at cross-project parity at all.

Read the above sentence again before moving forward.

What David Anderson stated, that he was going to ask stat sites to "scale down" (aka "manipulate") the stats of projects that HE deemed as "too much", is NOT a justifiable "means" to the "end" of having project parity.

Was there going to be a boost granted to those projects that were less than SETI? We don't know. It wasn't stated.

In any case, manipulation of the data at the stat site level, in my opinion, is an incorrect approach. Eric has stated that he is working with other projects now to try to come to an agreement. Clearly he is out here because he understands that David's actions ruffled quite a few feathers, and not neccessarily because people are just opposed to the credits being equal between projects. He has stated that he felt it was unwise for David to state things the way that he did.

So, Grant, in summary:

In my opinion, David's "means" of what he proposed was not a justifiable way to reach a valid "end".

If you can't understand the nature of my objection now, and that it is not against cross-project parity but against the one ill-conceived notion of how to rig things to get there, then I think you're "very strange indeed"... ;-)

---

but isn't the lesson of economics that things only have value because people perceive that they have value? A transaction is where people exchange something they value to get something they value more. In the case of BOINC projects, people give up their excess computing power in exchange for a combination of advancing the science, earning credits, and being part of a community. Each person will place a different value on each of those three items, but it's important that the projects recognize that all three are of value to some of their participants.

Very true. But just because something can have value, doesn't mean it should have value (or as much value as people put on it).

I realize there's a whole metaphysical argument that can be made about people and the crazy things they value, and I would fall into that category to an extent with some of my physical belongings that are valueless to everyone else. But I guess what I'm trying to say is that I look at credits like video game points: they're fun to collect but I wouldn't cry about them if they're gone, and I wouldn't try to turn them into a big deal that consumes so much of my time on a message board or any other aspect of my life.

Perhaps a new category needs to be added to this list?

:^)

But I guess what I'm trying to say is that I look at credits like video game points: they're fun to collect but I wouldn't cry about them if they're gone, and I wouldn't try to turn them into a big deal that consumes so much of my time on a message board or any other aspect of my life.

Then one has to ponder:

Why exactly is this such a big deal to David Anderson and a small, yet vocal, subset of users?