[QUOTE=lycorn;445257]Another milestone I'm looking forward to is "all numbers with exponents less than 1B trial factored to at least 63 bits". We are getting there, slowly but surely.[/QUOTE]

And it's done....as of December 19

[QUOTE=proxy2222;449435]The "Expires (days)" column is incorrect. They will expire next tuesday (2016-12-20) because they have not reported in for 30 days and will get reassigned to somebody else.[/QUOTE]

From the Assignments Rules page:

[QUOTE]Must be completed in 30 days
Assignments are recycled if assignment is not started with 7 days or when assignment is more than 30 days old.[/QUOTE]

These are both over 60 days old.

[QUOTE=petrw1;449556]From the Assignments Rules page:

These are both over 60 days old.[/QUOTE]

Yes but the exponent category limits changes daily so you have to look at the assignment rules for the date the exponents were assigned. So have a look at:

[URL="http://www.mersenne.org/M69827357"]M69827357[/URL] [URL="http://www.mersenne.org/thresholds/?dt=2016-10-05"]Assignment rules 2016-10-05[/URL]
[URL="http://www.mersenne.org/M69946859"]M69946859 [/URL][URL="http://www.mersenne.org/thresholds/?dt=2016-10-14"]Assignment rules 2016-10-14[/URL]

You will notice that they were both Cat 1 in october and - at that time - had 90 days to complete.

[QUOTE=proxy2222;449559]Yes but the exponent category limits changes daily so you have to look at the assignment rules for the date the exponents were assigned. So have a look at:

[URL="http://www.mersenne.org/M69827357"]M69827357[/URL] [URL="http://www.mersenne.org/thresholds/?dt=2016-10-05"]Assignment rules 2016-10-05[/URL]
[URL="http://www.mersenne.org/M69946859"]M69946859 [/URL][URL="http://www.mersenne.org/thresholds/?dt=2016-10-14"]Assignment rules 2016-10-14[/URL]

You will notice that they were both Cat 1 in october and - at that time - had 90 days to complete.[/QUOTE]

Yeah, as far as I know, the "expires in" column on that report should have the correct #. It hasn't been wrong yet.

I looked at the actual expiration process (and also the rules spelled out on the thresholds page) to reverse engineer and figure out when an exponent would expire, based on the current status (whether it had started or not).

As you point out, it also depends on what category it was when first assigned, to a degree.

Negative "time to complete" just means it hasn't updated progress since the last time, and it's previous ETA has come and gone.

I'd been eyeing those two slowpokes, thinking about poaching them myself, but, meh... someone else might anyway.

Plus, if they are allowed to expire, it means those machines will be blocked from getting any future low category assignments for a while. If someone poaches them, they convert to double-checks and haven't technically expired.

Of course their lack of progress means they wouldn't get low category work anyway, but I thought I'd mention that aspect of it.

[QUOTE=Madpoo;449566]Yeah, as far as I know, the "expires in" column on that report should have the correct #. It hasn't been wrong yet.

I looked at the actual expiration process (and also the rules spelled out on the thresholds page) to reverse engineer and figure out when an exponent would expire, based on the current status (whether it had started or not).
[/QUOTE]

Ok, then please explain me why they expired yesterday while they still showed 15 and 24 days before expiration :smile:

I still believe it is a bug because yesterday it should have displayed 0 days instead of 15 and 24 days.

I find it more logically to display the days to normal expiration or if it has not reported in for more than 2 days, display the number of days left before expiration due to not reporting in. Actually, display the Min(daysToNormalExpiry ,daysToExpiryBecauseNotReportedIn)).

Something like this (I'm leaving out the "not started within xx days" parameter for simplicity reasons):

[CODE]

const int DAYS_BEFORE_EXPIRY= 90;
const int DAYS_TO_REPORT_IN = 30;

// Example: 2016-12-20 - 2016-10-24 = 58 days -> 90 - 58 = 32 days
var daysToNormalExpiry = DAYS_BEFORE_EXPIRY - (DateTime.Now - beginDate).TotalDays;

// Example: 2016-12-20 - 2016-11-20 = 30 days -> 30 - 30 = 0 days
var daysToExpiryBecauseNotReportedIn = daysToNormalExpiry;
// Only change this variable if the user has not reported in for at least 2 days
if ((DateTime.Now - dateLastUpdate).TotalDays > 2)
daysToExpiryBecauseNotReportedIn = DAYS_TO_REPORT_IN - (DateTime.Now - dateLastUpdate).TotalDays;

// Return
return Math.Min(daysToNormalExpiry , daysToExpiryBecauseNotReportedIn);[/CODE]

I don't know how everything works but if I understand correctly the calculation on the web page and the calculation on the actual expiration process is not the same. Why not:

1) Add a field "expirationdate" on the exponents table
2) Write a batch program that updates the expirationdate field once a day
3) Perform actual expiration based on the expirationdate field (select * from exponents where expirationdate >= getdate())
4) Display the expirationdate field in the "Expires (days") column

