[QUOTE=Madpoo;456613]The current/original "cat" is for "category". I didn't know if/how useful sorting by "age" was (you can still sort by assignment date which gives the same sort order). Knowing the original and current category (0 through 4) plus the estimated time until the exponent expires seemed more useful, but cramming more columns in meant purging some that didn't seem as useful.

And you mentioned seeing the exponents close to expiring... now you can sort on that column. Technically some work you have is probably overdue but it won't really expire until it gets into the lower categories of work, so it'll only show the "hard" expiration.

[...]
[/QUOTE]
Thanks much for the rundown, this helps too.

Two notes:

[LIST=1][*]I can sort the assignments by date, but this doesn't give an indication of how urgently the assignments need to be finished. (See #2 below.) And under the "Assigned" column, all the dates are exactly the same number of characters in length. This nearly uniform visual cue isn't as useful as being able to notice at a glance, while scrolling up and down the page, that some TF assignments are one digit "old," others are two digits "old," and a few are three digits old (= danger zone).[*]I have several thousand assignments, more than 99 percent of them manual TF. However, the only assignment type that seems consistently to show any data in the "Expires (days)" column are the double-checks. If feasible, this would be a great column to populate with "days to go" information for TFs, which are the ones I manage by hand. Filling that column would help to serve a similar purpose as the removed column that used to show how many days old an assignment is: one could visually scan for TFs that show only two digits in the column.[/LIST]
I guess I'm coming at this from the perspective of someone whose main work is TF. I can understand how in some ways the "Account Assignment Details" page is geared toward people who do other types of work.

Anyway, just my 2 cents. I appreciate the critical work you put into maintaining the site.

[QUOTE=Rodrigo;456653]I guess I'm coming at this from the perspective of someone whose main work is TF. I can understand how in some ways the "Account Assignment Details" page is geared toward people who do other types of work.

Anyway, just my 2 cents. I appreciate the critical work you put into maintaining the site.[/QUOTE]

The problem I have is, I can't find any info on how/when a TF assignment would expire. LOL

I figure technically they would (and I'll take a look at the expiration code tonight to see), but in practical terms they probably wouldn't.

TF assignments are [B]SO[/B] far ahead of any DC/LL work that for all intents and purposes, a TF assignment would actually never expire because it would never hold up any "category 0-4" DC or LL work. And that's really all it cares about.

Admittedly, someone who gets a bunch of TF assignments and hangs onto them for a long time is going to frustrate others who might want to get those same exponents assigned (like they're working ranges of exponents to bring them up another bit level, or want to do P-1 on insufficiently worked exponents).

That's what makes me think there just might be something that looks at TF work, but I'm not sure.

I just checked... then again, maybe there isn't an expiration for TF. Here's the oldest active TF assignment:
[M]95644621[/M]

EDIT: Looking closer, it [I]might[/I] be expiring TF work if they haven't checked in for 6 months (180 days).

[QUOTE=Madpoo;456722]EDIT: Looking closer, it [I]might[/I] be expiring TF work if they haven't checked in for 6 months (180 days).[/QUOTE]

Okay... I looked at the daily expiration task, and while LL / DC have their own expiration rules (the thresholds page), other work types have a pretty basic expiration:

[CODE]If the assignment hasn't checked in for >= 60 days
[B]AND[/B]
the date it was next expected to check in is >= 10 days past due, it expires.
[/CODE]

Right now there are some VERY long lived TF assignments (over 3 years!) but the person keeps checking in... I know... you'd think after 3 years they might have made some kind of start.

Besides TF assignments, for those who like trivia, here is the current oldest assignment... over 8 years. But still kicking!
[M]332197309[/M]

There's actually also a special rule for 100M digit LL assignments that looks like this:
[CODE]If the exponent is between 330E6 and 350E6
[B]AND[/B]
(primenet assignment that last checked in over a year ago
[B]OR[/B]
manual assignments that are 1000 days past their next expected check in)
[/CODE]

There's a (temporary?) clause for the 100M exponents where it currently won't expire them even if they're super old as long as they've progressed more than 2% on the LL stage. George's note is right, that should probably be removed. :smile:

An example of that would be:
[M]332202181[/M]

It was assigned in Feb 2010, was last updated in August of 2015 and was expected to check in the following day but never did. It would have expired by now except it got to 81.2% done before vanishing.

There are only 50 assignments that would expire now if that little clause was removed so not a big deal. The most "recent" of those last reported in back in July 2015.

Reportedly, the server is giving bad worktodo lines for Fermat number F12, omitting most of the already-known factors. See [URL="http://www.mersenneforum.org/showthread.php?p=457011#post457011"]this thread[/URL].

This might be the cause of the bogus already-known factors for F12 (exponent 4096) that constantly appear in the [URL="https://mersenne.org/report_recent_cleared/"]Recent Cleared list[/URL].

:tu: Good point!

So I recently grabbed a bunch of very high TF assignments through the manual_gpu_assignment page.

User sasaki turned in some of the same exponents while I have been working on them, such as [url=https://www.mersenne.org/report_exponent/?exp_lo=918373097&full=1]918373097[/url]. The exponent status page shows duplicate results, and I also end up with weird double entries on the /results/ page for the poached exponents, like this:

Manual testing 918373097 NF 2017-04-21 22:02 2.7 no factor for M918373097 from 2^68 to 2^69 [mfaktc 0.21 barrett76_mul32_gs] 0.0651
Manual testing 918373097 NF 2017-04-21 22:02 0.0 no factor for M918373097 from 2^68 to 2^69 [mfaktc 0.21 barrett76_mul32_gs] 0.0651

Not sure if it need to be fixed, but I figured I would point it out.

[QUOTE=GP2;457015]Reportedly, the server is giving bad worktodo lines for Fermat number F12, omitting most of the already-known factors. See [URL="http://www.mersenneforum.org/showthread.php?p=457011#post457011"]this thread[/URL].

This might be the cause of the bogus already-known factors for F12 (exponent 4096) that constantly appear in the [URL="https://mersenne.org/report_recent_cleared/"]Recent Cleared list[/URL].[/QUOTE]

Fixed. I'm not sure how the server "forgot" 4 of the known factors.

[QUOTE=Prime95;457302]Fixed. I'm not sure how the server "forgot" 4 of the known factors.[/QUOTE]

I hate to quibble, but F12 has 6 known factors and [URL="http://www.mersenneforum.org/showthread.php?p=457011#post457011"]in the other thread[/URL] it mentions that the server was only specifying 1 of them. So it forgot 5 factors, I think.

Maybe just a quick re-check to make sure we have all known factors, for F12 and the other Fermat numbers? They are listed in the other thread.

Also, is there a robust mechanism in place for reporting new factors of Fermat numbers to you and Madpoo if and when they are discovered? It seems like this is a separate part of the database and a separate branch of code.

The [url=https://www.mersenne.org/report_recent_results/]PrimeNet Most Recent Results[/url] page doesn't show all the results from the most recent hour. At the moment it's missing the first 10 minutes or so.

[QUOTE=Mark Rose;457500]The [url=https://www.mersenne.org/report_recent_results/]PrimeNet Most Recent Results[/url] page doesn't show all the results from the most recent hour. At the moment it's missing the first 10 minutes or so.[/QUOTE]

Perhaps there is a "limit" clause in the SQL statement.

[QUOTE=chalsall;457504]Perhaps there is "limit" clause in the SQL statement.[/QUOTE]Sounds plausible, the current report shows exactly 3000 rows.