Poaching (please don't!) - Page 11

lisanderke · 2022-03-19, 11:10

User SRJ2877 went and (manually) took the cofactor-PRP test on an exponent 397849 I found an additional factor for :( As I understand it, when a factor is found for an exponent below cofactor PRP wavefront, the exponent is locked for five days from being assigned to anyone else that isn't the person that found the latest factor.

I guess I'll have to regularly check my results page and get the assignment for it (in hopes that other people won't poach an active assignment). This must be the downside of running P-1 that spews out factors left and right!

lisanderke · 2022-03-20, 11:13

Apparently they have something automated set up to "poach" any new co-factor PRP opportunity the moment one arises in the range that I'm finding factors in. (seemingly even before the hourly results page updates?)
263927 and 263843 are more examples of this. I was able to spot the factor found result for the former around ten minutes after the result was sent in by my machine, to find user SRJ2877 to already having finished the co-factor assignment.
It doesn't seem like they have an account on this forum, so I have no clue how to reach out to them and ask them to respect the 5-day wait period I mentioned earlier. I'll have to cave and make my machine hold results instead of sending them as assignments finish.

storm5510 · 2022-03-20, 15:15

To me, this is no better than poaching. This is from James Heinrich's >1000M project. An individual attempts to complete a bit range and another jumps in and takes a small amount which prevents the first person from completing the group. In this case, the first person was me.

slandrum · 2022-03-21, 06:14

60227683 was poached from me - in a similar fashion to other poaching that I'm seeing going on.
I only noticed when I realized that one of my machines doesn't have an assignment showing on the workload page.
There are (that I've noticed) two accounts poaching LL-DC assignments and running them as PRP. I don't know why it's happening, but the pattern is the same, a DC assignment expires, gets reassigned, and within a couple days one of these two accounts turns in a PRP result for the exponent poaching the reassigned DC.

My first guess was that they are trying to poach assignments that are clearly going to expire and just doing a bad job of it so are making matters worse by poaching the reassignments. But now I think there may be something else going on, and they may think they are getting legitimate assignments when they are not.

If someone is poaching DC assignments, there's really no need to do it, the best possible outcome is that no work is duplicated but there's no particular benefit. But a likely outcome is that now work is duplicated and wasted unnecessarily, and legitimate assignments are stolen which annoys people.

Another possibility is that the assignments are being obtained legitimately, but then being unassigned during the attempt to change them from DC to PRP (they can't be PRP-DC because there's no prior PRP) and then they get reassigned to someone else who is now doing work that's soon to be invalidated.

Whatever is causing it, it should stop happening.

alpertron · 2022-03-27, 12:45

Quote:

Originally Posted by storm5510

To me, this is no better than poaching. This is from James Heinrich's >1000M project. An individual attempts to complete a bit range and another jumps in and takes a small amount which prevents the first person from completing the group. In this case, the first person was me.

Numbers on that range can be reserved for 10 days only. So after this period, either the numbers are processed, or unreserved.

storm5510 · 2022-03-27, 15:03

Quote:

Originally Posted by alpertron

Numbers on that range can be reserved for 10 days only. So after this period, either the numbers are processed, or unreserved.

I am aware of this. It is just the idea of someone doing it to be an a**.

ixfd64 · 2022-04-12, 06:56

One of my PRP assignments was recently poached as well: https://mersenne.org/m111965131

I don't believe this was intentional because the user is a long-time GIMPS contributor. In all likelihood, they simply had continued to work on an assignment that had expired. It also looks like the original assignment was done by an older client that does not support proof files. Otherwise, the PRP certification would have been completed a long time ago. Given that I'm running PRP tests with proofs, this is not a waste for me.

However, there might be duplicate work if the exponent gets reassigned to someone else in the interim. Is it possible for George or another privileged user to "unexpire" assignments?

Uncwilly · 2022-05-03, 19:23

I got poached by PrimeNet user Manuel F. Fernandez. I was assigned the lowest DC. on April 23. The assignment was progressing until this weekend when the machine was rebooted during a software update. The assignment was to complete Sunday. I restarted the machine this morning. And I get back to the terminal less than 6 hours later and it is poached. It was working fine and barely missing its ETA. It still had weeks before it might expire. Obviously the user didn't watch the progress on the exponent and just decided to it.

kriesel · 2022-05-03, 20:15

Quote:

Originally Posted by ixfd64

One of my PRP assignments was recently poached as well: https://mersenne.org/m111965131
...
Is it possible for George or another privileged user to "unexpire" assignments?

Seems like you might be able to manually reserve it as a PRP DC.

slandrum · 2022-05-04, 04:55

Quote:

Originally Posted by Uncwilly

I got poached by PrimeNet user Manuel F. Fernandez.

Not exactly. If you look at the recently cleared page, you'll find that they got the assignment legitimately and worked on it for 71.3 days before turning in the result. The problem is that it was cat 1 when assigned, so it needed to be finished in 60 days. Their assignment expired and you got it. They continued to work on the assignment until it completed and a result was turned in while you were now working on it. Probably they never knew the assignment had expired, and possibly didn't know that it was even completed.

This just shows the drawback to expiring assignments that are actively being worked on. However if they didn't it creates an issue for completing milestones. I've seen assignments that have been worked on for close to a decade. I saw one result turned in for an assignment that started as a FTC, but when it was completed it was a quad check after the DC trailing edge had moved passed it over 8 years later.

retina · 2022-05-05, 06:04

Quote:

Originally Posted by slandrum

This just shows the drawback to expiring assignments that are actively being worked on.

So how to make it less bad?

After expiry, one could compute the ETA (A) based upon the partial progress (or use the ETA reported by Prime95) and compare that to the ETA (B) for someone else to complete it starting from zero, if A < B don't be so panicky to re-assign with such haste.

It might be more efficient to simply wait it out than start afresh. Just because it has officially "expired" doesn't mean someone else has to jump in ASAP. Have a bit of patience. Relax.

2022-03-19, 11:10	#111
lisanderke "Lisander Viaene" Oct 2020 Belgium 109 Posts	User SRJ2877 went and (manually) took the cofactor-PRP test on an exponent 397849 I found an additional factor for :( As I understand it, when a factor is found for an exponent below cofactor PRP wavefront, the exponent is locked for five days from being assigned to anyone else that isn't the person that found the latest factor. I guess I'll have to regularly check my results page and get the assignment for it (in hopes that other people won't poach an active assignment). This must be the downside of running P-1 that spews out factors left and right! Last fiddled with by lisanderke on 2022-03-19 at 11:17

2022-03-20, 15:15	#113
storm5510 Random Account Aug 2009 2²×3×179 Posts	To me, this is no better than poaching. This is from James Heinrich's >1000M project. An individual attempts to complete a bit range and another jumps in and takes a small amount which prevents the first person from completing the group. In this case, the first person was me. Attached Thumbnails

2022-03-21, 06:14	#114
slandrum Jan 2021 California 2²·3·5·7 Posts	This is really not cool 60227683 was poached from me - in a similar fashion to other poaching that I'm seeing going on. I only noticed when I realized that one of my machines doesn't have an assignment showing on the workload page. There are (that I've noticed) two accounts poaching LL-DC assignments and running them as PRP. I don't know why it's happening, but the pattern is the same, a DC assignment expires, gets reassigned, and within a couple days one of these two accounts turns in a PRP result for the exponent poaching the reassigned DC. My first guess was that they are trying to poach assignments that are clearly going to expire and just doing a bad job of it so are making matters worse by poaching the reassignments. But now I think there may be something else going on, and they may think they are getting legitimate assignments when they are not. If someone is poaching DC assignments, there's really no need to do it, the best possible outcome is that no work is duplicated but there's no particular benefit. But a likely outcome is that now work is duplicated and wasted unnecessarily, and legitimate assignments are stolen which annoys people. Another possibility is that the assignments are being obtained legitimately, but then being unassigned during the attempt to change them from DC to PRP (they can't be PRP-DC because there's no prior PRP) and then they get reassigned to someone else who is now doing work that's soon to be invalidated. Whatever is causing it, it should stop happening.

2022-04-12, 06:56	#117
ixfd64 Bemusing Prompter "Danny" Dec 2002 California 2,467 Posts	One of my PRP assignments was recently poached as well: https://mersenne.org/m111965131 I don't believe this was intentional because the user is a long-time GIMPS contributor. In all likelihood, they simply had continued to work on an assignment that had expired. It also looks like the original assignment was done by an older client that does not support proof files. Otherwise, the PRP certification would have been completed a long time ago. Given that I'm running PRP tests with proofs, this is not a waste for me. However, there might be duplicate work if the exponent gets reassigned to someone else in the interim. Is it possible for George or another privileged user to "unexpire" assignments? Last fiddled with by ixfd64 on 2022-04-12 at 07:04

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Poaching	Kevin	Lounge	123	2021-03-12 05:03
Poaching	blip	Data	8	2016-01-30 01:59
Poaching	davieddy	Lounge	6	2010-10-16 12:31
Poaching and v5	PrimeCruncher	PrimeNet	6	2004-04-05 19:17
New fashion poaching (???)	lycorn	Lounge	6	2003-01-31 08:33

2022-03-20, 11:13	#112
lisanderke "Lisander Viaene" Oct 2020 Belgium 109 Posts	Apparently they have something automated set up to "poach" any new co-factor PRP opportunity the moment one arises in the range that I'm finding factors in. (seemingly even before the hourly results page updates?) 263927 and 263843 are more examples of this. I was able to spot the factor found result for the former around ten minutes after the result was sent in by my machine, to find user SRJ2877 to already having finished the co-factor assignment. It doesn't seem like they have an account on this forum, so I have no clue how to reach out to them and ask them to respect the 5-day wait period I mentioned earlier. I'll have to cave and make my machine hold results instead of sending them as assignments finish.

2022-05-03, 19:23	#118
Uncwilly 6809 > 6502 """"""""""""""""""" Aug 2003 101×103 Posts 10100101011101₂ Posts	I got poached by PrimeNet user Manuel F. Fernandez. I was assigned the lowest DC. on April 23. The assignment was progressing until this weekend when the machine was rebooted during a software update. The assignment was to complete Sunday. I restarted the machine this morning. And I get back to the terminal less than 6 hours later and it is poached. It was working fine and barely missing its ETA. It still had weeks before it might expire. Obviously the user didn't watch the progress on the exponent and just decided to it.