ideas for expediting milestones and reducing poaching

[ixfd64]

I have a few ideas on how to clear milestones faster while discouraging poaching.

E-mail notifications

PrimeNet could send an e-mail notification to the user in the following situations:

1. An assignment has not been updated in X days
2. An assignment has not been started after X days
3. An assignment is close to expiring
4. An assignment is unlikely to finish before the expiration date
5. An assignment has expired
6. A returned result is proven to be bad

An example notification for the third case may look something like this:

Dear <PrimeNet user ID>:

One of your GIMPS assignments, a first-time test of M########, is due to expire on <date>. However, your computer's current rate suggests that it will finish on <ETA>, which is past the due date. Please note that the assignment may be reassigned to and finished by another user.

What you can do:

• Extend the assignment under your account settings
• Transfer the assignment to a faster computer
• Unreserve the exponent
• Do nothing; the exponent will expire and likely be assigned to another user

Require confirmed e-mail for Category 0 and 1 assignments

Assuming the above feature is implemented, a verified e-mail address should be a prerequisite for Category 0 and 1 assignments. Sometimes users may not even know that one of their machines has gone offline. Things like power failures and automatic restarts due to software updates can disrupt GIMPS jobs.

Poaching protection

One way to discourage poaching would be to place poached results in limbo. In other worlds, they would not be processed by server until the original assignment finishes, expires or is unreserved. Users would be able to opt out; this is so that placeholder accounts (such as the GPU to 72 spider) can "subcontract" assignments.

It may not be a bad idea to notify the user of poached assignments:

Dear <PrimeNet user ID>:

Another user, <PrimeNet user ID>, has found a factor for M########, an exponent assigned to you for double-checking. This means that M######## is decidedly composite.

It is suggested that you unreserve the exponent to avoid wasted work. However, you are free to complete it anyway, in which case you will still receive PrimeNet credit. Even if an exponent has been proven composite, a matching Lucas-Lehmer residue will show that your computer is in good working order.

[petrw1]

+1

[chalsall]

Originally Posted by ixfd64

I have a few ideas on how to clear milestones faster while discouraging poaching.

I don't think this is actually needed.

Since the new assignment rules have been put in place there seems to be very little poaching going on.

For those few workers who let assignments expire, they won't be given low assignments in the future.

I would argue we let the system do its job as designed. Never send a human to do a machines job.

[vsuite]

Is there any concrete information please on

What was the rate of poaching before the new rules were implemented?

What is the (decreased) poaching rate now?

[Gordon]

Poaching happens, you won't stop it, deal with it and move on.

I've done it before and had it done to me. In the grand scheme it matters not a jot.

[chalsall]

Originally Posted by vsuite

Is there any concrete information please on What was the rate of poaching before the new rules were implemented? What is the (decreased) poaching rate now?

I can't speak to that other than external observation. Aaron and/or George would be able to speak to this definitively.

But, as an example, take a look at 66587777. "deucalion" was assigned this 2016-03-30 after it was recycled, and completed it today. "proxy2222" then shortly later submitted a result (interestingly, with a different residue).

Previously proxy2222 has been known to poach low candidates. I'm hopeful (but don't know) that what instead happened in this case is he worked the candidate but didn't submit the result until after the official assignee completed.

[GP2]

Originally Posted by chalsall

But, as an example, take a look at 66587777. "deucalion" was assigned this 2016-03-30 after it was recycled, and completed it today. "proxy2222" then shortly later submitted a result (interestingly, with a different residue).

Even stranger is the ANONYMOUS user in 2015 who let this exponent expire at 99.9% complete...

[Syntony]

Originally Posted by Gordon

Poaching happens, you won't stop it, deal with it and move on.

I've done it before and had it done to me. In the grand scheme it matters not a jot.

See exponent 35872469 - user Bruno Victal has just posted an asynchronous 'Manual Testing' factor while pi is performing an LL DoubleCheck - same has happened to me in the past and I've just allowed the (almost finished) double-check to complete...

[Syntony]

Originally Posted by chalsall

I can't speak to that other than external observation. Aaron and/or George would be able to speak to this definitively.

But, as an example, take a look at 66587777. "deucalion" was assigned this 2016-03-30 after it was recycled, and completed it today. "proxy2222" then shortly later submitted a result (interestingly, with a different residue).

Previously proxy2222 has been known to poach low candidates. I'm hopeful (but don't know) that what instead happened in this case is he worked the candidate but didn't submit the result until after the official assignee completed.

proxy2222 seems to have a suspect machine, they've posted quite a few bad results if I'm not mistaken...

[Madpoo]

Originally Posted by Syntony

proxy2222 seems to have a suspect machine, they've posted quite a few bad results if I'm not mistaken...

Hmm... I just checked on that machine specifically that turned in the mismatched DC... it actually has a decent enough track record, although it's a newer CPU (added this January).

So far it has 9 good zero bad, 21 unknown (including that one mismatch).

[endless mike]

Originally Posted by Madpoo

Hmm... I just checked on that machine specifically that turned in the mismatched DC... it actually has a decent enough track record, although it's a newer CPU (added this January).

So far it has 9 good zero bad, 21 unknown (including that one mismatch).

We'll know soon enough, I just added to one of my machines to run. It didn't have anyone assigned to it yet.