Is there any way to continue to P-1 stage 2 even if a factor was found in stage 1? I'm thinking of how the MFakt[x] applications will stop immediately after finding a factor by default, but can be configured to finish out the bit level anyway.

I Ctrl+F'd "p-1" in undoc.txt but didn't find anything that seemed relevant.

[QUOTE=techn1ciaN;592532]Is there any way to continue to P-1 stage 2 even if a factor was found in stage 1?[/QUOTE]I recommend against doing that routinely. It diverts computing time away from productively advancing GIMPS' primary goal, of finding new Mersenne primes. One factor is enough to eliminate a Mersenne number from further consideration.
From [URL]https://www.mersenneforum.org/showpost.php?p=522098&postcount=22[/URL] in the reference info,
a single worktodo entry can be added back if you want to explore pursuing additional P-1 factors, of the form
Pminus1=[<AID>,|N/A,|<nul>]<k>,<b>,<n>,<c>,<B1>,<B2>[B][,"comma-separated-list-of-known-factors"][/B]

[QUOTE=Prime95;591868]The stage two 100% complete error should be harmless. I'm looking into why it occurs.[/QUOTE]


I've updated to 30.7 b7 (in hopes of doing faster P-1 work) and I seem to have encountered the 100% complete error.

I'm currently re-doing P-1 for exponents that previously had only B1 done from [URL]https://www.mersenne.ca/pm1_worst.php[/URL].

The error started popping up when worker #1 went from stage 1 -> stage 2 and forced worker #2 (already in stage 2) to restart using new memory allocation. (2 workers, 3 cores each)
When I noticed the erroneous logging behavior I promptly restarted Prime95 but worker #2 continued logging 100% complete throughout the assignment. This affected expected completion date, it constantly assumed the assignment on worker #2 would complete in that minute.

The assignment finished within its usual time frame and was registered successfully!
Thought this was worth reporting since no-one had specified they were able to recreate this bug.
Below are some screenshots attached. Unfortunately I did not capture the moment the erroneous behavior started.


Also, I've queued up a little under 300 exponents spread over these 2 workers and whenever the Test->Status... window is opened my Prime95 window freezes up for 10 seconds before the status window is shown. It sometimes enters "Prime95 not responding" before the status window is shown.
Not sure if this is expected behavior with this many exponents queued in Prime95 or if this is a bug.

I assume this error is as easily reproducible for others as it is for me :smile:. Please disregard previous post about 100% complete error. (See file attached)

[QUOTE=techn1ciaN;592532]Is there any way to continue to P-1 stage 2 even if a factor was found in stage 1?[/QUOTE]

Yes, look here:[QUOTE=kruoli;590431][...] Now, you need to set it to [C]Stage1GCD=-1[/C].[/QUOTE]

[QUOTE=kriesel;592534]I recommend against doing that routinely. It diverts computing time away from productively advancing GIMPS' primary goal, of finding new Mersenne primes.[/QUOTE]

It is my personal preference to turn in "complete" assignments. I use StopAfterFactor=0 with MFaktC for this reason.

In re: "wasting" cycles, my laptop runs standalone P-1 full time. The automatically set bounds seem to give me a chance of a bit less than 5% to find a P-1 factor for any given exponent. We might assume that half of these (not empirical; just my spitball) would be found within stage 1, and continuing to stage 2 in these cases would represent (approximately) only half the effort of a full P-1 run. So, unless my math or my assumptions are grossly wrong, continuing to stage 2 for every P-1 run should not cost me much more than a percent of my total computing time. I think I'm fine with that.

For test case PFactor=aid,1,2,107181343,-1,76,1
bounds for 1 test saved 403000, 15491000, determined by prime95
runtime for 1 saved est 6:09 (h:mm); 10/31/21 15:16 start s1, 16:52 s1 gcd done, 20:17 s2 & gcd done, actual 5:01 elapsed, 7.2853 GHD, NF
S1/s2 time ratio 1:36 vs 3:25; 96 min vs 205 min, <1/2
S1/total was 96/301 = 31.9% of total P-1 runtime, less than a third. Had a factor been found in stage 1 and stage 2 skipped, it would have been more than 3 times as productive as forcing stage 2 to run despite an already-found factor that eliminated the possibility of the same Mersenne number being prime. Saving over 3 hours, which could be applied effectively to following assignments.
Over the course of a year, 365*24*60/301 = 1746 exponents could be P-1 factored to such bounds. Odds of factoring was estimated as 3.36%. That's ~59 factored. Suppose 29 factors are found in stage 1, AND stage 2 skipped for those. 29 * 205 = 5945 minutes saved (over 4 days), enough to P-1 factor both stages for ~20 more in the same time, ~1.1% more.
Our rare few top programmers work hard to squeeze out the last few % of performance. Seems a shame to give it up so readily. But your kit your call.

