Checkout this host for the last few days it's claimed/granted credit jumped from 1.xx to 25x.xx per result with no increase in crunch time.

Even without a quorum requirement there should be a check for this type of over claim.

just one more from the cheaters gang. check his cpu benchmark. maybe he brought a cpu from the year 2070 or something ;). best way to get rid of them is to have a quorom. fits niceley to almost all top hosts in this project all have silly benchmarks.

____________

Hm, yes, these is as far as I can see an obvious cheat attempt ????

or is it a error of some kind ???

I never get more than 4-8 CS per WU, and it shouldn't be more either with such a short WU completion time and certainly not over 200CS for every WU !
____________

Hm, yes, these is as far as I can see an obvious cheat attempt ????

or is it a error of some kind ???

I never get more than 4-8 CS per WU, and it shouldn't be more either with such a short WU completion time and certainly not over 200CS for every WU !

Hm, yes, these is as far as I can see an obvious cheat attempt ????

or is it a error of some kind ???

I never get more than 4-8 CS per WU, and it shouldn't be more either with such a short WU completion time and certainly not over 200CS for every WU !

I have contacted the admin earlier, but crystallize, you are also using an unofficial 5.9.0 version with higher benchmarks!

This is another host that possibly is using a dodgy client http://milkyway.cs.rpi.edu/milkyway/show_host_detail.php?hostid=1314
____________

out of sudden. the cheat hosts all have hidden computers now lol

____________

best way to get rid of them is to have a quorom.

out of sudden. the cheat hosts all have hidden computers now lol

best way to get rid of them is to have a quorom.

I disagree. That also has the side effect of reducing the total crunching by 50% or more. Just slows down the project. Increasing the quorum should be done only if the science requires it.

A better way to deal with this kind of thing is fixed credits, or some sort of step counting.

The High Benchmarks could be causing a problem if that is how the Core client figures out scores. That is an Old version of BOINC and was known to cause weird results. They did not cheat but should update their Boinc client to a newer version.

You guys should have looked at the returned results and would have found out Either the core client has a problem or the WU's are causing problems.

Every WU I checked showed memory leaks in them. this can only be caused by the core client or by the WU's. This would not be caused by the Boinc Client.

The High Benchmarks could be causing a problem if that is how the Core client figures out scores. That is an Old version of BOINC and was known to cause weird results. They did not cheat but should update their Boinc client to a newer version.

The High Benchmarks could be causing a problem if that is how the Core client figures out scores. That is an Old version of BOINC and was known to cause weird results. They did not cheat but should update their Boinc client to a newer version.

You guys should have looked at the returned results and would have found out Either the core client has a problem or the WU's are causing problems.

Every WU I checked showed memory leaks in them. this can only be caused by the core client or by the WU's. This would not be caused by the Boinc Client.

The High Benchmarks could be causing a problem if that is how the Core client figures out scores. That is an Old version of BOINC and was known to cause weird results. They did not cheat but should update their Boinc client to a newer version.

Version 5.10.20 had no problems with correctly benchmarking a CPU.
The BOINC versions that possibly gave weird outcomes due to benchmark inconsistencies were 5.8.17, 5.10.1 and 5.10.6

None of the above versions gave integer benchmark claims in the way the two clients in this thread have them. So either someone took the core client code and adjusted how the benchmarks should be done before compiling it as a 5.10.20 client (easily done by changing the version number before compiling), or they've changed their values in client_state.xml

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

I'll try and update our validator tonight to get a quorum of 2 going, so hopefully this will fix any cheating.

The High Benchmarks could be causing a problem if that is how the Core client figures out scores. That is an Old version of BOINC and was known to cause weird results. They did not cheat but should update their Boinc client to a newer version.

Version 5.10.20 had no problems with correctly benchmarking a CPU.
The BOINC versions that possibly gave weird outcomes due to benchmark inconsistencies were 5.8.17, 5.10.1 and 5.10.6

None of the above versions gave integer benchmark claims in the way the two clients in this thread have them. So either someone took the core client code and adjusted how the benchmarks should be done before compiling it as a 5.10.20 client (easily done by changing the version number before compiling), or they've changed their values in client_state.xml

BINGO! client_state.xml
But "changing the version number" is OT.
Try edit (make higher) benchmark in this file.
For example <p_iops>500002814793331.347700</p_iops> instead of <p_iops>2814793331.347700</p_iops>
and "credit jumped from 1.xx to 1xxx.xx per result with no increase in crunch time."
Version number of the Boinc client is irrelevant.
To admin: ...Houston, ve have problem...
Best and simply is FIXED credit.

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?

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 :)
____________

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?

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

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.

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.

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

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

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.

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)

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.)

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