Thread: Welcome Ben Delo View Single Post
2021-09-20, 20:31   #89
kriesel

"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

32×659 Posts

Quote:
 Originally Posted by chalsall As I understand it, Mersenne.org manual submissions implicitly include the "DONE" flag.
Well, if that is so, and causing premature assignment termination, that occurs to me as a server script design error incompatible with Gpuowl 7.x and a departure from previous practice.
It's tripping up other users too (see Uncwilly's post about Jan S work in the server problems thread)
The rule has long been, that one can report without expiration or termination of an assignment, any lesser / earlier result without expiring an assignment for a later result, except TF at lower bit levels than a TF high bit level assignment.
That is, hold an LL or PRP assignment? Report as much TF or P-1 as you like before the primality test result, on the same exponent, without causing expiration of the assignment. Hold a P-1 assignment? Report as much TF as you like on the same exponent. Only a found factor would expire the assignment.
There seems to be issues with processing P-1 no-factor results in particular; I've seen it cause the P-1 ASSIGNMENT get marked expired. The issue goes back at least to February. "DONE" on P-1 is not "DONE" on PRP.

The server provides no notification to the user that reporting the P-1 just revoked the PRP assignment. That's a problem.
V7.x gpuowl completes part of the PRP WHILE DOING P-1 stage 1 AS A BYPRODUCT at reduced combined cost. Revoking the PRP assignment is a certain waste of cycles.
Mihai's primenet.py would report the P-1 result at its next iteration. I don't believe it has any mechanism for getting the PRP reassigned after the server mishandles it.
It would be better to deal with this issue now, before v30.7? prime95 / mprime also adopts the lower-cost P-1 stage method already present in gpuowl v7.x, and it becomes an issue in the broader user community and wastes many more cycles.

Had this manual assignment issued long ago:
PRP=E9A657A1EFE64E2F082CB753C99AF7C0,1,2,926972593,-1,85,2

Manually prepended GPU72 row bounds for it, then ran it, completed the P-1 part.
B1=5000000,B2=260000000;PRP=E9A657A1EFE64E2F082CB753C99AF7C0,1,2,926972593,-1,85,2

Manually reported this result 2021-02-21:
{"status":"NF", "exponent":"926972593", "worktype":"PM1", "B1":"5000000", "B2":"260000000", "fft-length":"54525952", "program":{"name":"gpuowl", "version":"v7.2-21-g28dbf88"}, "user":"kriesel", "computer":"asr2/radeonvii3", "aid":"E9A657A1EFE64E2F082CB753C99AF7C0", "timestamp":"2021-02-21 17:38:46 UTC"}

Checked today, actually tried to report PRP progress using CURL, and it replies there's no such assignment.
Code:
pnErrorResult=43
pnErrorDetail=ap: no such assignment key, GUID: ...
Apparently the server cleared the PRP assignment when processing the P-1 NF result, back in February.

(And I note Gpuowl V7.2-21 left the bounds and 2 tests saved by P-1 factor found on the worktodo item after P-1 complete, so it would have done P-1 again. Manually edited to 0 now.)

Obtained a new assignment for that PRP today.

Last fiddled with by kriesel on 2021-09-20 at 20:48