Travis please don't go to a quorum of 2 if it doesn't affect the science as it is a waste of cpu time...seems you have other tools to adjust for the cheaters :)

whats a good value for credit typically, if it's fixed?

Take an average across different os and cpu's of "claimed credit" in benchmarks and then throw out the high and the low and voila credit granted for a given project batch of results length.As you change the parameters making work units longer in your genetic search of course you will have to adjust upwards.

Thats probably a good idea. The work units are (for the most part) fixed size, so fixed credit might be the way to go. Currently, the amount of work done is based off two things: 1. the size of the volume, and 2. the number of stars.

Between a quorum of 2 and a way of calculating credit not based off boinc's benchmarks, maybe that will fix the problem?

In My Opinion - Yes
As well as QMC@HOME or Cosmology@Home

Take an average across different os and cpu's of "claimed credit" in benchmarks...

But exclude cheaters, of course. ;-)

Take an average across different os and cpu's of "claimed credit" in benchmarks and then throw out the high and the low and voila credit granted for a given project batch of results length.

A more representative average could be obtained by filtering out results from clients whose benchmarking methods are known to be unreliable (some of these platform-specific) or user-adjustable, if that would be possible to implement.

I would hope that all participants in an alpha-testing project are prepared for all manner of anomalies WRT credit and stats, up to and including retroactive adjustments or cancelled credit (albeit only as emergency measures). Start with conservative estimates, then adjust as may be required to maintain approximate parity with the benchmark-based measures (which, in theory, implies parity with other projects), and nobody should have grounds for complaint.

Rosetta@home seems to have implemented a consensus-over-WUs method, where a running average is kept for repeated runs of the same model (or sufficiently similar ones): the first few hosts to process tasks from a given ‘batch’ may be granted, shall we say, idiosyncratic amounts of credit, but over time one would expect the grants to converge on a fair value. Obviously this depends on having sufficiently similar batches, and I guess it requires additional fields in the database records.

Most of the reliable results that I have seen are granted credit of 1.50-1.80 per WU. I would suggest to make it somewhere in this range or just make the value 2 to be nice and simple.

---

Most of the reliable results that I have seen are granted credit of 1.50-1.80 per WU. I would suggest to make it somewhere in this range or just make the value 2 to be nice and simple.

Hey Acmefrog the #s you suggest look a little low to me thats why I didn't give any values...if you look at your or my rac and hosts the sample size on os and cpu is way too small..hence my suggestion...linux,win,amd,intel,and Boinc client are all variables...do you feel confident that you have a great enough cross-section to give a good #? I don't

---

Most of the reliable results that I have seen are granted credit of 1.50-1.80 per WU. I would suggest to make it somewhere in this range or just make the value 2 to be nice and simple.

I don’t know what the variables involved may be—I could be comparing apples to oranges—but that seems very high. My G5’s recent tasks have each taken just under 3.5 minutes and earned 0.63 or 0.64 of a cobblestone, for an average production of about 11 CS/h, quite typical for this system on other projects. (I’ve also had a small number that take double the time, earning double the credit.) At 2 CS/WU this host would be getting about 35 CS/h, much more than it does on SETI@home using a third-party optimized application, let alone on any other project with a stock app.

If the WUs vary that much—by a factor of two, three, or more—a fixed-credit system won’t be suitable unless the variations are predictable and can be quickly assessed by the servers, e.g. from the number of stars or time-steps in a simulation.

Hey Acmefrog the #s you suggest look a little low to me thats why I didn't give any values...if you look at your or my rac and hosts the sample size on os and cpu is way too small..hence my suggestion...linux,win,amd,intel,and Boinc client are all variables...do you feel confident that you have a great enough cross-section to give a good #? I don't

Looking at yours, you have one that does crunch around 2 but others that crunch at a lower rate. The others people's computers that I have looked at seem to depend upon how fast a WU was crunched. The variation might be from the data (number of stars or something) but I think my guess is fairly accurate (not a scientific sampling). Maybe the credit value would have to change depending upon the type of WU but to me it seems the most common value popping up would be in the range I mentioned. A credit either way would not bother me. It is the pc that are claiming 25-250 credit per WU that bug me.

---

A credit either way would not bother me. It is the pc that are claiming 25-250 credit per WU that bug me.

Yes I agree

