mersenneforum.org reported result leads to assignment falsely marked expired
 Register FAQ Search Today's Posts Mark Forums Read

 2018-11-20, 15:25 #1 kriesel     "TF79LL86GIMPS96gpu17" Mar 2017 US midwest 2·3·821 Posts reported result leads to assignment falsely marked expired It appears after looking at my own recent P-1 results, that manually reserved and reported P-1 run in CUDAPm1 (observed mostly at higher than wavefront exponent values, but probably because that's mostly what I'm running manually) when completed and reported leave the assignment listed as expired, usually, while primenet-connected prime95 handling routine ~90m assignments and results do not ever to my knowledge. The combination of accepting and recording a reported result, and listing the assignment as expired, seem inconsistent to me; mutually exclusive cases. An assignment would result in a reported result in time, or expiration after a time limit, not simultaneous acceptance of the result and forcing expiration of the assignment and recording it as expired. The database is getting salted with false expiration records. See for example https://www.mersenne.org/report_expo...0000111&full=1 Assignment is not retired, it's marked expired, same day as the result is reported. This one exceeds the gpu72 B1 and B2 limit minima / goals and was done with e=4 selected by the program, and was a manual report of a CUDAPm1 v0.20 run. See also https://www.mersenne.org/report_expo...7000069&full=1 https://www.mersenne.org/report_expo...0001033&full=1 https://www.mersenne.org/report_expo...0000189&full=1 https://www.mersenne.org/report_expo...0000719&full=1 https://www.mersenne.org/report_expo...9586961&full=1 Some are a little different, in that B1 is a bit lower than the gpu72 value. https://www.mersenne.ca/exponent/394000027 https://www.mersenne.org/report_expo...8000099&full=1 These were manual CUDAPm1 but not marked expired. Some may not have ever been assigned me. https://www.mersenne.org/report_expo...2000019&full=1 https://www.mersenne.org/report_expo...2000249&full=1 https://www.mersenne.org/report_expo...0000283&full=1 https://www.mersenne.org/report_expo...0001067&full=1 https://www.mersenne.org/report_expo...0007351&full=1 B1=B2: https://www.mersenne.org/report_expo...8000101&full=1 A rare manual reservation and report with B1
 2018-11-21, 12:55 #2 kriesel     "TF79LL86GIMPS96gpu17" Mar 2017 US midwest 10011001111102 Posts Sometimes assigned manual reports marked expired First one was recorded as expired, others not. All assigned together manually, and running to same B1 and B2 limits except the one with a factor found in stage 1, and all reported together manually. Code: M89696983 found no factor (P-1, B1=785000, B2=19036250, e=4, n=5184K, ... M89697031 has a factor: 1881353105816850970625767 (P-1, B1=785000, B2=785000, e=4, n=5184K, ... M89697077 found no factor (P-1, B1=785000, B2=19036250, e=4, n=5184K, .. M89697277 found no factor (P-1, B1=785000, B2=19036250, e=4, n=5184K, ... M89697367 found no factor (P-1, B1=785000, B2=19036250, e=4, n=5184K, ... M89697383 found no factor (P-1, B1=785000, B2=19036250, e=4, n=5184K, ... M89700139 found no factor (P-1, B1=785000, B2=19036250, e=4, n=5184K, ... All had previously recorded TF expirations. Last fiddled with by kriesel on 2018-11-21 at 12:56
 2018-11-22, 15:26 #3 kriesel     "TF79LL86GIMPS96gpu17" Mar 2017 US midwest 2·3·821 Posts FIRST manually reported P-1 result leads to assignment marked expired on date result reported https://www.mersenne.org/report_expo...9700157&full=1 As a result of reporting a bunch of TF and then these: Code: M89700157 found no factor (P-1, B1=785000, B2=19036250, e=4, n=5184K, aid=... M89700271 found no factor (P-1, B1=785000, B2=19036250, e=4, n=5184K, aid=... M89700343 found no factor (P-1, B1=785000, B2=19036250, e=4, n=5184K, aid=... M89700407 found no factor (P-1, B1=785000, B2=19036250, e=4, n=5184K, aid=... M89700467 found no factor (P-1, B1=785000, B2=19036250, e=4, n=5184K, aid=... M89700503 found no factor (P-1, B1=785000, B2=19036250, e=4, n=5184K, aid=... Last fiddled with by kriesel on 2018-11-22 at 15:28
 2018-11-23, 15:39 #4 kriesel     "TF79LL86GIMPS96gpu17" Mar 2017 US midwest 2×3×821 Posts Again today, with https://www.mersenne.org/report_expo...9700521&full=1
2018-11-23, 16:15   #5
chalsall
If I May

"Chris Halsall"
Sep 2002

224118 Posts

Quote:
 Originally Posted by kriesel Again today, with https://www.mersenne.org/report_expo...9700521&full=1
One thought on this... Are you reserving these through a Prime95/mprime instance, and then completing them via a GPU based P-1 program?

