Poaching

[blip]

Someone poached one of my exponents: 66291691


Another strange one (double assignment?): 65471347

And one more, where assignment seems ominous: 65273947

[cuBerBruce]

Originally Posted by blip

Someone poached one of my exponents: 66291691

This is probably a case of a user completing an expired assignment. I think of this as "soft poaching." I think this type of poaching has become much more common since the new recycling rules were implemented. I consider it "hard poaching" when there is deliberate poaching by someone who never had an official LL/DC assignment for the exponent.

[Madpoo]

Originally Posted by cuBerBruce

This is probably a case of a user completing an expired assignment. I think of this as "soft poaching." I think this type of poaching has become much more common since the new recycling rules were implemented. I consider it "hard poaching" when there is deliberate poaching by someone who never had an official LL/DC assignment for the exponent.

Without knowing more details about how long "blip" had these assignments beforehand, the idea that these may have been old expired assignments that *finally* turned in does seem plausible.

Quite simply, there are those assignments out there that plod along, very slowly but surely. They just can't get the work done before it expires so it gets reassigned to someone like "blip".

Meanwhile that slow, plodding system keeps chugging away and might even manage to turn theirs in first. It's happened before and will likely happen again, because even a system that slow will still keep working on their test as long as it's already in progress, and they'll finish whenever they feel like it.

[EdH]

Originally Posted by Madpoo

Without knowing more details about how long "blip" had these assignments beforehand, the idea that these may have been old expired assignments that *finally* turned in does seem plausible.

Quite simply, there are those assignments out there that plod along, very slowly but surely. They just can't get the work done before it expires so it gets reassigned to someone like "blip".

Meanwhile that slow, plodding system keeps chugging away and might even manage to turn theirs in first. It's happened before and will likely happen again, because even a system that slow will still keep working on their test as long as it's already in progress, and they'll finish whenever they feel like it.

I have no familiarity with the GIMPS s/w so I don't know how things work at all, but could there be some tiny routine placed somewhere that could tell the main system that the client is still "alive" once in a while, if it is? Maybe just something that says, "Yep, prime95/mprime is actually running here..."

Or, what about a query that checks in with the "lost" machine before the assignment goes stale? I can imagine running an assignment with my steam-powered antiques and after a looonnng time, getting told all my effort was all wasted because I took too long.

[chalsall]

Originally Posted by EdH

Or, what about a query that checks in with the "lost" machine before the assignment goes stale? I can imagine running an assignment with my steam-powered antiques and after a looonnng time, getting told all my effort was all wasted because I took too long.

The Primenet server cannot contact the client. Only the client can initiate a "conversation".

The issue we are seeing is mostly people promising to do work in a timely fashion in order to get the lowest (read: easiest to complete) assignments, but then failing to do so.

Then their assignments are recycled, and then they complain that they've been "poached". Or, even worse, the assignment is recycled and the second assignee is beaten (temporally) by the slowpoke who turn in their result after the deadline.

[Madpoo]

Originally Posted by chalsall

The Primenet server cannot contact the client. Only the client can initiate a "conversation".

The issue we are seeing is mostly people promising to do work in a timely fashion in order to get the lowest (read: easiest to complete) assignments, but then failing to do so.

Then their assignments are recycled, and then they complain that they've been "poached". Or, even worse, the assignment is recycled and the second assignee is beaten (temporally) by the slowpoke who turn in their result after the deadline.

It's hard to tell sometimes because the server deletes assignment info once it's checked in. There's enough info in the raw result message the client sends in which will include the assignment ID (if any). Based on that alone it's possible to see if the client turning in a result actually had an assignment or if they flat out poached it.

It will also add an entry to the result table showing when it was originally assigned, which is useful.

With that info in hand, I can see that these 3 exponents were indeed assigned to people previously to 3 different people.

65273947 was originally assigned 2015-03-23, returned 2016-01-17
65471347 was originally assigned 2014-12-10, returned 2016-01-05
66291691 was originally assigned 2015-03-21, returned 2016-01-27

User "blip" got those assigned between 2015-12-10 and 2015-12-29

Sad and unfortunate that someone worked on 65471347 for a year only to have it expire, get re-assigned, and then turn their old assignment in just a couple weeks before the new assignee turned theirs in.

[blip]

Originally Posted by Madpoo

Without knowing more details about how long "blip" had these assignments beforehand, the idea that these may have been old expired assignments that *finally* turned in does seem plausible.

Ok, that seems to be a possibility, will check that. Thanks.

[blip]

Originally Posted by Madpoo

Sad and unfortunate that someone worked on 65471347 for a year only to have it expire, get re-assigned, and then turn their old assignment in just a couple weeks before the new assignee turned theirs in.

Yeah, but I learned this is one of the things that can happen. As long at its not a prime...

[Prime95]

Originally Posted by EdH

I have no familiarity with the GIMPS s/w so I don't know how things work at all, but could there be some tiny routine placed somewhere that could tell the main system that the client is still "alive" once in a while, if it is? Maybe just something that says, "Yep, prime95/mprime is actually running here..."

The client does contact the server once a day with a progress report. The problems come from clients that run *very* slowly (imagine a computer on just once an hour a day) and from clients that disappear for a while only to reconnect later on.

Deciding when a client has stopped making any or sufficient progress is a difficult task. We've been tweaking the assignment rules trying to balance steady progress against wasting work.

The good news in this case is that no work was wasted. A necessary double-check got performed early.