Just thought you'd like to know what the new ideas for credit are. It's just talk at the moment and just ideas.

Several goals were identified:
1) make the credit system more "fair":
the claimed credit should the proportional
to the work actually done.
In particular, reduce the variation in claimed credit
for identical work.
2) social engineering: use the credit system to
steer people's PC purchasing decisions in a way
that maximally benefits science projects,
and to steer people towards the project that
can best use their particular resource.
3) simplicity: make it easy for users to understand

------------------
For 1) it was speculated that adding a memory-bandwidth benchmark,
and using it somehow in the credit calculation, would help.
Suppose app does X bytes of mem access, Y FP ops, and Z int ops,
and computer has mem bw A, fp B, int C.
Then time to do one unit of work is max(X/A, Y/B, Z/C)
and rate of work is 1/(max(x/a, y/b, z/c)

------------------
For 2), Anderson proposed a scheme in which projects
would publish a "pricing schedule" saying how much
credit per CPU second they give as a function of
RAM size
mem BW
FP bench
int bench
avail disk space
(other possible factors)
This would reflect their eventual plans, not necessarily
what their apps currently use.
For example, if CPDN wants to do an experiment that
requires 8GB RAM,
they could offer a high price for such machines,
even if their current apps don't use 8GB.

To prevent credit inflation there would be a
"inter-project parity" mechanism,
which would require that a project's price schedule,
integrated over the current population of all BOINC hosts
(not just those participating in the project)
averages out to a constant C.
I.e., if CPDN wants to give more credit for 8 GB machines,
they'll have to give less for other machines.
(In general, the average credit/sec for a project may
be higher than C, if the social engineering works).
This will require adding CPU time to XML exports (and DB)

If this scheme is deployed it would be possible to show
various information:
- Given a particular machine, a table of how much
credit/day it can expect to get on various projects
- Given a particular machine, how much additional
credit/day can be expected if it is upgraded in various ways
... and so on.

It's unclear how best to express pricing schedules.
One approach is to use an N-dim matrix (awkward if N is large).
Another is to use a piecewise linear function for each factor;
total credit is product of factors

There are some issues involving multi-core and multi-CPU machines,
We don't want a 4-CPU machine with 1 GB RAM to count
either as 4 1-CPU machines with 256 MB RAM each,
or as 4 1-CPU machines with 1 GB RAM each,
One approach is to calculate the credit/sec (for a PC as a whole)
as the max of C(n), the credit per sec using
n CPUs (and dividing RAM evenly between them).

We may want to generalize the benchmarks so that they
"discover" the memory architecture of the host.
------------------

We discussed the idea of letting each projects
assign additional "soft" credit
(not to exceed 10% of its "hard" credit)
to reward various types of user behaviors, such as
referral bonus for recruiting new users
message board participation
particular science results

-------------------
We discussed the idea of exchanging credit for products/services
iTunes download
EZNews?

(need to add "credit available for exchange" DB field)
need to work out secure RPC for transactions

---

Team mauisun.org

We discussed the idea of exchanging credit for products/services
iTunes download
EZNews?

(need to add "credit available for exchange" DB field)
need to work out secure RPC for transactions

This sounds like a good idea, but many other credit issues and arguments would need to be settled first. I think it would also cause more issues (and more work) for developers who would need to deal more stictly with suspect behavior regarding credit.

It would require true parity that could be agreed upon as fair by everyone, so that no project would draw users away from others for simply giving out more credit (or appearing to do so).

It would also require (IMO) that the credits available for exchange be only those credits that are awarded after the services become available. It would otherwise revive some enormous demons of the past few months in the Rosetta community (and maybe in other projects as well, I don't lurk in other forums very much so I don't know).

Other issues pertain as well, but I'll assume that his possibility is far in the future (if it comes to fruition at all) and I'll leave them for later.

---

We discussed the idea of exchanging credit for products/services
iTunes download
EZNews?

(need to add "credit available for exchange" DB field)
need to work out secure RPC for transactions[/i]

I think this could be on a project by project basis as well, donations from sponsors to this special one, and as such something distinct from the overall BOINC credit.

The idea is not that new : http://zennyexchange.com/

We discussed the idea of exchanging credit for products/services
iTunes download
EZNews?

(need to add "credit available for exchange" DB field)
need to work out secure RPC for transactions

This sounds like a good idea, but many other credit issues and arguments would need to be settled first. I think it would also cause more issues (and more work) for developers who would need to deal more stictly with suspect behavior regarding credit.

It would require true parity that could be agreed upon as fair by everyone, so that no project would draw users away from others for simply giving out more credit (or appearing to do so).

It would also require (IMO) that the credits available for exchange be only those credits that are awarded after the services become available. It would otherwise revive some enormous demons of the past few months in the Rosetta community (and maybe in other projects as well, I don't lurk in other forums very much so I don't know).

Other issues pertain as well, but I'll assume that his possibility is far in the future (if it comes to fruition at all) and I'll leave them for later.

I believe it would be project specific, something added to the API for projects that wish to use it.
Ok so they are giving an incentive to move to that project, so what. Rosetta@home/WCG give the incentives that it will help cure diseases.

