I agree with axn, counting the number of tests is not possible until they've already been done. That leaves only one reasonable metric, counting the number of exponents.

[QUOTE=Dubslow;425781]I agree with axn, counting the number of tests is not possible until they've already been done. That leaves only one reasonable metric, counting the number of exponents.[/QUOTE]

Yes, I believe it's simply a count of the # of exponents below M49 that need to be verified. Whether that's one more test, 2 more, 3+ more, who knows, but that's how many are currently unverified.

[QUOTE]Countdown to first time checking all exponents below M(74207281): 77,551 [/QUOTE]

This milestone started at 81,884 on Jan 19th at 15:00 UTC, so it has gone down 8.38 per hour or 201 every 24 hours.
Last 24 hours: -202
Last 7 days: -1445 (-206 per day)

[QUOTE=ATH;425803]This milestone started at 81,884 on Jan 19th at 15:00 UTC, so it has gone down 8.38 per hour or 201 every 24 hours.
Last 24 hours: -202
Last 7 days: -1445 (-206 per day)[/QUOTE]

Seems reasonable according the graph of LL results here:
[URL="http://www.mersenne.org/primenet/graphs.php"]http://www.mersenne.org/primenet/graphs.php[/URL]

Keeping in mind that of the total daily first time checks, most will be below M49 but not all.

I like seeing the # of daily DC's higher than the LL checks, just because DC's are so far behind and have a lot of catching up to do. And they take less time to run so there *should* be more done per day anyway, I think.

[QUOTE=Madpoo;425866]Keeping in mind that of the total daily first time checks, most will be below M49 but not all.[/QUOTE]

You are confusing LLs with DCs.

Most LLs will be below 75M, but not all... :smile:

[QUOTE=chalsall;425868]You are confusing LLs with DCs.

Most LLs will be below 75M, but not all... :smile:[/QUOTE]

And you are confusing M49 with 49M :smile:

[QUOTE=manfred4;425869]And you are confusing M49 with 49M :smile:[/QUOTE]

LOL... :blush:

[QUOTE=manfred4;425869]And you are confusing M49 with 49M :smile:[/QUOTE]

Excellent spotting, I was quite confused as to how that happened :smile:

I'm wrapping my head around the "if then or that then this else if that then this but not that" expiration rules... it's got my brain in a knot but I think I'm making progress.

What I want to be able to do is spit out a simple "days to expire" rather than the ambiguous and ultimately meaningless "age" on the assignment report.

That may help clear up some confusion (my own included) regarding just when an exponent can be expected to be recycled.

In the process I am experiencing some consternation at some rules...

For example, cat 3 and 4 require the work be started within 180 days...fine for them. But there isn't a "must start in XX days" for cat 1 and 2 and I feel like there should be.

Consider this example:
[URL="http://www.mersenne.org/assignments/?exp_lo=63921667"]http://www.mersenne.org/assignments/?exp_lo=63921667[/URL]

It was cat 1 when assigned 64 days ago and hasn't even started on it (or hasn't checked in...same thing from the server's point of view).

Yet it has 90 days before it'll expire... shouldn't we expect that someone who gets cat 1 and has a queue depth of < 10 days would actually *start* this within 10 days? And start within 30 days for cat 2, like they promised to?

Also, from all appearances a cat2-4 assignment won't expire even if it takes more than 150/180/360 days unless that exponent has moved into cat 1 territory by then. So there is a grace period there... a cat 3 assignment that's only cat 2 after a year or two can keep hanging on to it as long as they checked in some progress at all in the first 180 days of the assignment... even if they checked in the next day at 0.1% and then we never saw them again, several years back.

By way of example:
[URL="http://www.mersenne.org/assignments/?exp_lo=68549329"]http://www.mersenne.org/assignments/?exp_lo=68549329[/URL]

It was a cat 4 when assigned 847 days ago (October of 2013). But because it's still not in cat 1 territory it's still there. It just won't die until 68549329 is moved into cat 1.

In fact there are a somewhat surprising # of old cat 3 and 4 assignments that are more than 90 days old but are living in category 2 land right now.

For some, their grace is nearly over... they're very near the cat 1 threshold and after almost 2 years they'll finally have to admit defeat and be recycled.

These, for example, may be recycled in the next day or two after 621 days (and being only 88% done in all that time): M67628417, M67628777

Anyway, surprising stuff in there for me in terms of how these old things seem to linger well past their freshness date.

My immediate thoughts were that cat 1 and 2 need a "start in this many days" clause added in.

The lingering cat 3 and 4 stuff is weird but I know when they hit cat 1 they will recycle so I'm not terribly concerned, it's just weird. But hey, if they can manage to finish it in 18 months and squeak in just before it becomes cat 1, well, good for them, although I wonder what's happening that it's going so slow. I mean, 847 days on M68477317 and it's only 46.5% done? Should we give them until my estimate of July 2017 to finish? LOL :smile:

[QUOTE=Madpoo;425900]I'm wrapping my head around the "if then or that then this else if that then this but not that" expiration rules... it's got my brain in a knot but I think I'm making progress.[/QUOTE]

Here's a real world case with "expires in" times for the LL milestones < 63M:
[CODE]exponent Expires stage % Done Age Last Update Expected Completion
60371299 38 LL 95.4 52 2016-02-10 09:37:40 2016-02-13 12:37:43
60732869 69 LL 67.5 21 2016-02-10 05:23:05 2016-02-17 00:31:57
62259079 3 LL 98.1 87 2016-01-14 16:33:54 2016-01-15 03:37:36
62467271 6 LL 92.1 84 2015-12-28 10:32:23 2015-12-31 05:09:45
62794009 8 LL 76 82 2016-01-14 16:33:53 2016-01-20 14:41:18
62801633 8 LL 82.5 82 2015-12-28 10:32:22 2016-01-03 15:07:03
62900003 9 LL 84 81 2016-01-14 16:21:16 2016-01-17 16:14:34
62920681 9 LL 89.4 81 2015-12-15 09:21:38 2015-12-17 12:29:35[/CODE]

The "expires in" info isn't important in a vacuum... you'd have to look at the % done and ETA to know if it'll finish in time.

[QUOTE=Madpoo;425914]
[CODE]62259079 3 LL 98.1 87 2016-01-14 16:33:54 2016-01-15 03:37:36[/CODE]
[/QUOTE]

I started 62259079, it should finish so I can turn it in just hours before it expires. It is at 88 days now, I assume the day count changes at midnight UTC? or is it exactly at the hour when the user originally got the exponent?

[QUOTE=ATH;425950]I started 62259079, it should finish so I can turn it in just hours before it expires. It is at 88 days now, I assume the day count changes at midnight UTC? or is it exactly at the hour when the user originally got the exponent?[/QUOTE]

It seems to me it changes at UTC midnight. (I recently had an assignment reported as a day old only minutes after I got the assignment.) Once it shows as having an age of 90 days, I believe it has 23+ hours left before it expires.

Aaron or George can you confirm it is recycled at midnight UTC and when the age is changing from 90 to 91 days?

[QUOTE=ATH;425975]Aaron or George can you confirm it is recycled at midnight UTC and when the age is changing from 90 to 91 days?[/QUOTE]

Well, I can't speak for how the expiration works... in my analysis I'm using the date of the assignment compared to the current date using a SQL datediff by day.

It doesn't round up... if the difference is half a day, well, that's "0".

The task to expire things runs around midnight UTC. It may not be on the dot but it probably does, or close enough. I forget.

If that task runs and the datediff between when it was assigned and the time the expire task runs is big enough to make it expire, there you go. :smile:

[QUOTE=Madpoo;426032]
The task to expire things runs around midnight UTC. It may not be on the dot but it probably does, or close enough. I forget.[/QUOTE]

I've definitely seen assignments recycle over half an hour [b]before[/b] midnight UTC. So if you want to do something ahead of an exponent recycling, you probably want to do it around 23:00 UTC.

Yes I will do it before midnight UTC, but the question is, if it is when the age changes from 89 to 90, or 90 to 91.

Right now the variable Age (days) is at 89:
[url]http://www.mersenne.org/assignments/?exp_lo=62259079[/url]

My point is to avoid poaching it as long as there is a chance for the user to turn it in, but turn it in before it is assigned to someone else who might take his time with it.

If you are not sure, then I will wait until 90-91, so we learn how it works.

I turned mine in about 12 hours before Age turned to 91 days, because I had to go to work.

But it has still not expired now 9 hours after the Age turned to 91:
[url]http://www.mersenne.org/assignments/?exp_lo=62259079[/url]

Is it because the user was so close to finishing 98.1% ? That exponent was Cat 1 even back on Nov 15th.

