[QUOTE=axn;519316]True, but it is a weekend's work for preda to bring back LL to gpuowl, if there really is a need for it.[/QUOTE]Really? I think a higher priority use of his time would be to make P-1 in gpuowl work better; possible at all on NVIDIA, or possible in Windows on 4GB or 8GB AMD gpus, for example. But, his time, his call.

What is wrong with all these exponents? All by the same person on top of that.[SIZE="1"][CODE]84768809 LL [COLOR="Red"]-120 [/COLOR] 2019-01-01 2019-01-01 2019-06-20 Hugemon
84768839 LL [COLOR="red"]-120 [/COLOR] 2019-01-01 2019-01-01 2019-06-20 Hugemon
84768863 LL [COLOR="red"]-120[/COLOR] 2019-01-01 2019-01-01 2019-06-20 Hugemon
84768949 LL [COLOR="red"]-120[/COLOR] 2019-01-01 2019-01-01 2019-06-20 Hugemon
84769219 LL [COLOR="red"]-120[/COLOR] 2019-01-01 2019-01-01 2019-06-20 Hugemon
84769303 LL [COLOR="red"]-120[/COLOR] 2019-01-01 2019-01-01 2019-06-20 Hugemon
84769351 LL [COLOR="red"]-120 [/COLOR] 2019-01-01 2019-01-01 2019-06-20 Hugemon
84769459 LL [COLOR="red"]-120[/COLOR] 2019-01-01 2019-01-01 2019-06-20 Hugemon
84769693 LL [COLOR="red"]-120 [/COLOR] 2019-01-01 2019-01-01 2019-06-20 Hugemon
84769819 LL [COLOR="red"]-120[/COLOR] 2019-01-01 2019-01-01 2019-06-20 Hugemon[/CODE][/size]

I dont think he's working on GIMPS anymore

[QUOTE=petrw1;520383]I dont think he's working on GIMPS anymore[/QUOTE]

Yeah, but shouldn't all those exponents been reassigned?

[QUOTE=rudy235;520385]Yeah, but shouldn't all those exponents been reassigned?[/QUOTE]
I think yesterday they showed one day to expiration. This is the last batch of hugemon's out of 26 laggards between 84M and 85M in as I recall 3 different assignment dates and no indication of progress on any of them (so presumably all manual assignments).

[QUOTE=rudy235;520382]What is wrong with all these exponents? All by the same person on top of that.[SIZE="1"][CODE]84768809 LL [COLOR="Red"]-120 [/COLOR] 2019-01-01 2019-01-01 2019-06-20 Hugemon
84768839 LL [COLOR="red"]-120 [/COLOR] 2019-01-01 2019-01-01 2019-06-20 Hugemon
84768863 LL [COLOR="red"]-120[/COLOR] 2019-01-01 2019-01-01 2019-06-20 Hugemon
84768949 LL [COLOR="red"]-120[/COLOR] 2019-01-01 2019-01-01 2019-06-20 Hugemon
84769219 LL [COLOR="red"]-120[/COLOR] 2019-01-01 2019-01-01 2019-06-20 Hugemon
84769303 LL [COLOR="red"]-120[/COLOR] 2019-01-01 2019-01-01 2019-06-20 Hugemon
84769351 LL [COLOR="red"]-120 [/COLOR] 2019-01-01 2019-01-01 2019-06-20 Hugemon
84769459 LL [COLOR="red"]-120[/COLOR] 2019-01-01 2019-01-01 2019-06-20 Hugemon
84769693 LL [COLOR="red"]-120 [/COLOR] 2019-01-01 2019-01-01 2019-06-20 Hugemon
84769819 LL [COLOR="red"]-120[/COLOR] 2019-01-01 2019-01-01 2019-06-20 Hugemon[/CODE][/size][/QUOTE]

There was a funny bug in my code that estimates the countdown to expiration. I've mentioned before that assignments can expire for different reasons at different times. For example, a category 2 assignment (like those were originally) have 180 days to complete. But they can also expire earlier if it didn't start in a certain amount of time (unless it was manually assigned, like those happened to be).

So when I show the expiration for an assignment, which one should I choose?

Anyway, that wasn't the problem here... I was calculating the correct expiration (0 days) for them, since it had been 180 days since they were assigned. But then I still had some old code that calculated expirations differently based on when it last checked in and when it was next expected to check in. When these were assigned, it set the next check-in date to June 20th, and my code was triggering the alternate method when it was 10 days past the next check-in date.

Just so happened to be the day it expired anyway so by the time I started looking into it, they were gone, but I figured it out anyway.

Removed the old code - I didn't see anything in the current rules about expiring if it goes X amount of days past it's expected check-in date.

