OFFICIAL "SERVER PROBLEMS" THREAD

[kladner]

Originally Posted by Dubslow

Not even a checkbox, a more aethestic version (IMO) would be a single line with something like "x expired assignments (click to expand)", which expansion would replace said line.

+1

[GP2]

Originally Posted by Dubslow

Not even a checkbox, a more aethestic version (IMO) would be a single line with something like "x expired assignments (click to expand)", which expansion would replace said line.

That's less than ideal, because you are merely hiding the results. You are still spending the time to do the database query. The checkbox would skip the database query entirely.

For small exponents with lots of expired assignments, it can take several seconds to check their status, for instance M1277. If it is a 10k range of exponents rather than a single exponent, it can take half a minute or so. Whereas exponents without a lot of "baggage" usually display almost instantly.

A lot of time and server effort is spent on retrieving things that clutter the display and will be ignored anyway.

Maybe the default should be to display only "current status": factors, LL residues, PRP and PRP-cofactor residues, and current assignment if any. A lot of the time that's all you want. Anything that's "history" (including expired assignments) would require a checkbox.

[James Heinrich]

Originally Posted by GP2

That's less than ideal, because you are merely hiding the results. You are still spending the time to do the database query.

Not necessarily. You display the "click to expand" on page load, and use AJAX to load in the actual details iff someone clicks that.

Like on my PRP page, if you click "P-<digits>" it expands it to the full decimal representation, but only on demand.

[Dubslow]

Originally Posted by GP2

That's less than ideal, because you are merely hiding the results. You are still spending the time to do the database query. The checkbox would skip the database query entirely.

The full query is only run when expansion is clicked, as JH says. That might make expansion slow in the large cases, but only when you click it.

(I suppose that might require storing the count of expired assignments separately in the table, or just leave it out of the "expand" row.)

[retina]

Originally Posted by James Heinrich

Not necessarily. You display the "click to expand" on page load, and use AJAX to load in the actual details iff someone clicks that.

Like on my PRP page, if you click "P-<digits>" it expands it to the full decimal representation, but only on demand.

No JS please. I also hate the current trend of websites to hide everything behind "click here to ..." things. I like to have all the information there without having to waste time clicking around for hidden things like it is some sort of game for a 5 year old.

I prefer the checkbox option. It can also be stored as a link in the GET query so once someone has got their desired information they can save the link for future visits without needing to "click here" after the page is loaded.

[Madpoo]

Originally Posted by Mark Rose

I like to see expired LL/TF assignments so I have a good idea if I'm about to get poached if I'm manually reserving an assignment.

I do too... so I did think of an alternate idea which is to show recent expired assignments (in the past XX days), or maybe only show expired assignments if they're still checking in even though expired.

There would still, under that idea, be a checkbox to show *all* of the expired assignments for the truly curious folks who may want to look at something in particular, but for the average use, having all of those show up has little benefit and only clutters things... IMO.

[Mark Rose]

Originally Posted by Madpoo

I do too... so I did think of an alternate idea which is to show recent expired assignments (in the past XX days), or maybe only show expired assignments if they're still checking in even though expired.

There would still, under that idea, be a checkbox to show *all* of the expired assignments for the truly curious folks who may want to look at something in particular, but for the average use, having all of those show up has little benefit and only clutters things... IMO.

That's fair.

[potonono]

The mersenne.org/workload/ page shows UNKNOWN WORKTYPE "150" down in the work-to-do section for PRP tests rather than the expected PRP=xyz,#,#,M#,# that is in an actual work-to-do file.

[Madpoo]

Originally Posted by potonono

The mersenne.org/workload/ page shows UNKNOWN WORKTYPE "150" down in the work-to-do section for PRP tests rather than the expected PRP=xyz,#,#,M#,# that is in an actual work-to-do file.

Can you share an example worktodo entry for a PRP test (XX out the assignment ID). I can try fixing up that page but since I haven't done any PRP tests myself, I don't actually know what such a line should look like.

[James Heinrich]

PRP=(<assignment_id>,)1,2,<exponent>,-1(,"comma,separated,knownfactors")

[GP2]

Originally Posted by James Heinrich

PRP=(<assignment_id>,)1,2,<exponent>,-1(,"comma,separated,knownfactors")

Well, not exactly.

For PRP cofactor double checking:

Between the -1 and the comma-separated list of known factors, there is 99,0,3,1 if it's a double-check of a Type 1 first-time result and 99,0,3,5 if it's a double check of a first-time type 5 result.

For PRP cofactor first-time checking:

It's still a valid line if those four fields are omitted, and I think it just defaults to Type 5. If I'm not mistaken, first-time PRP test assignments do omit those fields, but I don't have any current examples to look at.

For PRP primality double-checking:

Obviously there is no list of known factors, and after the -1 there are the fields "75,0,3,4" (no factors below 2⁷⁵, uses base 3 as the work type, and uses residue type 4, to match the first time test that was done by preda using gpuOwL).

For PRP primality first-time checking:

Obviously there is no list of known factors, and the fields just end with the -1