Would it be posible to put a limit on how much credit each computer may claim per day until a credit value it figured out? How about 6,000 credits, (2000 wu's x 3 credits per wu). That might be somewhere to start. It would cut down on the 100,000+ RAC for some people.

Most of the reliable results that I have seen are granted credit of 1.50-1.80 per WU. I would suggest to make it somewhere in this range or just make the value 2 to be nice and simple.

I don’t know what the variables involved may be—I could be comparing apples to oranges—but that seems very high. My G5’s recent tasks have each taken just under 3.5 minutes and earned 0.63 or 0.64 of a cobblestone, for an average production of about 11 CS/h, quite typical for this system on other projects. (I’ve also had a small number that take double the time, earning double the credit.) At 2 CS/WU this host would be getting about 35 CS/h, much more than it does on SETI@home using a third-party optimized application, let alone on any other project with a stock app.

If the WUs vary that much—by a factor of two, three, or more—a fixed-credit system won’t be suitable unless the variations are predictable and can be quickly assessed by the servers, e.g. from the number of stars or time-steps in a simulation.

Odysseus,

my G5s claim and receive an average of 21-23 cr/hour with SETI@Home and Einstein@Home. This seems to be fair and is in-line with the faster Windows or Linux machines. Other projects with very little participation of Mac-users grant less than that due to badly optimized Mac-clients (e.g. Rosetta@Home, etc.)

---

Would it also be possible to have a quorum of 1 unless credit > 5 or 10 (or any number), then resend untill credit < 10. That would help with cheating and help eliminate extra work.

maybe the best solution would be to blacklist their accounts from all projects.
that would hurt "highscore" cheaters most.

---

IIRC, 5.10.1x reports immediately, but 5.10.2x does not.

All up to 5.10.13 report the same day when asking for new work.

5.10.14 and above report after 24 hours, or when requesting more work when the queue is empty, or when done manually and further following the normal rules of contact.

No client reports immediately. That was a command line option in the 4.xx version, long since deprecated. (i.e. no longer in the code)

5.10.up-to-13 reports results immediately, if the "Connect to network about every" is set to zero.

---

Most of the reliable results that I have seen are granted credit of 1.50-1.80 per WU. I would suggest to make it somewhere in this range or just make the value 2 to be nice and simple.

I don’t know what the variables involved may be—I could be comparing apples to oranges—but that seems very high. My G5’s recent tasks have each taken just under 3.5 minutes and earned 0.63 or 0.64 of a cobblestone, for an average production of about 11 CS/h, quite typical for this system on other projects. (I’ve also had a small number that take double the time, earning double the credit.) At 2 CS/WU this host would be getting about 35 CS/h, much more than it does on SETI@home using a third-party optimized application, let alone on any other project with a stock app.

If the WUs vary that much—by a factor of two, three, or more—a fixed-credit system won’t be suitable unless the variations are predictable and can be quickly assessed by the servers, e.g. from the number of stars or time-steps in a simulation.

Odysseus,

my G5s claim and receive an average of 21-23 cr/hour with SETI@Home and Einstein@Home. This seems to be fair and is in-line with the faster Windows or Linux machines. Other projects with very little participation of Mac-users grant less than that due to badly optimized Mac-clients (e.g. Rosetta@Home, etc.)

Ironically, I do all my development on a mac and our linux/unix machines at school. The only windows box i have access to is a much older thinkpad :P Currently, it seems that macs are crunching the numbers the fastest, unfortunately the way credit is being granted right now isn't as good as it should be. once i get the new validator up and running this should be a lot better.

We're hoping to get access to a 64 bit windows machine so having that binary available should speed things up for the windows users.

my G5s claim and receive an average of 21-23 cr/hour with SETI@Home and Einstein@Home. This seems to be fair and is in-line with the faster Windows or Linux machines. Other projects with very little participation of Mac-users grant less than that due to badly optimized Mac-clients (e.g. Rosetta@Home, etc.)

This G5 has been getting about 16 CS/h on E@h recently, but it’s been higher from other batches in this run; the S5R3 WUs seem to vary more by this measure than previous runs’ did. IME the E@h apps for PPC have always had above-average productivity. On S@h it gets about 25 CS/h, but that’s with a custom, processor-specific app; on S@h Beta it gets about the same as most other projects, around 11 CS/h. I don’t run Rosetta on this system, but from Ralph it does about average. (I have noticed that Rosetta doesn’t do quite as well as some other projects on my partner’s Core2 iMac.)

Anyway, I certainly won’t complain if the tasks that take this host 3.5 minutes start earning two credits each—I might even increase the project’s resource share. ;)

two is better than one in my opinion but I can live with one as long as people are on a level playing field.

---