[QUOTE=chalsall;401245]Please let us know who's residue you match with (presuming you do). I don't know why I'm listed as one of the attempts -- it didn't pass through the GPU72 proxy....[/QUOTE]

Will do!

Last 3 of the 54M first-time checks
 

I gotta be honest folks, the original assignees of these 3 exponents will not finish them in time:
54357769
54674791
54759797

The first one, despite being 97.9% done, is moving along at 0.0053% per day, with a real ETA of 2016-06-02.

The other 2 haven't checked in at all since April 15th. They might surprise me and check in again sometime soon, but from their previous rate of progress they're still only estimated to finish in March 2016.

All 3 would have expired before then anyway.

The remaining 55M exponents look better, with 55771997 as the exception (projected ETA in Feb 2016). The rest of those might squeak in around May/June of this year.

As near as I can tell, there's no provision for grandfathered assignments to expire after XX days of no contact. They'll only expire once they reach that max of 665 days (assuming they were at 99.9% complete by then).

With the last two 54M numbers only being 67 / 66.2 % done, and taking into account their rate of progress of < 0.01% per day, they'll actually expire around the end of May for 54759797 and the first week of June for 54674791.

I'd estimate 54357769 as expiring closer to it's 665 day max (which is June 17, 2015). By just a couple days... maybe June 15.

It kind of boils down to when they check in, but that's it more or less.

On the other hand, if those last two continue to NOT check in, and their current % done remains unchanged, they'll expire May 25 and May 22 respectively.

In summary, here's my projected expirations (I assume the last two will NOT check in again with any progress beforehand):
54357769 - June 15
54674791 - May 25
54759797 - May 22

They should get reassigned pretty quick... I have my own residues for these ready to check in but I'll do those as double-checks.

[QUOTE=Madpoo;401488]
They should get reassigned pretty quick... I have my own residues for these ready to check in but I'll do those as double-checks.[/QUOTE]

No reason to do that IMO. Just submit your results the day before they would expire. (And perhaps manually verify with the actual expiration that they will indeed expire... or perhaps not.)

We should still continue to assume that these people will complete their test eventually some day, and they can be the double check, rather than wasting their work be re-assigning when we already have a second test complete.

[QUOTE=Dubslow;401500]No reason to do that IMO. Just submit your results the day before they would expire. (And perhaps manually verify with the actual expiration that they will indeed expire... or perhaps not.)

We should still continue to assume that these people will complete their test eventually some day, and they can be the double check, rather than wasting their work be re-assigning when we already have a second test complete.[/QUOTE]

I could do that I suppose.

To come up with the probably expiration dates, I used the same code that it look at to see if it's past the grace period or not (for % of work done), and then also checked to see if the % done would be less-than or greater-than that "grace %" on whatever date.

It was a little tedious and I could have actually done the math, but it was easier for me to just plug in different values in something like this:
(10 + (DATEDIFF (DAY, a.dt_when_assigned, getdate()) - 365) / 3.33)

As in, instead of "getdate()" I'd plug in something like '2015-05-31' and see what the grace % would be on that day, and then using my observed %/day increase see where it would be on that same day. If it's less than the grace % would be on that day, boom, expired.

It's a little fuzzy because these clients don't check in each day, and even if they did it might be unchanged from the last one since it goes in 0.1% increments. Which can take a couple weeks for some of the slowpokes.

That means they might expire sooner. Now, in the last 2 I assumed they wouldn't check in again. The first one has been steadily reporting, just not usually incrementing the % done. We'll see how that goes.

Well, Danny's been poached upon again. At least he still has those 2 poached assignments as DC's.

7 exponents now are left for the sub-56M milestone.

[QUOTE=cuBerBruce;401890]Well, Danny's been poached upon again. At least he still has those 2 poached assignments as DC's.

7 exponents now are left for the sub-56M milestone.[/QUOTE]

[URL="http://www.mersenne.org/M55059383"]M55059383[/URL]

Bummer... I was predicting that one to finish around June 15 (the other two assigned to him I'm predicting June 14 and June 19.

Yeah, when it checks in it'll be a double-check. Good enough I guess.

[QUOTE=cuBerBruce;401890]Well, Danny's been poached upon again. At least he still has those 2 poached assignments as DC's.

7 exponents now are left for the sub-56M milestone.[/QUOTE]

And only 15 left sub-57M. Sub-66M might be the next logical countdown: 8,928 untested exponents remain.

[QUOTE=NBtarheel_33;401927]And only 15 left sub-57M. Sub-66M might be the next logical countdown: 8,928 untested exponents remain.[/QUOTE]

Also, the assignments for 54674791 and 54759797 checked in today... not much different than when they last checked in and the prognosis is even worse, with my own projections of finishing by early in the year 2020. At the current rate they'll expire anyway in just a couple weeks.

The owner of M55861261 has finally completed that assignment after 510.6 days. (Hurray!)

There are now 6 sub-56M assignments (officially) remaining for that milestone.

We'll see if any of the others will be finished before expiring (and hopefully, without poachers interfering). At least two of them appear to be on track to finish before being expired.

[QUOTE=cuBerBruce;402090]The owner of M55861261 has finally completed that assignment after 510.6 days. (Hurray!)

There are now 6 sub-56M assignments (officially) remaining for that milestone.

We'll see if any of the others will be finished before expiring (and hopefully, without poachers interfering). At least two of them appear to be on track to finish before being expired.[/QUOTE]

Here's my latest predictions:
[CODE]exponent RealEta DaysToHardExpire
54357769 2015-11-03 22:54 30.4
54674791 2020-01-05 05:06 14.5
54759797 2020-02-15 18:05 11.8
55027163 2015-06-17 18:18 65.5
55079077 2015-06-21 16:30 62.8
55771997 2016-03-04 02:38 111.5[/CODE]

The "DaysToHardExpire" is how long before it would expire if the client stopped reporting any progress at all from right now, according to the grandfather rules.

[QUOTE=Madpoo;402110]Here's my latest predictions:
[CODE]exponent RealEta DaysToHardExpire
54357769 2015-11-03 22:54 30.4
[/CODE]
[/QUOTE]

Wow, user "Ollum98" must be eating his Wheaties because the assignment for M54357769 is showing a big burst of speed. It had been poking along at something like 0.1% per week (per week!) and then just in the past 3 days it's shot up by 0.8%.

That obviously skews the 30-day trend of it's progress so I can't make a solid prediction. If it can keep up the latest rate of progress though, it *should* finish in just a couple more days since it's at 98.9% right now.