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 !

I have contacted the admin earlier, but crystallize, you are also using an unofficial 5.9.0 version with higher 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 !

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

Hm, I'm using our teams (TSWB's) BOINC application, with instant WU reporting, as far as I know it doesn't have higher benchmarks than the original BOINC !

---

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.

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.

---

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

Yes, I'll ask the team on our forum about this subject.
I don't want to take any more sh*t about it before I've investigate this more throughout ...

http://www.tswb.org/Forums/tabid/173/mid/504/threadid/11478/scope/posts/Default.aspx#11478

---

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.

Yes, also excluding 5.5.0/5.9.0 clients and perhaps an upper credit cap, reducing the credits of these high cheated hosts by factor 50-100, but as I have seen fixed credits would be wonderful, running times are all the same.

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

---

Jord.

The BOINC FAQ Service.

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.

Good work, Dan. The fingerpointing stats ho's go nuts if their clients get knocked down by an erroring client. :-(

Crystallize is using her own BOINC skin, running Crunch3r's old optimized BOINC client that reports work immediately. She mistakenly thought that her client was TSWB's because of the wording TSWB-BOINC Client in the window title.

She has been advised to upgrade her BOINC client. IIRC, 5.10.1x reports immediately, but 5.10.2x does not. In any case, further advances in the BOINC client, whether it's credit issues, bug fixes, or added features certainly makes it worth upgrading to 5.10.28.

---

Team Starfire World BOINC
IRC- irc//irc.teamstarfire.net:6667/team_starfire

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.

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)

---

Jord.

The BOINC FAQ Service.

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

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

This is not a good solution but temporarily.

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 500002814793331.347700 instead of 2814793331.347700
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?

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?

You can define credits in the wu template and validator.

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

---