Future project maybe like MoneyBee or other financial project, maybe an Amazon funded project. Why shouldn't they give an incentive to go there. Don't forget even if the cross-project parity (on the average computer) is even, it does not mean it'll be CPU specific or OS specific. It also does not mean one project could give 2 eBay vouchers for xx credit and another gives 4 Amazon vouchers for x credit...
(basically it's just adding features to the API for projects that wish to use it, e.g. A project may want to trade credit for logoed mugs ;-))

---

Team mauisun.org

I believe it would be project specific, something added to the API for projects that wish to use it.
Ok so they are giving an incentive to move to that project, so what. Rosetta@home/WCG give the incentives that it will help cure diseases.

Future project maybe like MoneyBee or other financial project, maybe an Amazon funded project. Why shouldn't they give an incentive to go there. Don't forget even if the cross-project parity (on the average computer) is even, it does not mean it'll be CPU specific or OS specific. It also does not mean one project could give 2 eBay vouchers for xx credit and another gives 4 Amazon vouchers for x credit...
(basically it's just adding features to the API for projects that wish to use it, e.g. A project may want to trade credit for logoed mugs ;-))

Incentives are good. I guess I would want to see this kind of incentive to come to BOINC but wouldn't feel as good about it if it were project by project. My thinking is this:

The reason that projects come to BOINC is largely that the researchers don't have the resources to carry out their work without our help. We give help and it would be reasonable to give something back in return for that help. But if a project doesn't have resources or connections comparable to others, then they cannot offer incentives that are as appealing. This would be fine if the least worthy projects (or those with least potential) were given the least resources, but we know that this isn't always true. Instead, projects that are just starting or are less well connected (and therefore need the most help) would not be able to offer as many incentives.

My thought process is somewhat self contradictory, I know that. Also, I think that the system you describe is completely fair (this is the real world, after all) but I still don't like the idea - there's another fair way which is better.

The CPU/OS thing I recognize but there isn't really much we can do about it except direct people to where they would be of most benefit.

---

One idea I do not like and I think may backfire (though I can see if a project wants to do it, then why not)

The CPDN thing, paying more credit to faster comupters in the aid to bring them to the project... What does this send to the person that has been doin gthe project for 1 year and now has in comparision an inceredibly slow computer to the new ones. Oh look we want these 4 core 4GB computers to run the models so we'll give you more credit per hour, but hey all you long tmers thanks for helping you can bugger off now, if you don't want to bugger off we'll be giving you less credit from now on (even though you maybe doing the same work). Ta V.Much.

The other flaw is the licensing, there is nothing in it (since the cannot put it in) to stop a project from giveing what it likes anyway. Though it would be nice for the project to drop the little guys scores, not really say they would have to do that, it's open source. Free to use and modify as you like (wrt standard license). Hey there was nothing to stop Rosetta giving double points to all during CASP7 in a bid to bring people here, then give them a added xxxx points at the end to say thanks.

---

Team mauisun.org

[quote]
thanks for that report FC = it sounds like it was a thoughtful and productive workshop.

R~~

One idea I do not like and I think may backfire (though I can see if a project wants to do it, then why not)

The CPDN thing, paying more credit to faster comupters in the aid to bring them to the project... ....

I fully agree, that's a crappy idea. I will not crunch for any project that implements this, not with slow hosts and not with fast ones either.

Fast hosts get more credits anyway, caused by the fact that they are faster.

One reliable slow host can do more full runs than 10 unstable fast ones, which sure does play a role especially at CPDN.

The correct solution would be ramping up the credits towards the full run so people who overclock way too much are encouraged to stay within the stable parameters. With higher credits for faster hosts they would encourage people to hunt for credits by OCing higher than their equipment allows.

But that's a CPDN thing, it currently doesn't apply to Rosetta.

One idea I do not like and I think may backfire (though I can see if a project wants to do it, then why not)

The CPDN thing, paying more credit to faster comupters in the aid to bring them to the project... ....

I fully agree, that's a crappy idea. I will not crunch for any project that implements this, not with slow hosts and not with fast ones either.

Fast hosts get more credits anyway, caused by the fact that they are faster.

One reliable slow host can do more full runs than 10 unstable fast ones, which sure does play a role especially at CPDN.

The correct solution would be ramping up the credits towards the full run so people who overclock way too much are encouraged to stay within the stable parameters. With higher credits for faster hosts they would encourage people to hunt for credits by OCing higher than their equipment allows.

But that's a CPDN thing, it currently doesn't apply to Rosetta.

I suppose the comparable thing here at Rosetta@home would be to give a bonus if you run the 1GB tasks they tried to do (say a 5% increase on your cranted), oh they could give you an extra 2% credit for using the (hopefully to be implemented) beta opt-in and helping them test beta runs, oh oh and an extra 1% for refering a friend :-), then you can trade them all in for some cookies at Amazon with the extra vouchers ;-)

---

Team mauisun.org

One idea I do not like and I think may backfire (though I can see if a project wants to do it, then why not)

The CPDN thing, paying more credit to faster comupters in the aid to bring them to the project... ....

...

But that's a CPDN thing, it currently doesn't apply to Rosetta.

I suppose the comparable thing here at Rosetta@home would be to give a bonus if you run the 1GB tasks they tried to do ...

I don't think that this would really be compareable. If a job really requires more ressources in order to run, it can have a bonus, no problem with that.

CPDN needs quite much HD space and it requires good nerves, quite a valuable ressource and worth a bonus ;-) But that is independant from the plain CPU power, which is already reflected by the trickle frequency and doesn't need an extra bonus.

One idea I do not like and I think may backfire (though I can see if a project wants to do it, then why not)

The CPDN thing, paying more credit to faster comupters in the aid to bring them to the project... ....

...

But that's a CPDN thing, it currently doesn't apply to Rosetta.

I suppose the comparable thing here at Rosetta@home would be to give a bonus if you run the 1GB tasks they tried to do ...

I don't think that this would really be compareable. If a job really requires more ressources in order to run, it can have a bonus, no problem with that.

CPDN needs quite much HD space and it requires good nerves, quite a valuable ressource and worth a bonus ;-) But that is independant from the plain CPU power, which is already reflected by the trickle frequency and doesn't need an extra bonus.

But the bonus has to be negated by removing that much from the people who do not run thoose jobs, to keep the balance.

---

Team mauisun.org