When is an exponent considered "started"?

[ric]

A small bit of an annoyance, got a Cat 0 exponent expired and reassigned and just out of curiosity would like to understand why.

Facts:

• on March 18th, I got served 2 exps in the 70.1M Cat 0 range
• one got completed in slightly over 7 days
• the other (M71140417) had a few thousands iterations done, was enqueued for completion - with ETC around 10 days (so well within the requested 30 days for that class)
• as per the Active Assignments page, the candidate was considered started and no sign of incumbent expiry was given
• however this exponent expired and was reassigned today.

Thus, my question to the server pundits here: what's the "minimum" completion percentage to make an exponent truly-truly reserved?

[retina]

Originally Posted by ric

Thus, my question to the server pundits here: what's the "minimum" completion percentage to make an exponent truly-truly reserved?

Well I'm not a "server pundit", but nevermind that sort of thing hasn't stopped me answering questions before.

AFAICT the minimum percentage is 0.1%. So for 70.1M that would be 70.1k iterations.

[thyw]

I remember the same 0.1% too. And IIRC there is some kind of
Found it!: https://www.mersenne.org/thresholds/

Cat 0: Assignments are recycled if assignment is not started with 10 days or when assignment is more than 30 days old.

[ric]

Originally Posted by ric

as per the Active Assignments page, the candidate was considered started and no sign of incumbent expiry was given

I'm well aware of that page, thanks - my point is the (apparent?) inconsistency between an official page deeming the candidate started, and the recycling script deeming it not. Thus the request for a pundit opinion :-)

[Madpoo]

Originally Posted by ric

I'm well aware of that page, thanks - my point is the (apparent?) inconsistency between an official page deeming the candidate started, and the recycling script deeming it not. Thus the request for a pundit opinion :-)

Even though it started, did it check in any progress before it expired? If you're only configured to update progress once daily and you started work on day 10, there's a good chance it expired in that interim.

I also wonder... when it finished the previous assignment, it probably reported that right away so would the server consider that it's daily check-in before any progress had really begun on the next one? No idea.

[Prime95]

The SQL query uses the clause assignment-is-more-than-7-days-old "AND percent_done = 0".

So, did you get the two assignments, do a few iterations of both, rearrange the worktodo.txt?

If so, then the server should have been aware of your progress and given you the full 30 days. Madpoo can comment on why the Active Assignments page considered the exponent started.

If not, then you just barely failed the 7-day expiration rule. In which case, I need to look at the assignments code as you probably should have been given only one cat 0 assignment.


Part of the problem may be due to the fact that I wrote the expiration code and Madpoo wrote the active assignments page with the expected expiration date.

[Madpoo]

Originally Posted by Prime95

The SQL query uses the clause assignment-is-more-than-7-days-old "AND percent_done = 0".
...
Part of the problem may be due to the fact that I wrote the expiration code and Madpoo wrote the active assignments page with the expected expiration date.

In my code to show the countdown of days-to-expire, I'm looking at whether the work "stage" is null or not (in the rare case where an exponent might be getting some TF or P-1 work before the LL starts).

Cases like that would be pretty rare since TF/P-1 work in the current ranges where DC/LL are being assigned have already been done extensively.

That does leave the possibility that an exponent starts and gets only a handful of iterations into it when it checks in... it'll show the stage as being "LL" but the % done would probably be zero (I don't know how it might round up, like would even a single iteration be rounded to 0.1% or would that show as 0)?

In that case, my code would show it as started even though % done is zero, which means the *actual* expiration code doesn't think it's started?

I'm happy to change the expiration function to look at % done and not just whether the stage is null or not, that's an easy change for me and it would align things. It seems like an edge case but if it helps out, we can do that.

[kladner]

Originally Posted by retina

Well I'm not a "server pundit", but nevermind that sort of thing hasn't stopped me answering questions before.

AFAICT the minimum percentage is 0.1%. So for 70.1M that would be 70.1k iterations.

0.1% was my target when I was using P95 to get assignments for GPU processing. I had picked up that number from somewhere on the forum, I think. Doing DC, it was easy to hit that threshold (and report it,) even with an AMD FX. The GTX 460 is also faster with CUDALucas than four real cores of an FX-8350.

[ric]

Originally Posted by Prime95

The SQL query uses the clause assignment-is-more-than-7-days-old "AND percent_done = 0".

So, did you get the two assignments, do a few iterations of both, rearrange the worktodo.txt?

That's what I did. That box is a dual CPU machine, configured to have all cores of each NUMA on a single worker (and BTW that's the reason why I got served 2 Cat 0s). And after some thousand iterations on both, forced communication to the server, verified from the Active Assignment page that it was deemed started (30 days to expire) and then rearranged my worktodo in order to enqueue both on a single NUMA.

Originally Posted by Madpoo

That does leave the possibility that an exponent starts and gets only a handful of iterations into it when it checks in... it'll show the stage as being "LL" but the % done would probably be zero (I don't know how it might round up, like would even a single iteration be rounded to 0.1% or would that show as 0)?

In that case, my code would show it as started even though % done is zero, which means the *actual* expiration code doesn't think it's started?

And that's what mislead me: the "LL" in the completion % (= not zero), and the corresponding 30 days allotted before expiry, both lead me to think that it was safe to keep it as it was. Not! :)

However, mine was certainly an edge case (i *love* chasing after those, at work and elsewhere), lesson learned (the hard way, as it happens) that 0.1% is the minimum safe % to aim for, before rearranging expos.

Originally Posted by Madpoo

I'm happy to change the expiration function to look at % done and not just whether the stage is null or not, that's an easy change for me and it would align things.

If you deem it appropriate, please do so - for the sake of consistency, mainly.

Thanks ya' all :)