This way, the business logic is in one place and it will improve the performance of your database server as I suppose the current calculation is done in stored procedures.

[QUOTE=petrw1;449529]And it's done....as of December 19[/QUOTE]

Yep. I noticed the long queue of numbers that extends to the left in the first line of [URL="http://www.mersenne.ca/status/"]This Report[/URL] has decreased by one unit of length :smile:.
Well done! Only 1125 left to clear the 63-bit level... :whistle:

[QUOTE=lycorn;449675]Yep. I noticed the long queue of numbers that extends to the left in the first line of [URL="http://www.mersenne.ca/status/"]This Report[/URL] has decreased by one unit of length :smile:.
Well done! Only 1125 left to clear the 63-bit level... :whistle:[/QUOTE]

Your turn?

:smile:

[QUOTE=proxy2222;449659]Ok, then please explain me why they expired yesterday while they still showed 15 and 24 days before expiration :smile:[/QUOTE]

Ah crud. I guess my figurin' needs some figurin'.

[QUOTE]I find it more logically to display the days to normal expiration or if it has not reported in for more than 2 days...[/QUOTE]

I think what I'm missing is that at some point since I added the prediction for "will expire in" info, the rules changed some (thresholds were changed a bit, etc). I think I missed the part about expiring if they haven't reported in for XX days if the assignment is > YY days old. I need to add that part in, otherwise I think I'm good.

The deal is, the expiration of assignments is a job that runs and looks at things as they exist at that moment. There's nothing in place that predicts when assignments will expire. And although that is deterministic based on current state, I still had to figure it out and work it into a SQL function.

Anyway... maybe something to work on over my Christmas vacation. And anyways, now those other two of the 4 remaining exponents have stalled out... hopefully the person running both of those is still going to report in... they are SO CLOSE to being done.

[QUOTE=petrw1;449696]Your turn?

:smile:[/QUOTE]

Unfortunately, I don't think I'll have the means to join any TF effort in the near future...:sad:
I will do my best in the ECM front, but even that won't be much.

[QUOTE=Madpoo;449707]I think what I'm missing is that at some point since I added the prediction for "will expire in" info, the rules changed some (thresholds were changed a bit, etc). I think I missed the part about expiring if they haven't reported in for XX days if the assignment is > YY days old. I need to add that part in, otherwise I think I'm good.[/QUOTE]

I'm having some trouble figuring out exactly how I should go about adding a predicted expiration time to account for machines that haven't reported in.

Most machines will update their work daily... considering a first time cat 1 assignment has 90 days to finish, I can't just "predict" the expiration will always be 29 days out, since that's 30 - (days since last update which is usually 1).

My best guess right now is that at some point, maybe after they haven't checked in for 3 weeks, then I could start an expiration countdown based on that fact alone?

Right now for instance, the days-to-expire for new assignments that haven't started yet have a much lower # since they only get XX days before they *must* start some work. But once they do start, the days-to-expire is extended out to reflect their new status.

This is kind of a reverse situation where the days-to-expire will be longer, and then at some point, when they haven't checked in for a while, all of a sudden the days-to-expire would plummet to however many days.

It's a pickle... I won't do anything for now and wait for feedback. Dunno if there's some option I haven't thought of. I don't want to have two different days-to-expire on that report and have to add something to explain each and have to totally muck with the function to return an array of results or something... it has to perform well and look nice. :smile:

If I had to pick right now, I'd just pick an arbitrary value, like they haven't reported in for 20 days or whatever, and *then* start counting down using that clause. :judge:

[QUOTE=Madpoo;449713]

....

Right now for instance, the days-to-expire for new assignments that haven't started yet have a much lower # since they only get XX days before they *must* start some work. But once they do start, the days-to-expire is extended out to reflect their new status.

This is kind of a reverse situation where the days-to-expire will be longer, and then at some point, when they haven't checked in for a while, all of a sudden the days-to-expire would plummet to however many days.

It's a pickle... I won't do anything for now and wait for feedback. Dunno if there's some option I haven't thought of. I don't want to have two different days-to-expire on that report and have to add something to explain each and have to totally muck with the function to return an array of results or something... it has to perform well and look nice. :smile:

If I had to pick right now, I'd just pick an arbitrary value, like they haven't reported in for 20 days or whatever, and *then* start counting down using that clause. :judge:[/QUOTE]

Two different dates would be very confusing. I'd say you start the countdown halfway at 15 days. The user will be notified earlier and still have another 15 days to report in.

As you already pointed out, the consequence will be that the number of days can skyrocket (when they report in again) or plummet (not reporting in) but this is already the case when a new exponent is reporting in for the first time.

Also, do not forget to always check the normal expiration date. If the exponent is 80 days old (cat 1) and the user has not reported in for 15 days, the number of days should then be 10 and decrease - regardless if he reports back in or not.