Anyway, just a display thing. I explained to ATH, who brought it to my attention today, that the actual expiration routine is just something that runs daily and looks at all the criteria and is simply a pass/fail. There's nothing stored anywhere that has a hard date on when assignments expire, since they can and do fluctuate based on conditions that can't be predicted. :smile:

TL;DR, the ETA for expiration is merely an estimate. I want it to be correct, but don't set your watch by it. :smile:

[QUOTE=Madpoo;520426]So when I show the expiration for an assignment, which one should I choose?[/QUOTE]
The earliest applicable one!

[QUOTE=axn;520428]The earliest applicable one![/QUOTE]

This ^^

BTW, is there a way to exclude "bad actors" from getting anything other than cat 5? People that have >5 exponents that are cat 1 or 0 that have 0 work on them is not acceptable.

[QUOTE=rudy235;493919][ATTACH]18959[/ATTACH] January 3rd 2018




[ATTACH]18960[/ATTACH] Today August 14[SUP]th[/SUP] 2018[/QUOTE]

In the 42,000,000 to 50,000,000 Row for the OneLL We went from 86K to 46K and now to <10K
It should be approx. 8 months more to get this number down to "0"

[QUOTE=Uncwilly;520510]This ^^

BTW, is there a way to exclude "bad actors" from getting anything other than cat 5? People that have >5 exponents that are cat 1 or 0 that have 0 work on them is not acceptable.[/QUOTE]
Cat 5 as in cat infinity = no assignments allowed? Or did you mean cat 4?
[URL]https://www.mersenne.org/thresholds/[/URL]

I concur that having lots of assignments sit for months with no progress during the long wait for expiration and reassignment is undesirable. But so would be assignment churn and premature expiration when manual assignments are in fact quietly progressing while the primenet server is unaware of any progress.

It sure would be nice to be able to submit progress reports for long-running manual assignments, such as by manually submitting a gpuowl or cudalucas console output line. These could be restricted to be at a multiple of 10[SUP]7[/SUP] iterations, so that interim residues could be captured for comparison. Gpuowl parsing could be complicated since there have been so many variations in format. It might help parsing if submissions included application and version explicitly also, eg "CUDALucas v2.06" or "Gpuowl v6.5" or "Gpuowl V3.8" preceding the console output record, or there was a menu selection for the supported manual interim report types, and the server side parsing allowed for the occasional possibility that the iteration coincides with a GEC (with the record containing OK and a check time field also).

CUDALucas v2.06 sample:[CODE]| Jun 13 14:52:42 | M79341173 10000000 0xf827ee51567eccd2 | 4608K 0.04980 6.2177 310.88s | 4:23:31:26 12.60% |
[/CODE]Gpuowl V6.5 sample:[CODE]
2019-06-07 17:58:41 332419523 OK 10000000 3.01%; 16.406 ms/sq; ETA 61d 05:20; b5f673876655f696 (check 17.07s)[/CODE] Gpuowl V3.8 sample: [CODE]2019-02-09 06:11:34 condorella-rx550 10000000/83411351 [11.99%], 14.52 ms/it [14.51, 14.54] (19.2 GHz-day/day); ETA 12d 08:09; 5760d09cf49a8245
[/CODE]Gpuowl v5.0 sample: [CODE]2018-11-05 05:34:37 89000167 10000000 11.24%; 4.52 ms/sq, 0 MULs; ETA 4d 03:06; 2ada1450d0f5801c
[/CODE]

[QUOTE=Uncwilly;520510]This ^^

BTW, is there a way to exclude "bad actors" from getting anything other than cat 5? People that have >5 exponents that are cat 1 or 0 that have 0 work on them is not acceptable.[/QUOTE]

Once they have some exponents that expire due to taking too long, they won't get any future cat 0/1/2 assignments. Those categories stipulate that they can't have any expired assignments in the past 120 days (4 months).

They might get cat 3 if they've still met the requirement that indicates it's likely to finish in 90 days, although they do actually get 270 days to complete.

Cat 4 is when they don't meet any of those other requirements, and they get work that gives them a year to finish.

Sometimes a cat3 assignment takes long enough that eventually it becomes category 1 or even zero. That shouldn't normally happen because the categories themselves are on a sliding scale, and use a moving average to determine where the category 0/1 assignments will be, 90 days from now. Sometimes we're super awesome and start moving through those categories quicker than the average predicted, so you get the occasional outliers. But it'll self adjust in the long run.

So far we've been doing pretty good with the new assignment rules. My memory may be faulty on this, but for the last few milestones, I think we've avoided having any "stalled" assignments holding things up. Those were generally being expired well ahead of when we actually got down to the last few in the queue. If I remember right.

In other words, it wouldn't have changed when we reached a particular milestone if we tried to be more aggressive on expiring those assignments that were obviously not running... the system took care of them as designed.

It was more common under the old rules to have some milestone waiting on a handful or more of assignments that were clearly not being worked on.