[QUOTE=ATH;426303]I turned mine in about 12 hours before Age turned to 91 days, because I had to go to work.

But it has still not expired now 9 hours after the Age turned to 91:
[url]http://www.mersenne.org/assignments/?exp_lo=62259079[/url]

Is it because the user was so close to finishing 98.1% ?[/QUOTE]

No I don't believe that has anything to do with it.

[QUOTE=ATH;426303]That exponent was Cat 1 even back on Nov 15th.[/QUOTE]

Because it got poached I believe it is now considered a cat 4 DC assignment. If it were not poached, I believe it would have expired instead of becoming a DC assignment. It should expire in about a month if its status isn't updated before then.

Rather than any first time LLs being expired would it be worth changing it to a DC assignment and rereleasing it for LL.
I realize that a lot of those will expire but they would at least be cat 4 DC(and far out).

[QUOTE=henryzz;426541]Rather than any first time LLs being expired would it be worth changing it to a DC assignment and rereleasing it for LL.
I realize that a lot of those will expire but they would at least be cat 4 DC(and far out).[/QUOTE]

That might be a good thing to feed to proven-unreliable machines to stop them from working on relevant assignments.

The last exponent below 61M to be tested at least once ([url="http://www.mersenne.org/M60732869"]M60732869[/url]) has now finished its first LL. It's also the last one below 62M.

Well done.
So Chris has to get rid of the first 2 rows in [URL="http://www.gpu72.com/reports/current_level/"]the table[/URL], and add two at the end. Like 80 and 81M?

[QUOTE=cuBerBruce;426626]The last exponent below 61M to be tested at least once ([url="http://www.mersenne.org/M60732869"]M60732869[/url]) has now finished its first LL. It's also the last one below 62M.[/QUOTE]

Just updated the milestone page (finally... I was out of town).

Perhaps a new Countdown to M66,438,563? All Mersenne numbers less than 20,000,000 digits checked at least once.

All exponents below 63M have now been tested at least once.

Yeah, I have been continuing to "poach" them just a few hours before they are recycled. I do not consider it poaching but I'm sure some disagrees.

A month ago:
[CODE]All exponents below 34,969,871 have been tested and double-checked.
All exponents below 60,371,299 have been tested at least once.

Countdown to first time checking all exponents below 61M: 6 (Estimated completion : 2016-02-11)
Countdown to first time checking all exponents below 62M: 13 (Estimated completion : 2016-02-11)
Countdown to first time checking all exponents below 63M: 25 (Estimated completion : 2016-02-11)
Countdown to first time checking all exponents below 64M: 84 (Estimated completion : 2016-05-12)
Countdown to first time checking all exponents below 65M: 134 (Estimated completion : 2016-05-12)
Countdown to first time checking all exponents below 66M: 200 (Estimated completion : 2016-05-12)
Countdown to first time checking all exponents below 67M: 764 (2 still unassigned)
Countdown to first time checking all exponents below M(74207281): 81,863

Countdown to double-checking all exponents below 35M: 7 (Estimated completion : 2016-02-02)
Countdown to double-checking all exponents below 36M: 5,932 (5,201 still unassigned)

Countdown to proving M(37156667) is the 45th Mersenne Prime: 16,191
Countdown to proving M(42643801) is the 46th Mersenne Prime: 99,202
Countdown to proving M(43112609) is the 47th Mersenne Prime: 108,391
Countdown to proving M(57885161) is the 48th Mersenne Prime: 400,202
Countdown to proving M(74207281) is the 49th Mersenne Prime: 636,148[/CODE]

Today:
[CODE]All exponents below 35,049,317 have been tested and double-checked.
All exponents below 63,012,913 have been tested at least once.

Countdown to first time checking all exponents below 64M: 19 (Estimated completion : 2016-05-31)
Countdown to first time checking all exponents below 65M: 27 (Estimated completion : 2016-05-31)
Countdown to first time checking all exponents below 66M: 38 (Estimated completion : 2016-05-31)
Countdown to first time checking all exponents below 67M: 160 (Estimated completion : 2016-05-31)
Countdown to first time checking all exponents below 68M: 5,316 (4,354 still unassigned)
Countdown to first time checking all exponents below M(74207281): 75,758

Countdown to double-checking all exponents below 36M: 4,131 (3,486 still unassigned)

Countdown to proving M(37156667) is the 45th Mersenne Prime: 12,698
Countdown to proving M(42643801) is the 46th Mersenne Prime: 91,788
Countdown to proving M(43112609) is the 47th Mersenne Prime: 100,506
Countdown to proving M(57885161) is the 48th Mersenne Prime: 388,723
Countdown to proving M(74207281) is the 49th Mersenne Prime: 706,261[/CODE]

The countdown to proving that M74,207,281 is M#49 went up?

[QUOTE=ixfd64;426898]The countdown to proving that M74,207,281 is M#49 went up?[/QUOTE]

not sure if [URL="http://mersenneforum.org/showpost.php?p=425767&postcount=2230"]post 2230[/URL] influenced it or if they tried to do some prediction to a finite degree if Madpoo's 5% or whatever it is now holds up what would the predicted number of tests be or what though 5% at each round of testing failing would only bring it too 669629 by my math in PARI (using suminf(x=0,1/(20^x)) ).

[QUOTE=cuBerBruce;426886]All exponents below 63M have now been tested at least once.[/QUOTE]

Milestone page updated.

[QUOTE=science_man_88;426906]not sure if [URL="http://mersenneforum.org/showpost.php?p=425767&postcount=2230"]post 2230[/URL] influenced it or if they tried to do some prediction to a finite degree if Madpoo's 5% or whatever it is now holds up what would the predicted number of tests be or what though 5% at each round of testing failing would only bring it too 669629 by my math in PARI (using suminf(x=0,1/(20^x)) ).[/QUOTE]

As far as I know it should be correct... it's simply a count of how many exponents below M49 (in this example) are still unverified.

The exponents below it could be checked once, perhaps twice+ with mismatches, but whatever the case, they remain unverified/unfactored.

I can look at the query again and see if I messed something up. I used the same query for M49 that existed for M45-M48 and hopefully I didn't screw it up in some unholy way.

[QUOTE=Madpoo;426911]As far as I know it should be correct... it's simply a count of how many exponents below M49 (in this example) are still unverified.

The exponents below it could be checked once, perhaps twice+ with mismatches, but whatever the case, they remain unverified/unfactored.

I can look at the query again and see if I messed something up. I used the same query for M49 that existed for M45-M48 and hopefully I didn't screw it up in some unholy way.[/QUOTE]

I don't know, it seems okay. I can only guess that something was weird with the result from a month ago that showed the lower value.

It's definitely the type of measurement that should always be going down, never up.

[QUOTE=Madpoo;425900]I'm wrapping my head around the "if then or that then this else if that then this but not that" expiration rules... it's got my brain in a knot but I think I'm making progress.

What I want to be able to do is spit out a simple "days to expire" rather than the ambiguous and ultimately meaningless "age" on the assignment report.[/QUOTE]

I think I've worked out a little "something something" to show expiration dates. On the assignments page for now, and it's showing that instead of the (mostly) useless "Age" column.

Here's an example showing the DC stuff in the 35M-36M range.
[URL="http://www.mersenne.org/assignments/default.mock.php?exp_lo=35049317&exp_hi=36000000&execm=1&exp1=1&extf=1&exfirst=1"]Beta DC assignment[/URL]

And another example with first-time tests in the 63M-67M range:
[URL="http://www.mersenne.org/assignments/default.mock.php?exp_lo=63128917&exp_hi=67000000&execm=1&exp1=1&extf=1&exdchk=1"]Beta LL assignments[/URL]

I haven't fully tested/debugged, but whatever, it's a start.

The way it seems to work out, it seems like cat 3/4 assignments that haven't started at all will expire once they reach their designated "you better at least start in XX days".

Cat 2 assignments don't have anything like that... they don't have to start in a certain time frame, they only expire once the exponent becomes cat 1.

Once any assignments become cat 1, they obey the rules of how many days they should have finished in, according to what category they were in at the time of assignment.

So anyway, I wrote a SQL function to try and take all of that into account and spit out a "Expires" value (in days).

You'll notice, if you try different ranges, that some exponents don't have a value, and that's because they're not cat 1 yet but they've started work, so they can take as long as they want until it becomes cat 1, and there's no way to predict when that would be.

If you see any issues on those "default.mock.php" versions of that page, let me know.