IIRC, the Prime95/mprime clients actually unreserve the assignment after reporting the results (it's been a while since I look at the deep API protocol, so I could be wrong on this point).

2018-11-23, 18:16   #6
kriesel

"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

2·3·821 Posts

Quote:
 Originally Posted by chalsall One thought on this... Are you reserving these through a Prime95/mprime instance, and then completing them via a GPU based P-1 program? IIRC, the Prime95/mprime clients actually unreserve the assignment after reporting the results (it's been a while since I look at the deep API protocol, so I could be wrong on this point).
Hmm, an interesting question, but no, prime95/mprime were not involved in any way in getting these assignments that got marked expired. gpu72 was also not involved. The operation of prime95 on those systems' cpus is primenet automated, and completely independent of the gpus' operation which is entirely manual.

I've been running P-1, PRP, LL, LLDC on cpus, and P-1, PRP, TF, LL, LLDC, and PRPDC on gpus. I have not that I recall seen the expiration issue for prime95 P-1 assignments (which are automatically primenet assigned, prime95 performed, and primenet reported).

I have seen the issue for some manual P-1 assignments. In recent days I've narrowed that, by study of my results listings, and subsequent experiment, to the first P-1 assignment reported manually that was assigned manually, in any given manual report. Today's earlier post was the result of a deliberate careful test for that. Assignments for gpu based P-1 were obtained from https://www.mersenne.org/manual_assignment/, copied/pasted from the web page response directly into gpu application CUDAPm1 instances' worktodo files manually, and results from their results.txt files copied/pasted directly into https://www.mersenne.org/manual_result/ manually for submission. I've also been inserting a line "reported " followed by mm/dd/yy at the current end of results.txt files, to prevent accidental double reporting of results. Windows remote desktop supports remote clipboard service, so I can readily report multiple systems' manual results in a single submission.

Showing the issue:
First manually reported P-1 result in a manually assigned and manually reported gpu batch of results reported (that is, reporting several manually assigned P-1 results together, the first in the list reported together gets result recorded and assignment marked expired, the others get result recorded and assignment cleared)
This is apparently occurring in every manual report that contains at least one P-1 result (that was also manually assigned). These manual reports I typically make daily.

Not showing the issue to my knowledge:
Any other type of assignment than P-1
Results reported for which no assignment was in effect
P-1 results reported manually following the first reported P-1 manual result in a combined manual submission
Any prime95/primenet automated work, which is set up to occur on autopilot and is let be. It's rare that I would shift any such work even between worker threads on an instance, much less from one application type or hardware type to another.

No unambiguous data on mixed manual/primenet cases:
prime95/primenet assigned work, moved manually elsewhere and reported manually (I try to avoid this case, as well as essentially the converse, manual reservation followed by performance on prime95 with result reporting by primenet)

Over time, this means that 10% to 50% or more of my manual P-1 results generate a false expiration record in the database; one per manual report form submission. I assume others doing manual assign and report of P-1 are producing these extraneous "expirations" too, whether they're aware or not. (current wavefront P-1 can complete several per day on a fast gpu, while a large exponent may take several days each.) I suspect it is an issue with the script that processes manual report submissions on the server, perhaps leftover values from TF preceding or improper initialization for the first P-1 result present in the combined manual report.

Last fiddled with by kriesel on 2018-11-23 at 18:23

 2018-12-03, 02:38 #7 kriesel     "TF79LL86GIMPS96gpu17" Mar 2017 US midwest 2×3×821 Posts still happening https://www.mersenne.org/report_expo...9787661&full=1 First of 3 manually reserved yesterday, all 3 reported today manually, first is marked expired, other two were processed as expected (assignment cleared, not marked expired). Last fiddled with by kriesel on 2018-12-03 at 02:41
 2018-12-10, 22:13 #8 Madpoo Serpentine Vermin Jar     Jul 2014 2·5·7·47 Posts I'm not sure what's happening there, and I only skimmed the thread, but my initial take is this: Typically this is the sort of thing that happens when an assignment is made through the site manually or the client itself, so an assignment ID is generated. Aside from people adding worktodo entries manually that don't contain the assignment ID, that's how most work is handed out. When a result comes in through the client, it will contain that assignment ID and the work is marked as complete, not expired or anything. When a result comes in through the manual results page on the website, if it contains the assignment ID in the text, it should also be marked complete, not expired. However, I think it also makes sure you're logged into the site as the same user who got that work assigned to them. You may have the correct AID in the text but if you're not logged in when submitting the result, it may simply mark the old assignment as expired (poached ... finished by someone else than it was assigned to). I believe there may also be some code that looks at a result coming in without the assignment ID - it checks to see if the user has that same exponent assigned and if so, marks it as complete anyway. One other thing it's checking for is to see if the work *type* matches the assignment. For example, if you were assigned an exponent for LL test and you turn in a PRP result, it may mark the original assignment as expired because it wasn't really a match for the work type. I suspect what we have here is a case of the system getting confused about whether the same person turning in the result is the same one it was assigned to, or the work type didn't match up. Again, I skimmed, and if that is the issue I'm not sure if that's something on the server side when it's checking in a result, or if it's the client side not reporting the correct work type in the API call it makes, or... something else.
2018-12-10, 23:07   #9
kriesel

"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

133E16 Posts

Quote:
 Originally Posted by Madpoo I'm not sure what's happening there, and I only skimmed the thread, but my initial take is this: Typically this is the sort of thing that happens when an assignment is made through the site manually or the client itself, so an assignment ID is generated. Aside from people adding worktodo entries manually that don't contain the assignment ID, that's how most work is handed out. When a result comes in through the client, it will contain that assignment ID and the work is marked as complete, not expired or anything. When a result comes in through the manual results page on the website, if it contains the assignment ID in the text, it should also be marked complete, not expired. However, I think it also makes sure you're logged into the site as the same user who got that work assigned to them. You may have the correct AID in the text but if you're not logged in when submitting the result, it may simply mark the old assignment as expired (poached ... finished by someone else than it was assigned to). I believe there may also be some code that looks at a result coming in without the assignment ID - it checks to see if the user has that same exponent assigned and if so, marks it as complete anyway. One other thing it's checking for is to see if the work *type* matches the assignment. For example, if you were assigned an exponent for LL test and you turn in a PRP result, it may mark the original assignment as expired because it wasn't really a match for the work type. I suspect what we have here is a case of the system getting confused about whether the same person turning in the result is the same one it was assigned to, or the work type didn't match up. Again, I skimmed, and if that is the issue I'm not sure if that's something on the server side when it's checking in a result, or if it's the client side not reporting the correct work type in the API call it makes, or... something else.
Thanks for replying at length. I know that can be time consuming.

These false expiration entries are occurring for CUDAPm1 completely manually reserved and reported. I've been able to reproduce it, as the first manually reported P-1 result reported, with a valid AID assigned to kriesel, while logged in properly, assigned the day before, manually, with a valid AID assigned to kriesel, while logged in properly, gets marked expired, the others in the same batch get cleared. The result submission as I recall occurs without error messages appearing on the web browser. The assignments and results are copy/paste entire, to avoid typographical errors.

"kriesel logged in" in white text in a green region in the upper right of https://www.mersenne.org/manual_result/ or https://www.mersenne.org/manual_assignment/ respectively, I routinely check for before reserving or reporting.

Perhaps it would help clarify things if I take before and after screen shots of manual assignment and reporting for P-1. I'll run another batch shortly. I am _not_ seeing the issue with prime95, which is managed through the primenet API. I only see it with the first P-1 reported in a manual report with a valid assignment for me, which is also a manual assignment, and processed in CUDAPm1 which requires manual assign and report.

Last fiddled with by kriesel on 2018-12-10 at 23:25

2018-12-11, 14:44   #10
kriesel

"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

2×3×821 Posts
Dec 10-11 documentation of the sequence part 1 of 2

I reserved 4 assignments, 89860301-349, in a single operation, and recorded screen shots or printed pdfs at several steps along the way to document the issue is with the first manual report of a P-1 result in a set reported together. Here are the images. There are no error messages shown in the manual report result page or elsewhere along the way.
First group, attached to this message, is the directory listing afterward with time stamps to show sequence, the assignment reservation and worktodo addition sequence and assignment status confirmation.

Part two in the post following shows result reporting and the erroneous outcome.
Attached Thumbnails

Attached Files
 Exponent Status - PrimeNet.pdf (82.1 KB, 83 views)

Last fiddled with by kriesel on 2018-12-11 at 14:59

2018-12-11, 14:57   #11
kriesel

"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

2·3·821 Posts
Dec 10-11 documentation of the sequence part 2 of 2

The images attached to this post show gathering the CUDAPm1 P-1 results records, status of the assignments shortly before reporting the results, reporting them manually, an error-message-free report result page in the web browser, and the first P-1 result reported generates one false expiration recorded in the database, shown in the status check after the report completed. The first in the set of four, 89860301 has both an accurate completion of the assignment, and a false expiration recorded. The other three were processed correctly, but not the first.

There appears to be no way to manually reserve and manually report CUDAPm1 work through copy/paste into the web form without producing false P-1 expirations, since any result report for P-1 work completed will have a first report in it. I don't know if the file submission method also has this issue; I haven't used that in a long time, since in my environment that requires extra steps creating an additional file or additional web browser sessions host by host.

Please investigate and resolve this issue with the manual results submission web form processing or whatever's behind the false expiration of the first P-1 report per result submission.
Attached Thumbnails

Attached Files
 Exponent Status - PrimeNet just before reporting manually.pdf (82.0 KB, 85 views) Exponent Status - PrimeNet showing first P-1 manually reported result expired and completed.pdf (83.4 KB, 84 views)

Last fiddled with by kriesel on 2018-12-11 at 15:05

 Similar Threads Thread Thread Starter Forum Replies Last Post kracker PrimeNet 23 2016-01-26 20:41 Yura PrimeNet 2 2011-05-10 15:13 tichy PrimeNet 4 2010-12-17 09:57 Old man PrimeNet PrimeNet 2 2006-02-16 23:02 axn Sierpinski/Riesel Base 5 1 2005-10-13 07:53

All times are UTC. The time now is 05:56.

Sun Mar 7 05:56:10 UTC 2021 up 94 days, 2:07, 0 users, load averages: 1.29, 1.46, 1.73