Newer milestone thread

[Madpoo]

Originally Posted by TheMawn

What happened to LL's which were assigned before GPU's came in an changed the optimal factoring levels?

As I understand it, if an exponent is assigned for LL, it won't be re-assigned for TF even if the optimal TF depth has changed since that original assignment.

That's not to say that some folks haven't (apparently) gone through and found some of those and done some extra TF work anyway... There are active LL assignments where a factor was reported in by someone else in the interim.

Technically it looks like the server marks an LL assignment as "expired" when someone else reports a factor for it, but the client doesn't know that and will keep plugging away. I don't know, maybe there's something in the process that alerts a client that a factor was found the next time it checks in, so it won't waste it's time on the LL check... I would hope so anyway.

I'm not sure though... for example, there are 59 LL (first or DC) assignments in the database where the client last checked in *after* the assignment expired, and a factor has been found.

Consider this example:
http://www.mersenne.org/report_expon...exp_hi=&full=1

A factor was found on July 14, and the original LL assignment made in January was expired, but the client continues to check itself in, working on it (it's 9.1% done, as of today, a few hours ago when it last reported in).

Now, if you go to the active assignments page, you won't see it, because that LL assignment is indeed marked as expired, but like I mentioned, the client apparently doesn't know that:
http://www.mersenne.org/assignments/?exp_lo=60721279

The factor was found in the 73-74 bit range by a user running mfaktc...unassigned (poached?). It had also been previously TF'd from 70-73 bit depth by another GPU user, unassigned.

Should we name and shame the TF "poachers"? LOL

(PS - apologies in advance to UncWilly... I'm expecting an "off topic" post any moment now on this...)

[Mark Rose]

Originally Posted by Madpoo

Now, if you go to the active assignments page, you won't see it, because that LL assignment is indeed marked as expired, but like I mentioned, the client apparently doesn't know that:
http://www.mersenne.org/assignments/?exp_lo=60721279

The factor was found in the 73-74 bit range by a user running mfaktc...unassigned (poached?). It had also been previously TF'd from 70-73 bit depth by another GPU user, unassigned.

Should we name and shame the TF "poachers"? LOL

The user in question is a new and heavy throughput user at GPU72. I don't think it was a case of intentional poaching.

[srow7]

The user in question is a new and heavy throughput user at GPU72. I don't think it was a case of intentional poaching.

I did not poach
I work only on what misfit/gpu72.com gives me
my setup is 100% automated.

[chalsall]

Originally Posted by Madpoo

Should we name and shame the TF "poachers"? LOL

I know this was meant in good humour, but just for the record... 60721279 was legitimately owned by GPU72, and given to srow7 for TF'ing. srow7 didn't poach, and GPU72 didn't make a mistake.

The records shown by Primenet on that particular report don't indicate that Qwerty's assignment of 60721279 was converted from the LL assignment which timed out to be a DC assignment.

It is the latter (DC) assignment which fully expired after srow7 found the factor. Unfortunately Prime95/mprime don't appear to understand "bad assignment key" messages once the processing of the assignment is underway.

60721279 LL             0 54 2014-02-28 2014-01-06 2014-01-05 2014-01-05 qwertyfly QwertyBox
60721279 LL LL, 3.10%  13 44 2014-03-03 2014-01-09 2014-01-08 2014-01-05 qwertyfly QwertyBox
60721279 LL LL, 3.10%  56  1 2014-03-03 2014-01-09 2014-01-08 2014-01-05 qwertyfly QwertyBox
60721279 LL             2               2014-08-26 2014-03-09 2014-03-09 wabbit    Manual testing
60721279 LL            69               2014-08-26 2014-03-09 2014-03-09 wabbit    Manual testing
60721279 LL             2               2014-11-09 2014-05-23 2014-05-23 wabbit    Manual testing
60721279 LL            40               2014-11-09 2014-05-23 2014-05-23 wabbit    Manual testing

[Madpoo]

Originally Posted by srow7

I did not poach
I work only on what misfit/gpu72.com gives me
my setup is 100% automated.

Sorry, no offense meant. I realized later that the work being done was probably automatically generated from some lists or another, maybe GPU72 handing them out.

[kladner]

Originally Posted by Mark Rose

The user in question is a new and heavy throughput user at GPU72.....

Wow! No kidding! ~1600 GHzD/D is nothing to sneeze at.

Thanks, srow7, for bringing that kind of power to the project.

[Madpoo]

Originally Posted by chalsall

I know this was meant in good humour, but just for the record... 60721279 was legitimately owned by GPU72, and given to srow7 for TF'ing. srow7 didn't poach, and GPU72 didn't make a mistake.

Correct, it was meant to be a joke... I'm the *last* person who should throw stones... believe me.

I do wonder how GPU72 handed out a TF assignment for an exponent that was assigned to someone else for LL. I'm assuming something didn't go right because I have a feeling GPU72 respects existing assignments... doesn't it use Primenet itself to get the work anyway? So it could have been something on the mersenne.org side that handed that particular one out again for some reason. I don't know...

There are other examples though, so maybe there's some common thread to them all that would explain how it happened and keep it from happening again.

It's kind of nice that factors are found, and if only the client doing the LL test were aware of it, it would *still* save some CPU time, because the LL assignment could stop and move on to another one, but at the sacrifice of losing any "credit" for the work done so far.

If there was some consensus that exponents with an active LL assignments shouldn't be handed out to someone else for deeper TF work, then we'd just want to see what it takes to keep that from happening.

I don't know if it matters or not, but the one example I gave was for a "grandfathered" assignment, before the new recycling rules? Might be irrelevant to this, but in case it mattered.

**** Back on topic ****

I noticed there's just one more 1st time check for an exponent below 52M. I guess that means 2 of those last 3 were either done by the original assignee or someone else snagged 'em. Either way, down to 1 more for that mini milestone.

[Mark Rose]

Originally Posted by kladner

Wow! No kidding! ~1600 GHzD/D is nothing to sneeze at.

Thanks, srow7, for bringing that kind of power to the project.

Makes me want to go out and buy another couple GTX 580's and a box to put them in :D

[Madpoo]

Originally Posted by Madpoo

I noticed there's just one more 1st time check for an exponent below 52M. I guess that means 2 of those last 3 were either done by the original assignee or someone else snagged 'em. Either way, down to 1 more for that mini milestone.

Oh, you know, I think we were looking at exponents in the 52M-54M range, not just to 53M. So there are still those 3 left.

I think I need a timeout. :) Or just stick my nose back into tweaking some reports or getting XML dumps of the daily results.

[retina]

Originally Posted by Madpoo

Oh, you know, I think we were looking at exponents in the 52M-54M range, not just to 53M. So there are still those 3 left.

I was wondering what you were looking at. Those magic mushrooms will do that every time.

[Primeinator]

This

Countdown to double-checking all 2P-1 smaller than 10M digits: 63 (Estimated completion : 2015-02-20)

seems to be falling quite rapidly all of a sudden.

Edit: A lot of the ones remaining are by the same person- GrunwalderGIMP and are all quite a bit overdue even though the assignments are not that old.