Oh, the "expires" color coding breaks down to anything with 10+ days until expiration are plain black-on-white. If it's between 4-9 days until it expires, it's black-on-yellowish, and <= 3 days, it's white-on-reddish. Just a little visual cue.

I also changed the color on the "ETA" and "Estimated Completion" so it's simply red-on-white if it's more than 3 days past when it said it'd be done instead of the multi-leveled coding the live page has. Nothing too fancy, just another visual cue that there's an assignment that's probably MIA.

If you enter 72M to 72.1M you'll get several undefined variables.

[QUOTE=Madpoo;426987]I think I've worked out a little "something something" to show expiration dates. On the assignments page for now, and it's showing that instead of the (mostly) useless "Age" column.[/QUOTE]

I would say it's the [b]Account Assignment Details[/b] page where changes such as this are really needed.

[QUOTE=Prime95;426988]If you enter 72M to 72.1M you'll get several undefined variables.[/QUOTE]

Whoops. Fixed. Still learning about PHP and its differences between isset and empty. I saw that "empty()" also includes variables where the value is zero, not just null.

Anyway, I set a default font color up front, hope that takes care of it.

[URL="http://www.mersenne.org/assignments/default.mock.php?exp_lo=72000000&exp_hi=72100000&execm=1&exdchk=1&exp1=1&extf=1"]Example 72M - 72.1M[/URL]

[QUOTE=cuBerBruce]I would say it's the Account Assignment Details page where changes such as this are really needed.[/QUOTE]

Could be... if this other page works out okay and I can work out any bugs, there are definitely other places this could be useful.

I'd like to think someone who actually bothers to check on their assignments on the website is going to be on top of things and finish their assignments before expiration, but that's a guess.

[QUOTE=Madpoo;427001]I'd like to think someone who actually bothers to check on their assignments on the website is going to be on top of things and finish their assignments before expiration, but that's a guess.[/QUOTE]

If the page gave better information, maybe...

[QUOTE=cuBerBruce;427002]If the page gave better information, maybe...[/QUOTE]

Besides the estimated days 'til expiration, what else did you have in mind for that page (I assume you're talking about this one: [URL="http://www.mersenne.org/workload/"]http://www.mersenne.org/workload/[/URL] )

Outstanding work on the site ! Thanks to Chris and George and... !
[QUOTE=Madpoo;426987]...
The way it seems to work out, it seems like cat 3/4 assignments that haven't started at all will expire once they reach their designated "you better at least start in XX days".
Cat 2 assignments don't have anything like that... they don't have to start in a certain time frame, they only expire once the exponent becomes cat 1.
Once any assignments become cat 1, they obey the rules of how many days they should have finished in, according to what category they were in at the time of assignment.
...
You'll notice, if you try different ranges, that some exponents don't have a value, and that's because they're not cat 1 yet but they've started work, so they can take as long as they want until it becomes cat 1, and there's no way to predict when that would be.
...[/QUOTE]I think this explanation vindicates the necessity of modifying the assignment rules.
The type of assignments one gets is determined by the the fact that one activates "get the smallest exponents", the "days of work to queue up" settings for each CPU, the reliability of the CPU and a vague promise.

For the categories 1, 2 and 3 assignments there should also be conditions on the timely updates of the server.

Another thing is that expiration should occur not only "when the exponent moves into the first category [b][size=+1]and[/size][/b] the assignment is more than xxx days old" but "when the exponent moves into the first category [b][size=+1]or[/size][/b] the assignment is more than xxx days old". Whether the age should be determined by the category the assignment was in when delivered or by its current category is food for discussion.

Finally shouldn't the category of the assignments a CPU get also depend on it's confidence score and shouldn't the confidence diminish when it does not finish assignments timely ?

Jacob

All categories now have a max amount of days before they expire: [url]http://www.mersenne.org/thresholds/[/url]

DC Cat 1-4: 60days, 100days, 240days, 360days
LL Cat 1-4: 90days, 150days, 270days, 360days

[QUOTE=ATH;427010]All categories now have a max amount of days before they expire[/QUOTE]Not quite true : for the condition on age leading to expiration the exponent must also move to Cat 1.

For instance for category 2 DC assignments "Assignments are recycled when the exponent moves into the first category and the assignment is more than 100 days old." There is an AND between the conditions !

I would like to see "Assignments are recycled when the exponent moves into the first category OR WHEN the assignment is more than 100 days old."

Jacob

[QUOTE=S485122;427007]Outstanding work on the site ! Thanks to Chris and George and... ![/QUOTE]

Indeed, great work! However, for the record, I'm not involved. All the credit should go to Aaron, George and James.

[QUOTE=S485122;427012]I would like to see "Assignments are recycled when the exponent moves into the first category OR WHEN the assignment is more than 100 days old.[/QUOTE]

Why should I be penalized because someone somewhere completed an assignment that has nothing to do with mine? Or be shown leniency because someone somewhere didn't complete an assignment?

Simpler: "Assignments are recycled when the assignment is more than n days old".

This is a more predictable policy.

[QUOTE=chalsall;427013]Indeed, great work! However, for the record, I'm not involved. All the credit should go to Aaron, George and James.[/QUOTE]Indeed I meant Aaron and forgot James (I was too lazy to look up the right names :-(

So, many thanks to Aaron, George and James !

Jacob

Almost all of the site credit goes to Aaron. He is becoming a PHP wizard :)

The reasoning behind the "AND" between "completes in N days" and "moves to category 1" was to give a grace period to users that are checking in regularly (thus presumably making progress) as long as the exponent was no where near the critical milestones. The grace period is beneficial to GIMPS in that even if only a few percent are completed before becoming category 1, then that's a few less DCs the remaining users need to do.

The only downside to the "AND" clause that I can see is that if there were a large number of such cases, cat 2/3/4 users would be getting assigned somewhat larger exponents than they otherwise would be.

To S485122: There is no chance I will change the "AND" to an "OR". If we have cat 2 drifting deep into cat 1 territory before the 100 day deadline, or cat 3/4 assignments drifting down to cat 1 territory before their 240/360 day deadlines, then we need to increase the number of exponents in various categories to make that not happen in the future. Please keep an eye out for such cases. This occurred recently and the number of cat 1 exponents was increased.

Would it be helpful is the assignments page also listed each exponent's category on the day it was assigned?

[QUOTE=Madpoo;427005]Besides the estimated days 'til expiration, what else did you have in mind for that page (I assume you're talking about this one: [URL="http://www.mersenne.org/workload/"]http://www.mersenne.org/workload/[/URL] )[/QUOTE]

Yes, that's the page,

Since the new assignment rules went into effect, I've always felt the the assignment's category number (meaning the range its in when it was assigned) is something thought should appear in this page.

The proposed calculated expiration date would also be nice. The issue with the expiration date as MadPoo described is that it can mislead the user into thinking an assignment has lots of time, but it could move into the cat 1 range the next day and then immediately expire. (I agree that we should not really expect the server to try to predict this date, but I think we can still try to warn the user about this possibility.)

Also, I believe MadPoo's expiration calculation doesn't take into account expiring due to not updating status for 60 days, but taking that into consideration would seem to involve making some assumptions. Maybe that should only be considered if the "next update" date is missed by at least a day, or possibly some number of days (45?) passing since the last update. Or just have a separate way of warning about this case.

Some information might be reflected through highlighting (as in special text or background colors) rather than extra columns:
1) some kind of warning for an assignment that has exceeded its "limit" but hasn't moved into cat 1 yet. Such an assignment could be in danger of expiring "without warning" when it moves into cat 1.

2) some kind of indication if an assignment is nearing cat 1, or maybe displaying what category it would be in if it were just assigned now. Maybe if an exponent is currently in the top 10% (or some other appropriate percentage) of the cat 2 range, some sort of highlighting could warn the user that its nearing the cat 1 range.

3) some indication if the assignment is nearing 60 days without updating (maybe the server already does this and I haven't noticed since I don't tend have assignments in this situation).

One other thought: instead of simply getting rid of the "Age" column, have the ability to toggle the assigned date column to display either the assigned date or the age. These are in some sense just different ways displaying the same information.

[QUOTE=cuBerBruce;427033]Since the new assignment rules went into effect, I've always felt the the assignment's category number (meaning the range its in when it was assigned) is something thought should appear in this page.[/QUOTE]

That could be easy enough to add. I could get creative and color code them into cat 1-4 "colors" rather than add another column... oh, who knows, that might look messy.

[QUOTE=cuBerBruce]The proposed calculated expiration date would also be nice. The issue with the expiration date as MadPoo described is that it can mislead the user into thinking an assignment has lots of time, but it could move into the cat 1 range the next day and then immediately expire. (I agree that we should not really expect the server to try to predict this date, but I think we can still try to warn the user about this possibility.)[/QUOTE]