build 8 now available

RESOLVED
Turns out I mis-edited my worktodo.txt to read "Pminus1=N/A,2,11996279,-1" instead of "Pminus1=N/A,1,2,11996279,-1". That makes mprime crash. I guess that shouldn't happen either, but at least it is a crash that is easy to reproduce.





I had a crash today on build 5, so I updated to build 8 and got another crash after 45 minutes of running. Mprime's last words were
[quote]
[Worker #7 Nov 9 18:59] ECM on M304331: curve #40 with s=4906294320036236, B1=250000, B2=TBD
[Worker #2 Nov 9 18:59] Stage 1 complete. 25612656 transforms, 1 modular inverses. Total time: 890.428 sec.
[Worker #2 Nov 9 18:59] Available memory is 11000MB.
[Worker #8 Nov 9 18:59] M12000979 stage 2 complete. 1350170 transforms. Total time: 1907.737 sec.
[Worker #8 Nov 9 18:59] Stage 2 GCD complete. Time: 2.086 sec.
[Worker #8 Nov 9 18:59] M12000979 completed P-1, B1=400000, B2=21200000, Wi8: 37EA4735
[Comm thread Nov 9 18:59] Sending result to server: UID: nordi/sweet16, M12000979 completed P-1, B1=400000, B2=21200000, Wi8: 37EA4735
[Comm thread Nov 9 18:59]
[Worker #8 Nov 9 18:59]
mprime: malloc.c:3829: _int_malloc: Assertion `chunk_main_arena (bck->bk)' failed.
[/quote]The first crash had also happened just after the Comm thread was sending a result.

Previously, mprime ran crash free for weeks. What has changed is that I now have 4 (very memory hungry) workers on P-1 work, which I previously never did. Note that the "Available memory is 11000MB" is due to a per-worker config that limits most worker to 11GB (and some to 18GB). There is no "out of memory" message in the system log.

Right now, mprime crashes when starting the 8th worker, which is a P-1 worker. The dmesg tool shows
[quote]
[7615784] traps: mprime[25587] general protection ip:53ef89 sp:7f0f7d430900 error:0 in mprime[400000+21db000]
[7615892] traps: mprime[25715] general protection ip:53ef89 sp:7ff38a78e900 error:0 in mprime[400000+21db000]
[7615970] traps: mprime[25968] general protection ip:53ef89 sp:7f8963d30900 error:0 in mprime[400000+21db000]
[7616156] traps: mprime[26076] general protection ip:53ef89 sp:7fb1ab0ac900 error:0 in mprime[400000+21db000]
[/quote]

[QUOTE=kriesel;592577]Odds of factoring was estimated as 3.36%. That's ~59 factored. Suppose 29 factors are found in stage 1, AND stage 2 skipped for those.[/QUOTE]
I calculated in [url]https://www.mersenne.ca/prob.php?exponent=107181343&factorbits=76&b1=403000&b2=403000[/url] that the stage 1 only probability is 1.15%, so you should suppose that only 20 (59*0.0115/0.0336) are found in stage 1.

[QUOTE=kriesel;592577]Our rare few top programmers work hard to squeeze out the last few % of performance[/QUOTE]
It's never the lase few percent. People are continuing to explore new factoring methods and optimizing the code.

[QUOTE=Zhangrc;592839]It's never the lase few percent. People are continuing to explore new factoring methods and optimizing the code.[/QUOTE]Actually there are indications of diminishing returns over the life of the prime95 software. P+1 factoring is irrelevant to wavefront GIMPS work. Performance improvements early on were 5%, 15% or even sometimes 40% on the same hardware.
The program uses a large percentage of the theoretical maximum memory bandwidth for specific hardware.