Poaching (please don't!)

[hansl]

Hi, I just noticed another poached work unit from a couple days ago by Niels_Mache_Nextcloud

PROCESSING RESULT: NO FACTOR FOR M101603891 FROM 2^73 TO 2^74 [MFAKTC 0.21 BARRETT76_MUL32_GS]
ERROR CODE: 40, ERROR TEXT: TF RESULT FOR M101603891 WAS NOT NEEDED

I don't care about correcting the credit as it was just one small result (as far as I'm aware*), but I felt like naming and shaming for the record.

* This was on my only Windows computer, using MISFIT which alerts when "results not needed". No idea if any of my other machines all running Linux are victims also, I'm using a version of "mfloop" script for result uploading, which I don't think reports such occurrences.

[hansl]

I figured I'd check my results page on mersenne.org, sorted by GHzDays to see how many 0's there were.

Turns out 11 other results of mine were poached in the past couple weeks by Niels.

101604341
101604379
101604421
107601271
107601301
107601391
107601407
107601433
107601457
107601491
107601539

[storm5510]

I was poached two days ago by a used known as "Ivan M." He has been running exponents from mersenne.ca on a sub-project called "Exponents that were poorly P-1 factored." James clearly states at the top of the search page that anyone running these must get AID's first. "Ivan M" is not doing this. So, he ran over some which I had reserved causing me to receive "Results not needed" from Primenet. There were between 20 and 30 of them. I stopped running.

There are probably several ways this could be stopped. The best way I can think of is for Primenet to refuse any submitted work which does not have a valid AID. The user submitting such results would be informed of their infraction, and have no credit given. Being an old-programmer, I understand this would take a bit of additional programming on the server. It would be worth the effort.

[ixfd64]

Originally Posted by hansl

I figured I'd check my results page on mersenne.org, sorted by GHzDays to see how many 0's there were.

Turns out 11 other results of mine were poached in the past couple weeks by Niels.

101604341
101604379
101604421
107601271
107601301
107601391
107601407
107601433
107601457
107601491
107601539

As a note, you can get credit for overlapping TF results as long as you increase the bit level. For example, if the poacher had factored to 74 bits, then you will still receive full credit for "no factor from 2^73 to 2^75" results. Just make sure you actually factor to 75 bits in this case because submitting fake results isn't cool.

However, this doesn't work for factor-found results.

[kruoli]

Originally Posted by storm5510

The best way I can think of is for Primenet to refuse any submitted work which does not have a valid AID.

Generally, I understand what you are thinking about, but somehow someone should be able to report new factors without an AID (when there is an existing faulty TF, for example). Of course, that's only a small percentage where this would be helpful, but nonetheless. A factor is always more important than any other NF result. On the other hand, having an assignment that would result in the same "found factor" result, can not be segmented by that policy in the same way.

[Rodrigo]

Would there be any drawbacks to (and how hard would it be to code) a function making it impossible to get an assignment, or reporting a result, for an assignment that has not yet expired?

This afternoon I went to submit a batch of TF 74-75 assignments and all but one were rejected because somebody else submitted them yesterday. It cost me over 700 Ghz-days in CPU credit, plus electricity used and money spent that went completely to waste.

[Uncwilly]

Originally Posted by Rodrigo

This afternoon I went to submit a batch of TF 74-75 assignments and all but one were rejected because somebody else submitted them yesterday.

What range were you working in?

Maybe take smaller chunks and send them in more often.

[Rodrigo]

Originally Posted by Uncwilly

What range were you working in?

Maybe take smaller chunks and send them in more often.

Please see my PM, thanks.

[storm5510]

Originally Posted by Rodrigo

Would there be any drawbacks to (and how hard would it be to code) a function making it impossible to get an assignment, or reporting a result, for an assignment that has not yet expired?

This afternoon I went to submit a batch of TF 74-75 assignments and all but one were rejected because somebody else submitted them yesterday. It cost me over 700 Ghz-days in CPU credit, plus electricity used and money spent that went completely to waste.

In simpler terms, any active and valid assignment. 700 GHz days on a CPU is a lot of time wasted. As Uncwilly suggested, much smaller groups multiple times a day. There is really no need to hold on to completed work for long periods of time. I try to never go beyond six hours on fast running assignments.

[Uncwilly]

Potential cause of issue noted. Might be accidental related to:
https://www.mersenneforum.org/showpo...postcount=1861

[Rodrigo]

Originally Posted by storm5510

In simpler terms, any active and valid assignment. 700 GHz days on a CPU is a lot of time wasted. As Uncwilly suggested, much smaller groups multiple times a day. There is really no need to hold on to completed work for long periods of time. I try to never go beyond six hours on fast running assignments.

Just to be clear, the 700 GHz-days were on a GPU, so at least it's not like months of work were lost.

My farm has grown over time to a dozen CPUs and, more importantly, a half-dozen GPUs all running 24/7, so it could be time-consuming to report on them even once a day. The CPUs report on their own via Prime95, but not the GPUs.

I've greatly enjoyed doing the GPU manual assignment + reporting thing for all these years. Keeps me engaged with the action IMHO. That said, it may be time to consider more automated methods for TFing on GPUs.