It's possible, but even if it was a cat 2 when assigned and moved into cat 1 the very next day, they still have a good amount of time to finish. If they got a cat 2 assignment and they already squandered 100+ days for DC or 150+ days for LL without completing it, it expires the moment it moves to cat 1. All I can say is, "oh well". That's the whole point of the expiration rules. For cat 2 they still promise to complete it in a timely fashion, same as cat 3.

You could make the argument that a cat 4 assignment, where no promise was made to complete it quickly, is the most unfortunate because they could get their cat 4 work and then fiddle away for a year, during which time it might move down to cat 1 and then expire. Is it unreasonable to expect a result for a cat 4 assignment to come in within 360 days? I don't think it's unreasonable. Of course they have more time than that if it's still not cat 1 yet.

Given that cat 4 first time tests are above 75.7 M right now, I'd guess it could be more than a year before those become cat 1, so they actually do have extra time.

The other side of it is for cat 3/4 where they at least need to start work on it (and report that fact in) within a certain time frame. Otherwise it sure looks like it's probably been abandoned if we haven't even got a "0.1% done" result within 6 months of assignment.

And it's not "in the past 6 months"... it's whether it reported any work at all within 6 months of being assigned (near as I can tell). It could report progress on day 2 and then not be heard from again for a year and it would still qualify as "having started", according to the language of the rules.

[QUOTE=cuBerBruce]Also, I believe MadPoo's expiration calculation doesn't take into account expiring due to not updating status for 60 days, but taking that into consideration would seem to involve making some assumptions. Maybe that should only be considered if the "next update" date is missed by at least a day, or possibly some number of days (45?) passing since the last update. Or just have a separate way of warning about this case.[/QUOTE]

It does. In reference to my previous paragraph, if an exponent has checked in any progress at all, the clause that it must start within XX days of being assigned is taken care of.

My calculation of the days-til-expiration will take into account two different things:
1) assignments now in cat 1 that have a certain # of days to complete
2) assignments that were originally cat 3 or 4 that have not started at all, and will expire regardless of what category they're in now.

There is that fuzzy zone of originally cat 2 assignments that don't have a requirement to start in a certain # of days. I thought that was odd... an oversight perhaps, or maybe it just didn't matter since they'd be cat 1 sooner than a cat 3 or 4?

[QUOTE=cuBerBruce]Some information might be reflected through highlighting (as in special text or background colors) rather than extra columns:
1) some kind of warning for an assignment that has exceeded its "limit" but hasn't moved into cat 1 yet. Such an assignment could be in danger of expiring "without warning" when it moves into cat 1.

2) some kind of indication if an assignment is nearing cat 1, or maybe displaying what category it would be in if it were just assigned now. Maybe if an exponent is currently in the top 10% (or some other appropriate percentage) of the cat 2 range, some sort of highlighting could warn the user that its nearing the cat 1 range.[/QUOTE]

Maybe. In some of my testing, I experimented with including a "doomsday clock" showing how many exponents away any assignment was from slipping into category 1, but without a way of knowing the rate at which cat 1 exponents are clearing, it would be a wild guess on how far away anything is from becoming cat 1.

On the other hand, if you saw that there are only a dozen or so exponents before your elderly cat 4 becomes cat 1, you'd have an idea you were on the verge of losing it.

I was surprised to see some grandfathered assignments that still live on in the 68M and 69M ranges. They're cat 2 at the moment and so even though they *should* have expired about a year ago even under the grandfather rules, they'll be okay until they turn into cat 1. They won't finish... I ran the #'s... I estimate they'll finish in between 2017 and 2024 in different cases, so they'll definitely bump into cat 1 and vanish before then.

[QUOTE=Madpoo;427037]My calculation of the days-til-expiration will take into account two different things:
1) assignments now in cat 1 that have a certain # of days to complete
2) assignments that were originally cat 3 or 4 that have not started at all, and will expire regardless of what category they're in now.[/QUOTE]

Your point 2) is fine but imo it should always show the days remaining as if it was already moved to Cat 1, if it then happens to be outside Cat 1 when reaching 0 days that just an added bonus for the user.

[QUOTE=ATH;427050]Your point 2) is fine but imo it should always show the days remaining as if it was already moved to Cat 1, if it then happens to be outside Cat 1 when reaching 0 days that just an added bonus for the user.[/QUOTE]
+1. Better alert him earlier, than let it inadvertently expire!

[QUOTE=ATH;427050]Your point 2) is fine but imo it should always show the days remaining as if it was already moved to Cat 1, if it then happens to be outside Cat 1 when reaching 0 days that just an added bonus for the user.[/QUOTE]

I have a feeling that would be confusing, seeing exponents that expire in negative XX days, highlighted in a nasty red warning color. :smile:

The best near term solution I can think of is to do some kind of rule-of-thumb where it might look at the # of exponents left before this particular assignment becomes cat 1. If that # is below 100 or something, it's on the verge of moving to cat 1 very soon, and if it would expire when that happens, show something to generate a sense of urgency for anyone looking at the report to spur them to actually get that work done before then.

And there's the rub... for any of these stats to make sense on the individual account assignment page, there would need to be an assumption that some user has this work assigned to them, they've let it go far too long, and they actually logon to the website and check and this would be their only way of knowing they have assignments in danger of expiring.

I think it's a stretch to assume that any users at all in that predicament would actually be checking the website for their assignments. Because in my utopian brain, people who check that stuff on the website don't let their assignments lapse in the first place.

Call it wishful thinking on my part... I kind of feel like putting that info on the account assignment page wouldn't really benefit anyone, at least in the sense that they'd see an assignment expiring in 7 days and think "oh noes, I better start that!" or whatever. LOL

Not to say I won't add it anyway... I don't think it'll have the outcome you might expect from it. :smile:

You can check out my progress on the /workload/ page here:
[URL="http://www.mersenne.org/workload/default.mock.php"]http://www.mersenne.org/workload/default.mock.php[/URL]

Just added the "expires" column instead of the "age". No color coding in there... it just is what it is. I realized I never added the sorting on this table either so I might slip that in later.

[QUOTE=Madpoo;427090]Just added the "expires" column instead of the "age". No color coding in there... it just is what it is. I realized I never added the sorting on this table either so I might slip that in later.[/QUOTE]

I like it!!! Thanks! :tu:

Edit: I just thought of something which might be worth considering: move the "Expires" column over to be immediately to the left of "Days to go", and colour code one or the other (or both) of the cells if the former is less than the latter.

[QUOTE=Madpoo;427090]The best near term solution I can think of is to do some kind of rule-of-thumb where it might look at the # of exponents left before this particular assignment becomes cat 1. If that # is below 100 or something, it's on the verge of moving to cat 1 very soon...[/QUOTE]

One thing you might consider would be something like what I do for the [URL="https://www.gpu72.com/reports/estimated_completion/primenet/"]Estimated Completion[/URL] report. This was created to make sure GPU72 wasn't biting off more than it could chew.

Basically it calculates how long the work would take assuming all the firepower was being concentrated on a particular 1M range. The firepower available is calculated based on the past 30 days of production.

You would probably want to take into consideration the production rate of the different categories. Cat 1 has only completed ~30 candidates a day for the last 30 days, for example, while Cat 3 has completed ~171 a day. There is almost no Cat 2 work being assigned (as far as I can tell).

Thus, the transition from Cat 2 to Cat 1 is going to be a lot slower than what might be expected.

What happens to a CPU that has a cat 1 assignment expire? Can it still get cat 1 assignments? Surely if CPUs expire exponents they shouldn't be able to get that cat anymore.

[QUOTE=henryzz;427095]What happens to a CPU that has a cat 1 assignment expire? Can it still get cat 1 assignments? Surely if CPUs expire exponents they shouldn't be able to get that cat anymore.[/QUOTE]

[URL="http://www.mersenneforum.org/showpost.php?p=424582&postcount=2222"]http://www.mersenneforum.org/showpost.php?p=424582&postcount=2222[/URL]

Yeah...
[QUOTE]...To me that means weeding out the folks who tick that box but let exponents expire anyway. That *should* be part of the criteria in getting these cat 1 (or even cat 2) assignments... people with a proven track record (over the course of the past few months) of not letting things slip...[/QUOTE]

[QUOTE=Madpoo;426987]I think I've worked out a little "something something" to show expiration dates. On the assignments page for now, and it's showing that instead of the (mostly) useless "Age" column.[/QUOTE]

I've just made this new page "live". I had to fix one other minor display bug... if the ETA days was zero, it was blank on the report. Just had to jujitsu some PHP and now it shows zero correctly.

