[QUOTE=Madpoo;387832]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...[/QUOTE]

I tried to explain what happened.. The assignment was "recycled" by Primenet, and the candidate was then available for LL assignment; but, importantly, the original assignment was still in the Primenet database, but as a DC assignment. GPU72 then (legitimately) picked it up, and gave it to srow7 to TF.

When srow7 reported the factor, Primenet then canceled the DC assignment.

[QUOTE=chalsall;387874]I tried to explain what happened.. The assignment was "recycled" by Primenet, and the candidate was then available for LL assignment; but, importantly, the original assignment was still in the Primenet database, but as a DC assignment. GPU72 then (legitimately) picked it up, and gave it to srow7 to TF.

When srow7 reported the factor, Primenet then canceled the DC assignment.[/QUOTE]

Well, I won't pretend I know what happened with any earlier assignments... the Primenet DB doesn't show all historical assignments, necessarily... once an assignment reports in as usual, the assignment is cleared. The only "historical" assignment records are the ones where it expired for whatever reason, before completion. My only point was that it was assigned to someone for LL work (first or DC didn't seem to matter), and during that period when it was assigned to someone and being worked on, a TF result was checked in. The assignment on it for LL work was in January, so it should have been operating under the grandfathered rules, and in fact the server hasn't expired it for any other reason than that a factor was checked in by someone else... it wasn't expired due to recycling rules.

If you're saying Primenet assigned that TF work out even though there was an active LL/DC assignment, I believe you, I really do. :smile: I just didn't think the server would assign the same exponent twice, even if one was for LL/DC work and one was for TF/ECM/P-1. The *only* time an exponent can be assigned to multiple people is for ECM work, as far as I can tell.

My main point is that it seems counter-productive, no matter how it happened, and we would probably want to make sure those kinds of things don't crop up too often?

In my defense, the server did in fact mark that LL assignment as "poached" using it's own internal flagging codes... assignments can be expired for 4 different reasons:
Poached (someone else checked in a result that supersedes this assignment...either another double-check or a factor-found)
No Contact (expired because the client didn't check in in the timeframe required, 60 days, *and* it's 10 days past due)
Assignment Rules (expired due to the recycling rules in effect)
Manually Extended (this is kind of a special case... the assignment was manually extended so it's in a kind of limbo for an extra xx days)

The "poached" definition is only saying that Primenet had it assigned to someone, and someone else checked in a result... that's all. I suspect there must have been some confusion going on if Primenet handed that assignment out to someone else while it was still assigned to someone, and it was definitely a first-time LL assignment (nobody else has checked in an LL result for it), so I'm not sure why you show it got converted to a DC at some point? That would only be the case if a first-time LL assignment was out there, and someone else checked in a result first. That original LL assignment is "converted" to a DC just by definition, although a peek in the database would still show it was originally assigned as a first time check.

Sorry to go into such detail... maybe the extra info will be helpful in peeking under the cover at how the machine works. :)

I think Chris is saying the original LL was recycled. Since the exponent is grandfathered and not in the critical range, I think the only reason it would expire is due to no contact for 60 days. The server would then downgrade the assignment to a DC marked with the internal expired due to "no contact" code.

Chris/GPU72 then grabbed the LL assignment and sent it out for more factoring. When a factor was found, the server then overwrote the internal "no contact" code with the "poached" code. I suppose, we could add a new internal code: "expired and then rendered unnecessary", but seems like a lot of bother to me.

If the above is what actually happened, then everything took place as expected.

[QUOTE=Prime95;387895]If the above is what actually happened, then everything took place as expected.[/QUOTE]

The above is what happened.

[QUOTE=chalsall;387898]The above is what happened.[/QUOTE]

I surrender. :smile: I will freely admit I was wrong to even suspect GPU72 or srow7 of doing anything wrong.

I think this is just one of those crazy cases where an exponent was thought to be abandoned and thus recycled, but then the user started work on it anyway at some later point.

I was curious how often that happens, and it seems to happen with some frequency?

For example, I just queried how many assignments (LL and DC) are out there where:
a) The assignment is expired
b) The user has updated the assignment 30+ days after the expiration
c) That update from the user was at some point after Oct. 1 2014 (this year)

5042 such assignments.

Of those 5042 that are still curiously chugging away on their work, 28 of them have had factors found.

Those 28 are the odd ones because whatever reason for their original expiration (I assume it was a no-contact or the general recycling rules), once a factor was found by a subsequent assignment, like what we were talking about, that original expiration reason was updated to show it was "poached" (but not really).

Even if I expand my search criteria to exponents that were updated *60* or more days since expiration, to account for machines that are just really out of touch or don't get online that often, there are still 4355 of them and 22 with a known factor.

