Detecting and defeating assignment server cheaters

[ChasR]

It comes from the weight given to the WUs and can be seen in serverstatus. IIRC, p8101 has a weight of 10, while the p690x series has a weight of 1, hence the 10:1 ratio.

[Punchy]

I originally guesstimated 10% 690x just based on people's experiences posted in a few threads.
The 10:1 ratio came from examining the OS_Weight_Program_Port parameter from the server status page for the two servers involved.

[PinHead]

Then it must be time weighted or WU count weighted, otherwise I would not have been able to receive them back to back. That being said, it seems to be a simple calculation to defeat without breaking the best rules of practices rule.

So letting time run it's course is probably the best solution.

[Amaruk]

And, as I described the time threshold via the "fastest 12 core system", so it would make sense to set the cap based on that same "fastest" system.

So you're trying to get PG to manipulate the points system in such a way as to benefit your team while crippling another. Specifically, you want to preserve the 30% bonus for all of your single socket systems while simultaneously cutting the PPD of the 'other guys' multi-socket systems by 80% or more. Good luck with that.

The real solution is already known to PG, Vijay himself wrote about it months ago.

IF the point values for 8101 are representative of bigadv, bring the other projects in line with it.


Here are TPFs for various bigadv on a 930 (4C/8T), dual 5620s (8C/16T), dual 5645s (12C24T) and 4P 6174 (48C/48T)

Code: Select all

Project            6901         6903       6904         8101

930 - 3.8         00:29:45    01:06:32    01:34:18    01:00:39

2P 5620 - 3.8     00:15:10    00:34:14    00:50:58    00:31:51

2P 5645 - 3.8     00:10:47    00:25:18    00:35:35    00:24:34

4P 6174 - 2.2     00:06:31    00:14:27    00:19:38    00:14:27

Here is the PPD with current base points:

Code: Select all

Project              6901        6903        6904        8101

930 - 3.8          36,436.60   48,853.24    4,816.44    5,367.53

2P 5620 - 3.8     100,099.76  132,366.64  119,296.29   96,637.97

2P 5645 - 3.8     166,970.10  208,339.46  204,496.72  142,656.85

4P 6174 - 2.2     355,410.29  482,670.28  498,959.41  316,235.20

Bringing 6903/4 roughly in line on the 2P 5620 can be accomplished by:

Reducing base points for 6903 from 22,706 to 16,700.

Reducing base points for 6904 from 31,541 to 22,400.


This results in the following PPD:

Code: Select all

Project              6901        6903        6904        8101

930 - 3.8          36,436.60   35,930.99    3,420.57    5,367.53

2P 5620 - 3.8     100,099.76   97,354.13   84,722.64   96,637.97

2P 5645 - 3.8     166,970.10  153,231.26  145,230.86  142,656.85

4P 6174 - 2.2     355,410.29  354,998.40  354,354.36  316,235.20

Simply changing base points for 6903 & 6904 will make the primary issue being discussed here go away, and would allow PG to weigh BA assigns according to scientific need without having to worry about anyone 'cheating' the system. At that point it would not matter if PG changed the core requirements or not, they could continue to assign BA8/BA12 as they are now if desired.

PG provided a solution quite some time ago, 690x are nearing their end and the issue will go away.

I wouldn't be so sure they're ending anytime soon, currently there are almost twice as many BA8/BA12 WUs as there are BA16.

With that in mind, giving single core systems the opportunity to fold them as needed could prove beneficial to both PG and 12 core folders.

[Punchy]

And, as I described the time threshold via the "fastest 12 core system", so it would make sense to set the cap based on that same "fastest" system.

So you're trying to get PG to manipulate the points system in such a way as to benefit your team while crippling another. Specifically, you want to preserve the 30% bonus for all of your single socket systems while simultaneously cutting the PPD of the 'other guys' multi-socket systems by 80% or more. Good luck with that..

Nope, the cap would only be imposed on systems that reported 12 cores. It wouldn't have any effect on the other systems that received those WUs as part of their 1 in 11 ratio from the AS. And, while I agree that other points should be brought in line with 8101, and that 690x do seem to be going on indefinitely, that's part of previous discussions regarding alternative solutions. This solution, if possible in the AS/CS logic, could prevent similar issues in the future as well.

[gwildperson]

Isn't this whole topic a moot argument? The projects are planned to end and if I understand correctly, the whole issue goes away. Why would the Pande Group waste any effort correcting the inequality or resolving the controversy?

[Punchy]

Isn't this whole topic a moot argument? The projects are planned to end and if I understand correctly, the whole issue goes away. Why would the Pande Group waste any effort correcting the inequality or resolving the controversy?

The earth is planned to end at some point as well, right? It all depends on what time scale we're talking about - geological or other.

[v00d00]

Good luck with it Punchy. We've been trying to get a linux gpu client for years. The likelihood of them changing the points for you or anything else are astronomical. It is rare that anything happens on here besides new projects being announced.

[PinHead]

PG provided a solution quite some time ago, 690x are nearing their end and the issue will go away.

I wouldn't be so sure they're ending anytime soon, currently there are almost twice as many BA8/BA12 WUs as there are BA16.

What servers are you seeing this on? When I look, SMP 8 and SMP 12 have NMJ.