[QUOTE=Madpoo;427230]I've just made this new page "live". I had to fix one other minor display bug... if the ETA days was zero, it was blank on the report. Just had to jujitsu some PHP and now it shows zero correctly.[/QUOTE]Is that the same for blank expiry dates?

e.g. [url]http://www.mersenne.org/assignments/?exp_lo=67914299&exp_hi=67914299&execm=1&exp1=1&extf=1&exdchk=1[/url]
Expires in <blank> days.

Many more like that also.

[QUOTE=retina;427232]Is that the same for blank expiry dates?

e.g. [url]http://www.mersenne.org/assignments/?exp_lo=67914299&exp_hi=67914299&execm=1&exp1=1&extf=1&exdchk=1[/url]
Expires in <blank> days.

Many more like that also.[/QUOTE]

Blank days-to-expire means it's not cat 1 yet and it's started (even if it's only like 0.1%). So it won't expire unless it's cat 1 *and* hasn't finished in the time specified.

If I "pretended" everything was cat 1 and showed the expiration dates as if that were true, there'd be a heckuva lot of exponents with negative expiration dates, making it meaningless. Or you wouldn't be able to tell which exponents will *really* expire compared to ones that would expire "if they were cat 1". :smile:

[QUOTE=Madpoo;427280]If I "pretended" everything was cat 1 and showed the expiration dates as if that were true, there'd be a heckuva lot of exponents with negative expiration dates, making it meaningless.[/QUOTE]

This wouldn't be a problem if you implemented the heuristical methodology I proposed above.

Separately, one thing I noticed in the report is candidates which are soon to be recycled because of no check-in recently doesn't seem to be incorporated in your formula.

I understand that someone who hasn't checked-in in a week or so shouldn't be listed as soon to expire. But perhaps after thirty days or so should start seeing a count-down.

[QUOTE=chalsall;427282]This wouldn't be a problem if you implemented the heuristical methodology I proposed above.

Separately, one thing I noticed in the report is candidates which are soon to be recycled because of no check-in recently doesn't seem to be incorporated in your formula.

I understand that someone who hasn't checked-in in a week or so shouldn't be listed as soon to expire. But perhaps after thirty days or so should start seeing a count-down.[/QUOTE]

As far as I could tell (just from the language of the assignment rules page itself), as long as they report in sometime in the first however many days, even if it was the same day as the assignment, they have no obligation to check in ever again until it becomes cat 1 and crosses the #-of-days threshold.

There isn't a "must have checked in within the past XX days" rule, although it could be argued there should be something like that for cat 1 & 2, but that's a "whole nuther" topic. :smile:

I haven't checked to see how the expiration code actually works in practice, i.e. when that nightly task runs, what is it looking at... but for purposes of my little function, I assume an assignment has started if it's "stage" is not null. When an assignment is made, the percent done is set to 0 and the "stage" is null. It only updates that stage to TF, ECM, LL or whatever if it's actually started that stage, even if the percent is still zero.

I could have looked at the difference between when it was assigned and when it was last updated, but there's actually a slight difference in those times anyway, by a few milliseconds, as it sets the "last updated" time during the initial assignment process. Ideally it would have used the same timestamp if it did all that SQL stuff in one batch, but it's actually being done in different parts.

So then it became a comical thing of "well, let's say it won't be considered as checking in if there's less than 2 seconds difference"... agh. I have a feeling the expiration code does what I'm doing and just seeing if it's started work on any particular stage of an assignment.

That's how you can know from the assignment page if it's actually done anything... is the "stage, % done" column blank or not.

If it's blank, then it will follow the "must start within XX" days countdown, and it *should* be showing that info.

However, curiously, there's no requirement on cat 1 or cat 2 assignments that they have to start within X days. Of course if it was a cat 1 assignment to start with, they get however many days already. But cat 2 assignments don't have to start on it or do anything at all and nothing will happen until it's cat 1. Theoretically if progress halted for some reason, cat 2 assignments could live on indefinitely even if they're never heard from again after getting the assignment. :smile: But yeah, eventually they'll become cat 1 at which point those cat 2 assignments would expire in 100 or 150 days.

Personally I think cat 2 work should start within 30 days, or else why is that person saying they agree to get small exponents and have a work queue <= 30 days? 30 days means 30 days. Could even argue that cat 1 assignments should start in 10 days or they expire, for the same reason. If your "days of work" queue is <= 10 days, well, this new assignment you just got better have started in 10 days, or I'm calling you a big fat liar. LOL

(I say that jokingly, but... yeah... I know that Prime95's estimates can be wrong, but usually in the direction of thinking things will take longer than actual; it doesn't normally estimate times that are faster than actual).

And that's also the reason I'd exclude someone from getting cat 1 & 2 work if they've let 2+ assignments expire in the past few months. Clearly they missed the plain text: "Assigned to users that promise to complete assignments quickly." Letting exponents expire is a sign that their promise means nothing. :smile:

But maybe I'm being too harsh... all I know is, people wouldn't really even be tempted to poach those kinds of things if the assignments were going to reliable systems in the first place.

In the grander sense, who cares if exponents finish in any kind of order, as long as they all get done, but in a human sense, people like to see the mile markers zip past in their rear view mirror... gives a sense of accomplishment that you just wouldn't have if you took the shotgun approach and assigned stuff randomly and it finished "whenever".

[QUOTE=Madpoo;427298]As far as I could tell (just from the language of the assignment rules page itself), as long as they report in sometime in the first however many days, even if it was the same day as the assignment, they have no obligation to check in ever again until it becomes cat 1 and crosses the #-of-days threshold.[/QUOTE]

I believe the "must report at least every sixty days" clause was inherited from the previous recycling behaviour. This is with the exception of manually assigned candidates which get 180 days (unless they're extended).

[QUOTE=Madpoo;427298]In the grander sense, who cares if exponents finish in any kind of order, as long as they all get done, but in a human sense, people like to see the mile markers zip past in their rear view mirror... gives a sense of accomplishment that you just wouldn't have if you took the shotgun approach and assigned stuff randomly and it finished "whenever".[/QUOTE]

I agree, it doesn't really matter /that/ much. But, the new assignment rules were initially created to try to lessen the temptation to "poach". Before there were some assignments in lower ranges with ridiculous assignment age!

[QUOTE=retina;427232][url]http://www.mersenne.org/assignments/?exp_lo=67914299&exp_hi=67914299&execm=1&exp1=1&extf=1&exdchk=1[/url]
[/QUOTE]

Is this a security breach that we can see the user id?

There got to be a reason why we have both user id and display name.

Edit: never mind, it is Display Name, the column is just labeled Userid. LOL

[QUOTE=chalsall;427093]You would probably want to take into consideration the production rate of the different categories. Cat 1 has only completed ~30 candidates a day for the last 30 days, for example, while Cat 3 has completed ~171 a day. There is almost no Cat 2 work being assigned (as far as I can tell).

Thus, the transition from Cat 2 to Cat 1 is going to be a lot slower than what might be expected.[/QUOTE]

The assignment rules show how many exponents are expected to be in each category... for first time checks, for example, there should always be 4000 exponents in cat 1, and then I can't tell if it's 6000 in cat 2, or if it's the next 10,000 in cat 2? Hmm... cat 3 has the next 100K (either 100K itself, or 100K minus the 10K of cat 1 and 2?)

The fact that a small 4000 cat 1 assignments is being cleared at a snails pace tells me too many are taking too long, or not enough people signed up to do them?

If I look at the current crop of exponents that are *now* cat 1, here's how their *original* categories break down:
cat 1 = 797
cat 2 = 55
cat 3 = 23

Apparently there are a bunch of cat 1 assignments that are up for grabs but not assigned... hmm... all in the 67M - 68M range. I guess there aren't that many people signed up to do first time cat 1 work after all? ~3100 available LL cat 1 exponents...

Well, I guess that's fine because the cat 1 workers who really are doing them in a timely fashion will have a steady pool of them.

[QUOTE=TObject;427314]Is this a security breach that we can see the user id?

There got to be a reason why we have both user id and display name.

Edit: never mind, it is Display Name, the column is just labeled Userid. LOL[/QUOTE]

Yeah, it's display name... I could change the column header to just "user" or something.

[QUOTE=chalsall;427300]I believe the "must report at least every sixty days" clause was inherited from the previous recycling behaviour. This is with the exception of manually assigned candidates which get 180 days (unless they're extended).[/QUOTE]

It would behoove me to look at how the nightly task *actually* expires things, rather than base my assumptions on the descriptions... I looked at the code once and at the time it was so full of "if this then that or else if that then this except this or that until that or this"...

I kind of shied away from it. :) Now that I have a little better base understanding of the rules it might not be as intimidating and I could see if it's doing anything else in there that's not described in the assignment rule page.

[QUOTE=Madpoo;427317]The fact that a small 4000 cat 1 assignments is being cleared at a snails pace tells me too many are taking too long, or not enough people signed up to do them?[/QUOTE]

I suspect it's the latter; almost by definition it can't be the former... :wink:

This brings up a thought... What about the system giving out cat 1s or 2s automatically (read: even when the user hasn't promised) if the requesting machine's history is both good (as in it reports regularly) and candidate turn-around is relatively quick?

I know Aaron, easier said than done, but it would "make sense".... :smile:

[QUOTE]Apparently there are a bunch of cat 1 assignments that are up for grabs but not assigned... hmm... all in the 67M - 68M range. I guess there aren't that many people signed up to do first time cat 1 work after all? ~3100 available LL cat 1 exponents...
[/QUOTE]
I am signed up for cat 1, but I have been doing only DC for some time. :smile:

[QUOTE=kladner;427356]I am signed up for cat 1, but I have been doing only DC for some time. :smile:[/QUOTE]

There's lots of cat 1 DC work as well, so you're good. :smile:

[QUOTE=Madpoo;427317]Apparently there are a bunch of cat 1 assignments that are up for grabs but not assigned... hmm... all in the 67M - 68M range. I guess there aren't that many people signed up to do first time cat 1 work after all? ~3100 available LL cat 1 exponents...[/QUOTE]

By definition, there will always be 4000 available LL cat 1 exponents. If I get a cat 1 exponent, then #4001 will become #4000 and move from cat 2 to cat 1. Doesn't matter if there are infinity people crunching cat 1. (It would matter how/when the server performs the readjustment of category definition - i.e. instantly, once a day, once a week, etc.)

You need to look at how many active assignments are there that we assigned _as_ cat 1 (and get distinct users and distinct computers for those assignments).

Also,you can't sign up for cat 1 or cat 2 or cat 3, specifically. You sign up for "smallest exponents", and then based on the individual computer performance, the computer will receive 1 or 2 or 3 appropriately. So you should be able to count the users who have this flag turned on, directly from the database without looking at the assignments.

[QUOTE=axn;427363]...
Also,you can't sign up for cat 1 or cat 2 or cat 3, specifically. You sign up for "smallest exponents", and then based on the individual computer performance, the computer will receive 1 or 2 or 3 appropriately. So you should be able to count the users who have this flag turned on, directly from the database without looking at the assignments.[/QUOTE]Once a user signs up for "get the smallest exponents" the category of exponents assigned depends only on its setting "days of work to queue up", not on its performance.

Jacob

[QUOTE=S485122;427367]Once a user signs up for "get the smallest exponents" the category of exponents assigned depends only on its setting "days of work to queue up", not on its performance.

Jacob[/QUOTE]

Going by the definitions here ([url]http://www.mersenne.org/thresholds/[/url]), it is one of the criteria, but there are others, including the assignment completion rate (what I meant by "performance").

[QUOTE=Madpoo;427317]The assignment rules show how many exponents are expected to be in each category... for first time checks, for example, there should always be 4000 exponents in cat 1, and then I can't tell if it's 6000 in cat 2, or if it's the next 10,000 in cat 2? Hmm... cat 3 has the next 100K (either 100K itself, or 100K minus the 10K of cat 1 and 2?)[/QUOTE]

[url]http://www.mersenne.org/thresholds/[/url]

Today Cat 2 ends at 68651924 and Cat 3 at 75765578, you can do a quick search and see if those limits are for first 4k+6k or 4k+10k and 100k/110k/114k?

[QUOTE=ATH;427371][url]http://www.mersenne.org/thresholds/[/url]

Today Cat 2 ends at 68651924 and Cat 3 at 75765578, you can do a quick search and see if those limits are for first 4k+6k or 4k+10k and 100k/110k/114k?[/QUOTE]

Well, I don't know what this means exactly, but as of right now, here are the counts of the # of *available* exponents in each LL category:

cat 1 = 3108
cat 2 = 1915
cat 3 = 15285

Assuming that it resets each night and sets the threshold so that, for example, the first 4000 *available* exponents are the new cat 1 range, 3108 right now means nearly 900 cat 1 assignments were handed out since then.

That doesn't seem right though. In fact, by my count, only 14 of the cat 1 LL stuff was assigned today so far.

There have been zero cat 2 assignments today and 114 cat 3.

EDIT: In other words, I think the "4000" for cat 1 includes assigned and available together, not merely the "available" pool.

Cat 1: 3108 available + 875 assigned = 3983 (close to 4000)
Cat 2: 1915 available + 3678 assigned = 5593 (close to 6000)
Cat 3: 15285 available + 7663 assigned = 22948 (close to 23000?)

Why are they off by a handful of exponents... no idea.

Anyway, that does suggest that cat 1 = 4000, cat 2 = another 6000, and cat 3 presumably would be another 90K, so I'm not sure why the cat 3 count is so off. Maybe my quick query for the totals is missing something. I was just guessing that *assigned + available" are the only factors involved in deriving the total... could be something else the actual algorithm is taking into account.

Well, something to explore later I suppose.

[QUOTE=Madpoo;427385]EDIT: In other words, I think the "4000" for cat 1 includes assigned and available together, not merely the "available" pool.

...

Anyway, that does suggest that cat 1 = 4000, cat 2 = another 6000, and cat 3 presumably would be another 90K, so I'm not sure why the cat 3 count is so off.[/QUOTE]

Are you remembering to count the TF and P-1 assignments? My understanding is each category boundary is calculated based solely on the number of LL candidates outstanding, regardless if they are assigned (for whatever worktype) or not.

And yes, it's 4K, then 6K, then 90K.

[QUOTE=axn;427363]By definition, there will always be 4000 available LL cat 1 exponents. If I get a cat 1 exponent, then #4001 will become #4000 and move from cat 2 to cat 1.[/QUOTE]

Not true.

At approximately 0:00 UTC primenet checks how many candidates haven't yet been LL'ed, and calculates the boundaries from that. Even if every single cat 1 candidate was assigned (which would imply the offset needs to be increased) the boundary would still be at 4,000, and those requesting cat 1 would in fact be given cat 2.

[QUOTE=chalsall;427389]Not true.

At approximately 0:00 UTC primenet checks how many candidates haven't yet been LL'ed, and calculates the boundaries from that. Even if every single cat 1 candidate was assigned (which would imply the offset needs to be increased) the boundary would still be at 4,000, and those requesting cat 1 would in fact be given cat 2.[/QUOTE]

So actual category limits change when assignments are _completed_?

[QUOTE=axn;427392]So actual category limits change when assignments are _completed_?[/QUOTE]

Correct.

[QUOTE=Madpoo;427385]Cat 1: 3108 available + 875 assigned = 3983 (close to 4000)
Cat 2: 1915 available + 3678 assigned = 5593 (close to 6000)
Cat 3: 15285 available + 7663 assigned = 22948 (close to 23000?)[/QUOTE]

BTW... I suspect you'll find that something like 90% of the 3,678 cat 2 candidates currently assigned were originally cat 3. Very few cat 2s are being assigned.

[QUOTE=Madpoo;427385]Well, I don't know what this means exactly, but as of right now, here are the counts of the # of *available* exponents in each LL category:[/QUOTE]

I meant a "simple" Milestone calculation. Right now Cat 1 ends at 67651470, which is the same as saying:
Countdown to first time checking all exponents below M(67651470): 4,000

Cat 2 ends at 68651924, so one of these is true depending on if Cat 2 is 6K or 10K by itself:
Countdown to first time checking all exponents below M(68651924): 10,000
Countdown to first time checking all exponents below M(68651924): 14,000

The reason is it not exact is that it is only calculated once per day. Todays threshold was calculated yesterday at 11:20 pm UTC ( [url]http://www.mersenne.org/thresholds/?dt=2016-02-25[/url] ), so everything happening since has changed the counts slightly.

[QUOTE=chalsall;427396]BTW... I suspect you'll find that something like 90% of the 3,678 cat 2 candidates currently assigned were originally cat 3. Very few cat 2s are being assigned.[/QUOTE]

Very good assumption. I checked to see... list of the cat 2 stuff and what their *original* category was:

cat 2 = 1
cat 3 = 3622
cat 4 = 37

Now... why is this? Is it a function of not enough people signed up to get the smallest exponent (and/or not meeting the other requirements like reliability and days-of-work in their settings)?

It wouldn't be a terrible idea to just automatically assign these cat 1 & 2 things to systems who meet certain criteria even if they haven't explicitly checked the box. If that happened I'd definitely exclude any systems that have had assignments expire in the past however many months.

I suppose if something like that worked well, we could just get rid of that "opt in" altogether.

But hey, that's just me... I could work on that but ultimately I will never futz with assignment stuff without a thumbs-up from George, and he or James would probably be the ones to implement it in the end. Those parts of the web code scare me. :smile: One errant semicolon from a PHP novice like myself could have disastrous results.

[QUOTE=ATH;427399]IThe reason is it not exact is that it is only calculated once per day[/QUOTE]

Derp, that'd be right. I'm sure if I included the "cat 1" results that came in since midnight it would roughly fill the gap.

[QUOTE=Madpoo;427404]It wouldn't be a terrible idea to just automatically assign these cat 1 & 2 things to systems who meet certain criteria even if they haven't explicitly checked the box. If that happened I'd definitely exclude any systems that have had assignments expire in the past however many months.

I suppose if something like that worked well, we could just get rid of that "opt in" altogether.[/quote]

I think that's a good idea.

[QUOTE=Madpoo;427404]Now... why is this? Is it a function of not enough people signed up to get the smallest exponent (and/or not meeting the other requirements like reliability and days-of-work in their settings)?[/QUOTE]

I suspect this is it -- there are many capable machines owned by people who didn't click the "promise" button, and thus are being given cat 3.

Unfortunately, some who _did_ click the button perhaps shouldn't have... :wink:

[QUOTE=Madpoo;427404]It wouldn't be a terrible idea to just automatically assign these cat 1 & 2 things to systems who meet certain criteria even if they haven't explicitly checked the box. If that happened I'd definitely exclude any systems that have had assignments expire in the past however many months.

I suppose if something like that worked well, we could just get rid of that "opt in" altogether.[/QUOTE]

I think this would be a really good idea, realizing there would be some coding work and testing involved...

It could be argued the whole "you have to promise" was experimental in the beginning, to avoid people being caught off guard and having their assignments be reassigned sooner than they were used to (at the time, effectively assignments /never/ expired!).

Perhaps now that things have settled to a relatively stable state, we can look at the ~30 Cat 1s being completed a day compared to ~170 Cat 3s and conclude that more Cat 1s should be assigned to those who haven't "promised".

Machine performance heuristics would be key. And, at the end of the day, if a few LLs get reassigned the worst that happens is few early DCs are done. The project doesn't lose any throughput.

How many cat 3 assignments are manual assignments?

[QUOTE=owftheevil;427440]How many cat 3 assignments are manual assignments?[/QUOTE]

That would be a /very/ interesting statistic. I would also be interested in knowing how many manual assignments are in the cat 4 range, particularly true "anonymous" assignments.

To put on the record (again), I still think it is silly that some random person can surf by the Primenet website, and reserve many (sometimes MANY!) candidates which almost certainly will never even be started let alone completed, but are then held up for 180 days.

[QUOTE=owftheevil;427440]How many cat 3 assignments are manual assignments?[/QUOTE]

Hmm... that would have been interesting, unfortunately I don't see a way to know whether assignments were done through the manual assignments page or by a client automatically.

On results there's a way to tell, but not assignments.

EDIT: Oh wait, there is a way to tell, kind of... the computer that got the assignment will always have a name of "Manual Assignments"... So, okay, there is a way, just an extra join on my lookup. Stay tuned, I'll see what I can find.

Okay... (for first time LL work):
Originally cat 3 assignments = 7,893 of which 214 were manually assigned (none from truly anonymous users)
Originally cat 4 assignments = 24,178 of which 6244 were manually assigned (2399 of those from truly anonymous users)

[QUOTE=Madpoo;427508]Hmm... that would have been interesting, unfortunately I don't see a way to know whether assignments were done through the manual assignments page or by a client automatically.[/QUOTE]

How do the [URL="http://www.mersenne.org/assignments/?exp_lo=75851099&exp_hi=75852223&execm=1&exdchk=1&exp1=1&extf=1"]public reports[/URL] know to show "Computer: Manual testing" under the Userid column popup for some (but not all) Anonymous (and other) users?

Wouldn't the same conditional apply? And I think owftheevil and I are talking about currently assigned, not completed.

Edit: Whoops. Cross-post.

By the way, this is some inside-baseball stuff (sorry, stupid American term), but I'm just shaking off the dust from my brain after looking into the whole "confidence level" and "reliability index" that Primenet tracks for each CPU.

Before I lose that train of thought (and since I'll likely forget it, so I'll "archive" the knowledge here)...

Basically Primenet tracks two things for each CPU to help determine how well it's doing. A reliability index between 0 and 1, and a confidence level between 0 and 10.

A new computer starts out with a confidence level of zero (because it hasn't done anything), but a reliability index of 1 (because we start out assuming it will only ever return good results).

When a result is returned, there is a temporary reliability value set of:[LIST][*]Matches a previously verified result = 1.0 (new result matches the already confirmed residue)[*]Does not match a previously verified result = 0.0 (mismatches the confirmed residue, so we know it's bad)[*]Unverified and "clean" = 0.98 (no critical errors reported during the run)[*]Unverified and "suspect" = 0.5 (had some error that makes it suspect)[/LIST]
This temporary reliability value is for just this one result and it's used to help adjust the overall reliability and confidence stats.

The new reliability is a function of:
(old value * confidence + temp reliability) / (confidence + 1)

If we take the example of a new system where the reliability is assumed to be 1, confidence is zero, and they just returned a clean unverified result, we plug those in as:
(1 * 0 + 0.98) / (0 + 1) = new overall reliability of 0.98

The confidence value gets adjusted as:
if confidence < 10 then confidence = confidence + 1

So... yeah, as near as I can tell, the confidence level goes up whenever you turn in a result, up to a max of 10, no matter what. Suspect, clean, verified, unverified, bad...

Going back to our example, this user returns a second clean result, so we get:
(0.98 * 1 + 0.98) / (1 + 1) = new overall reliability of 0.98

So as long as they keep returning clean unverified stuff, they'll stay at 0.98 for their reliability... all good. And weird because the only way it can go higher is if you're doing triple-checks of already-verified results (hey, been there, done that). And yes, there are systems with a perfect 1.0 reliability which could only come from *only* doing triple-checks and always matching.

It's only if you start turning in suspect results or if you (why?) turn in a mismatched residue for an already verified result that you'll dip below 0.98. And yes, it happens.
e.g. [URL="http://www.mersenne.org/M35498293"]M35498293[/URL]

It's important to note that the reliability is apparently not affected when you have an old result, and someone turns in a result later on that confirms yours as either good or bad (which should use a value of 1.0 or 0.0 for that formula if it were to do so).

To get a preferred first time LL test, you need a confidence level of 2 (at least 2 results returned) and a reliability of 0.9

In reality that's only going to weed out systems that have returned 2 at all, since the CPU entry was added, and as long as they haven't had any suspect results, or turned in a lot of clean stuff to offset any suspect.

There is also a CPU speed requirements of 2GHz or better, plus the already known limit on how many days of work can be in your queue (<= 10 days), and the 2 results have to be recent.

When I look at computers that meet all the normal criteria for getting first time checks, but also include how many expired assignments or how many bad results they've had in the past 120 days, it paints an interesting picture.

One system, for example, is still active (last seen 1 day ago), has 11 recent results, confidence level of 10, reliability of ~0.98, good CPU speed.

But by my additional metrics... they also have 3 expired assignments in that timeframe, their CPU rolling average is a pretty low 667 (probably from running 4 workers on 4 cores, which is safe to say is inefficient at 4M FFT).

Another example... system meets all the requirements. Reliability is a bit lower at 0.94, and that makes sense because in the past 120 days they've had 14 results bad, so I'd assume they turned in some suspect results in that time as well (that user has been doing doublechecks, so no real risk right now to the LL leading edge).

Basicaly, of the 728 CPUs (not users... cpus) that could get cat 1 LL right now, I'd exclude 48 of them based on having recent expirations or recent bad results.

If I were to automatically opt-in systems, there would be 5179 eligible under the existing rules, but if I weed out the ones with recent expirations or bad stuff, then subtract 294 from that.

But forget the current rules... I looked for machines that are even more awesome:[LIST][*]3 results in the past 90 days (one a month)[*]10 days in the work queue (same as now)[*]Rolling average of 1500 or higher (no strangely slow systems)[*]No expired work in the past 90 days[*]No (known) bad results in the past 90 days (doesn't help if they're fast but buggy)[*]Seen in the past 30 days (still active... this is just for estimating the pool of eligible systems)[/LIST]
So I didn't even look at the confidence or reliability values for this... I found it better to estimate based on the past 90 days worth since the reliability doesn't take into account any results that were later proven one way or the other.

With those rules I've whittled it down to 595 cpus, but these are systems that I could be fairly sure are going to crank away at the work and not let them hang.

If I bump it to 120 days of history and only 2 results in that time, it's 1069 cpus. Or if I then also set the min rolling average to 1000, the pool grows to 2033 systems.

In my opinion, rolling averages below 1000 indicate a system that really isn't running optimally. Just my 2 cents.

So... that's my investigation in a very large nutshell and I wanted to share the results. :smile:

[QUOTE=Madpoo;427547]So... that's my investigation in a very large nutshell and I wanted to share the results. :smile:[/QUOTE]

_Very_ interesting! Thanks for the look under the hood.

Your various heuristical metrics as applied to the current empirical dataset are also informing. Clearly Cat 1 could easily be more appropriately serviced if one of your metrics were applied to the assignment code.

Edit: Just thought of something... Perhaps implement something like the "3 results in 90, rolling average of 1500" metric for Cat 1 and the "2 results in 120, average of 1500" metric for Cat2? Handy because the rolling average variable is easy to tweak over time.

Any internal discussion as to if this will be implemented?

[QUOTE=chalsall;427583]Any internal discussion as to if this will be implemented?[/QUOTE]

Right now this is just me taking a look to see what the options are. If it seems like these new criteria would be useful, my next step would be to just create a SQL function to spit out a result on whether the CPU is good for cat 1, cat 2, etc. Then that could be tied back into the assignment stuff as either supplemental or replacing the part that lets it know if it's eligible for preferred assignments.

[QUOTE=chalsall;427583]_Very_ interesting! Thanks for the look under the hood.

.....

Any internal discussion as to if this will be implemented?[/QUOTE]
No real discussion here. I just want to compliment the most thorough explanation of certain metrics in P95 that I have ever seen.

Thanks, Aaron! :tu:

[QUOTE=chalsall;427583]Perhaps implement something like the "3 results in 90, rolling average of 1500" metric for Cat 1 and the "2 results in 120, average of 1500" metric for Cat2? Handy because the rolling average variable is easy to tweak over time.[/QUOTE]

I rather object to the Rolling Average of 1500 requirement. It seems to me Rolling Average is not a good measure of actual productivity.

I have two machines with very similar productivity in terms of GHz-days/day, but their respective rolling averages are currently 1389 and 678, respectively. Both machines have been getting cat 1 LL assignments and completing them well before the expiration time for cat 1 LL. It perhaps could be argued that these machines are at a performance level more suited to cat 2, but I certainly don't think it makes sense to demote them to cat 3, which would be what Chris's proposal would cause them to get, at least based upon their current Rolling Average values

The one with the lower Rolling Average is a laptop with thermal throttling issues that limits its overall throughput. I use a Throttle setting to try to keep thermal throttling from slowing down the processor too much, and set its hours/day setting to approximately compensate for that. But I guess my main point is two machines with similar overall throughput have two very different Rolling Average values (and both are below the 1500 value).

On the other hand, I am also guessing I could change some settings (such as the hours/day value) and possibly get a quite different Rolling Average value. I then might get them to meet the required threshold while doing nothing as far as their actual productivity. But it seems kind of silly to me to have to do this.

[QUOTE=Madpoo;427547][*]Rolling average of 1500 or higher (no strangely slow systems)[/QUOTE]

How is this rolling average calculated? My Haswell-E 5960X has "RollingAverage=1112" in local.txt and it is faster than most "normal" systems, except your big Xeon servers with lots of cores.

Edit: I found the answer myself in this old thread: [url]http://www.mersenneforum.org/showthread.php?t=8652[/url]

So this is not an comparable estimate of overall speed, it is just measuring how fast your computer is running compared to how fast Prime95 assumed it would be running, and if you set the "Hours per day this program will run" to less than 24 hours and then run it 24 hours anyway you can inflate the rolling average up to a max of 4000.

Rolling average is not a reliable measure. On my i7-5820K it is at 3600 and the computed completion dates are realistic. Sometimes, after Prime95 is restarted the rolling average drops to around 1000 which gives unrealistic completion dates. Those fluctuation of that value have existed for a long time...

Jacob

[QUOTE=S485122;427625]Rolling average is not a reliable measure.[/QUOTE]

OK, fine. Then we use a different metric. Perhaps simply the number of completions over the last (say) 90 days.

The revised algorithm is simply being discussed at this point. Let's converge on what would (or, at least, might) work best, and maybe give it a whirl.

[QUOTE=chalsall;427640]OK, fine. Then we use a different metric. Perhaps simply the number of completions over the last (say) 90 days.

The revised algorithm is simply being discussed at this point. Let's converge on what would (or, at least, might) work best, and maybe give it a whirl.[/QUOTE]

Yeah, the rolling average, to me, is a quick and dirty way of assessing whether the system is performing at "expected" speed.

I'd certainly consider anything below 1000 to be underperforming since that's the definition of the metric itself...it should be near 1000 (although it's typically higher in my experience).

I know it's inaccurate as heck but it's better than nothing. Maybe 1500 is too much to expect, but I think it should still be above 1000.

I get what cuberbruce is saying about the one system that has a rolling average of 1389, but the one that's at 678 I would humbly suggest is not ideally suited for cat 1 assignments.

Technically I suppose it's still (probably) cable of completing a first time LL assignment in 90 days, or a DC in 60 days, but it's (literally) a half-hearted attempt. :smile:

I should be less controversial... LOL... if the assignment completes in the 60/90 days reqiured, I suppose that's all that matters.

[QUOTE=Madpoo;427656]Yeah, the rolling average, to me, is a quick and dirty way of assessing whether the system is performing at "expected" speed.[/QUOTE]

On reflection, after looking at some actual stats on machines that are eligible to get cat 1 work right now and then looking at their rolling averages, it really is all over the place.

There are systems with unusually low rolling averages, like one with 82. It's completed 2 results in the past 120 days though, and a CPU speed of 2.8 GHz.

No idea why it's rolling average is so low... that's really bizarre. If Prime95 isn't even running, that's fine, it won't affect the rolling average, you just won't be getting any progress. So something must be happening there that it's going so slow when it's actually running. Thermal throttling, something else taking nearly all the cycles, etc.

All I know is, the rolling average is kind of a snapshot in time... if it's low for some spurious reason, it won't stay low once things are back to normal. But if it's really *SUPER* low like < 500, maybe getting cat 1 isn't the best idea for it right then? Next time it gets an assignment it might be just fine and there'll be no problems.

Anyway, besides using that as a quick metric, reported by the client itself, the other option is to look at the # of results over a period of time.

There's probably some clever calculation I could do to take the rolling average, cpu speed, and the ratio of cores to workers into account and come up with a "performance factor" that could approximate how many LL or DC results it would be expected to clear in a set period of time.

It's also worth noting that a system might have completed a couple of smaller double-checks in the past 120 days, which would then qualify it to get a larger first time LL cat 1 assignment, but there's no basis to assume that completing a couple smaller tests at the rate of one every 2 months means it can complete a 67M exponent in 3 months time.

See the problem there? When looking at the past # of results in some time frame, the *size* of those tests should be calculated... were they similar in size to the type of work they want (DC or LL)?

So there is that aspect to it I hadn't considered until just now... If/how to judge suitability for first time LL assignments if their recent history only has smaller DC exponents...

A system that can barely do 1 DC test every 2 months is not likely to be able to do a single cat 1 LL test in 3 months...

I don't know if that's actually an issue. Someone doing DC work will probably stick with that, but then again someone doing DC might be looking for a change and ask for first time tests and they may not be up to that task.

Hmm... maybe just looking at the ghz days they've done in the past 120 days instead of just how many results they've turned in.

[QUOTE=Madpoo;427657]There are systems with unusually low rolling averages, like one with 82. It's completed 2 results in the past 120 days though, and a CPU speed of 2.8 GHz.

No idea why it's rolling average is so low... that's really bizarre. If Prime95 isn't even running, that's fine, it won't affect the rolling average, you just won't be getting any progress. So something must be happening there that it's going so slow when it's actually running. Thermal throttling, something else taking nearly all the cycles, etc.[/QUOTE]

If "Hours per day this program will run" is set to 24hours but the user is only running it 2 hours per day: 1000* 2/24 = 83

That is why this is a poor metric for speed since it is so dependent on that variable being correct.