Please try again

[QUOTE=James Heinrich;469658]Please try again[/QUOTE]
Submitting a factor seems to work again.
Thanks...

One of my machines was assigned the same exponent [M]2538959[/M] twice in a row for a PRP-CF test, resulting in a self-double-check.

This exponent stood out among the rest because it was out of the usual sequence: it was assigned a PRP-CF test because a new factor was discovered. The other exponents in worktodo were in the 3.1M range and hadn't had a first-time test on Primenet yet.

When the first PRP test completed, the exact same assignment (with same residue type 5) was assigned again, as part of the same communication with the server!

I noticed a few cases like that for Oliver Kruse and others doing PRP-CF tests, but until now I thought maybe they did a self-verify on purpose.



Here is the extract from prime.log, where the result is sent in for the old assignment, and then the new assignment is made at the same time:

[CODE]
[Thu Nov 2 13:19:37 2017 - ver 29.4]
Sending result to server: UID: GP2/c4.xlarge, [M]M2538959[/M]/25110366968391401/26621637266814029887 is not prime. Type-5 RES64: A87DC36CC4F0C31E. Wg8: 5D905E14,1247745,00000000, AID: 7014D24D0BF69D360E9EBE83BFF9888C

PrimeNet success code with additional info:
PRP test successfully completes double-check of [M]M2538959[/M] --
CPU credit is 0.1761 GHz-days.
Getting assignment from server
PrimeNet success code with additional info:
Server assigned PRP work.
Got assignment A6AAED2F0142C4EE83C068749B5D39BB: PRP [M]M2538959[/M]
Sending expected completion date for [M]M2538959[/M]: Nov 3 2017
Sending expected completion date for M3227717: Nov 2 2017
[/CODE]

And results.txt:

Here is results.txt:

[CODE]
c4.xlarge-prp/i-03aa0960019cf8075/results.txt:{"status":"C", "exponent":2538959, "known-factors":"25110366968391401,26621637266814029887", "worktype":"PRP-3", "res64":"A87DC36CC4F0C31E", "residue-type":5, "fft-length":131072, "shift-count":1247745, "error-code":"00000000", "security-code":"5D905E14", "program":{"name":"Prime95", "version":"29.4", "build":2, "port":8}, "timestamp":"2017-11-02 13:19:37", "errors":{"gerbicz":0}, "user":"GP2", "computer":"c4.xlarge", "aid":"7014D24D0BF69D360E9EBE83BFF9888C"}

c4.xlarge-prp/i-03aa0960019cf8075/results.txt:{"status":"C", "exponent":2538959, "known-factors":"25110366968391401,26621637266814029887", "worktype":"PRP-3", "res64":"A87DC36CC4F0C31E", "residue-type":5, "fft-length":131072, "shift-count":2364730, "error-code":"00000000", "security-code":"5D905E14", "program":{"name":"Prime95", "version":"29.4", "build":3, "port":8}, "timestamp":"2017-11-03 15:34:04", "errors":{"gerbicz":0}, "user":"GP2", "computer":"c4.xlarge", "aid":"A6AAED2F0142C4EE83C068749B5D39BB"}
[/CODE]

The same flaw has probably existed all along for LL assignments, it's just much less likely to happen. Right now there are only a handful of us doing PRP-CF tests, with two of us doing the bulk of them, and new assignments for exponents below the wavefront get sent whenever a new factor is discovered, so it's much more likely to happen.

[QUOTE=GP2;470977]One of my machines was assigned the same exponent [M]2538959[/M] twice in a row for a PRP-CF test, resulting in a self-double-check..[/QUOTE]

Actually, there is SQL code in place to prevent assigning double-checks to the same user that did the first test. I believe that code is working.

Your bug was in the SQL code that classifies the next work needed on the exponent. On your first test, you returned a type-5 residue that matched the type-5 residue returned when there was one fewer factor. Your result classified the exponent as double-checked. The SQL code that classifies the next work type for the exponent was not expecting just one row marked as double-checked and classified the exponent as needing a first-time test rather than needing ECM.

Short version: bug fixed.

I recently requested that a [url=http://mersenneforum.org/showthread.php?t=22655]P-1 result be manually added[/url] because PrimeNet keeps complaining that it wasn't needed. However, I still don't see it after almost two weeks. Is there some sort of administrative backlog?

If manually updating the database isn't practical, then I fully understand, but can someone at least let me know instead of never responding to my thread?

[QUOTE=ixfd64;471050]
If manually updating the database isn't practical, then I fully understand, but can someone at least let me know instead of never responding to my thread?[/QUOTE]

Lack of response usually means the 2 or 3 people with access to the server are not real interested in fixing or the effort was too great.

When I looked at it the first time, I found it too tedious to manually generate the needed rows.

Today, I figured out a much easier shortcut. I deleted the factor and re-submitted the result using manual forms. I don't think that will cause any problems, we'll see.....

Thanks, George. This is much appreciated!

Some exponents have a long list of expired assignments in red, which slows down display of the status. Especially the smaller exponents, which can have a lot of expired "factor ECM small" assignments.

These are mostly of historical interest and could be omitted by default.


In other words, how about changing the checkbox from:

Include full ECM history (every "no-factor ECM" result)

to

Include full history (every "no-factor ECM" result, every expired ECM assignment)


By default, we already omit completed NF-ECM assignments from the display, so why do we display uncompleted (expired) ECM assignments? They should be controlled by the same checkbox.

Actually, it might even be desirable to omit all the red lines by default (all expired assignments, whether ECM or not). But at least omitting "factor ECM small" by default would be a good start.

[QUOTE=GP2;471170]Some exponents have a long list of expired assignments in red, which slows down display of the status. Especially the smaller exponents, which can have a lot of expired "factor ECM small" assignments.

These are mostly of historical interest and could be omitted by default
<....>
Actually, it might even be desirable to omit all the red lines by default (all expired assignments, whether ECM or not). But at least omitting "factor ECM small" by default would be a good start.[/QUOTE]

Maybe it could exclude expired assignments by default with a checkbox to enable them if someone were so inclined.

Yeah, I'm not sure how much value is added by showing expired stuff by default, but I can imagine there'd be times when so-and-so would want to look at the full assignment history. Maybe the next prime will be discovered and someone will look back at that and say "oh man, so-and-so had this assignment but never worked on it" and we can all laugh at them. :smile:

(M74207281 has an expired assignment, but it was assigned after we'd made the discovery... not sure how that happened, it shouldn't have gone out as an assignment).

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.

[QUOTE=Madpoo;471188]Maybe it could exclude expired assignments by default with a checkbox to enable them if someone were so inclined.
[/QUOTE]

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.