I guess I shouldn't worry about it, but then I think of all those clients out there chugging away on an LL assignment, and unbeknownst to it, the server is already aware that it's composite.

At least with the other ones where no factor has been found, once they do (if ever) report in, it'll still be useful for a first, second or sometimes third LL test.

As I understand it, Primenet will see these "expired" assignments check in, and I think as long as work has already started on it, there's nothing built in to tell the client to stop even if a factor is known.

I'm pretty sure that's by design... I remember back when I started poaching some exponents (long ago, when it was probably a lot more controversial and I was more of a doofus) I would start work on some poached assignment "offline", let it run a few iterations, and then transfer it to an "online" Primenet connected machine. At that point Primenet would no longer unassign any poached exponents and remove them from my worktodo like it would if work hadn't started on it yet. :smile:

It'll probably happen some more... some of those "active but also expired" exponents in the 40M-50M range have only been TF'd to 69 bits so I imagine they'll get processed by GPU72, maybe, for extra TF work (sorry, I don't know what the GPU72 TF cutoffs are for different ranges).

And again, apologies to Chris and srow7 ... mea culpa.

[QUOTE=Madpoo;387914]And again, apologies to Chris and srow7 ... mea culpa.[/QUOTE]

Hey no problem.

We're all rather intense around here; frankly it's nice being able to be intense in a space without immediately being accused of being mean. :smile:

[QUOTE=chalsall;387919]Hey no problem.

We're all rather intense around here; frankly it's nice being able to be intense in a space without immediately being accused of being mean. :smile:[/QUOTE]

Whatever, jerkface. :smile: (yes, I had to reach WAY down deep into my inner 7-year old for that gem of an insult... and by the way, I'm rubber and you're glue...)

EDIT: in case anyone is confused, YES, I'm kidding around :)

[QUOTE=Madpoo;387914]I was wrong to even suspect GPU72 or srow7 of doing anything wrong.[/QUOTE]
This time...
:razz:

[QUOTE=Madpoo;387914]I guess I shouldn't worry about it, but then I think of all those clients out there chugging away on an LL assignment, and unbeknownst to it, the server is already aware that it's composite.[/QUOTE]

If they did not report in for 30 or 60 days and then starts working (very slow I guess) on the exponent, then apparently they do not really care about it. Most of them do not even know they are still running Prime95, the running applications are hidden by that damn little white arrow nowadays unless you turn it off, which most "standard" users do not know how to do or that they need to.

Think of all the lost performance and used RAM by all the "shit" every application leaves running in the memory and all the damn browser toolbars. I have been helping so many "standard" users with their computers over the years and have seen it all.

[QUOTE=ATH;387958]If they did not report in for 30 or 60 days and then starts working (very slow I guess) on the exponent, then apparently they do not really care about it. Most of them do not even know they are still running Prime95, the running applications are hidden by that damn little white arrow nowadays unless you turn it off, which most "standard" users do not know how to do or that they need to.[/QUOTE]

Who knows... it's weird though.

I was experimenting yesterday with modifying the assignments page to show expired assignments as well... it's interesting to see just how many there are in certain ranges, but overall not that useful. And I can see in the table there the same thing I was mentioning, where an assignment is expired but the client keeps checking in results.

Oh well though... like I said, most of that work will still be useful, assuming they finally finish. It may be reassigned to someone else for a "first time check" and then it's just a race over which one is first, which one is the double-check.

I guess if one of these happened to be the next Mersenne Prime there could be some discussion there... whoever tested it first would get the credit, but the original assignee might be upset. But hey, it is what it is, the rules are what they are.

An example is this one: [URL="http://www.mersenne.org/M53042401"]http://www.mersenne.org/M53042401[/URL]

Assignment expired on Oct. 22 and was reassigned to someone else, but the original assignee has continued to check in results on a daily basis, as recently as this AM. The original user is at 71% done, but the new assignee is already at 55% and will probably finish first.

Don't know what to say though... that original user got the assignment back in April of 2013, 593 days ago. It could well be argued that if you can't complete an LL assignment in the 53M range in over a year, you're not trying hard enough and the recycling makes sense. This user was given a year and a half before it recycled, so I don't feel bad for them. At best it means that assignment gets a double-check farther ahead of the current DC assignments. At worst (for that user) it's the next prime and they missed their shot at glory. :)

[QUOTE=Madpoo;387997]
I was experimenting yesterday with modifying the assignments page to show expired assignments as well... it's interesting to see just how many there are in certain ranges, but overall not that useful. [/QUOTE]

The database has only kept the expired assignment info since the new assignment rules went into effect 9 months ago. I would expect to see most of the "expired but still checking in" exponents in the cat 1 DC and cat 1 LL area or low 30Ms and low 50Ms. But as you pointed out they had well over a year to reach a result. I'd bet most of these people don't even know prime95 is running on the computer.