[QUOTE=techn1ciaN;592318]Probably a stupid question:

When one is using the cert range controls provided in undoc.txt (Cert[Min|Max]Exponent), do you need to add both lines for the functionality to work, or are you fine to add only one or the other?[/QUOTE]

I suspect just one will work

[QUOTE=techn1ciaN;592318]Probably a stupid question:

When one is using the cert range controls provided in undoc.txt (Cert[Min|Max]Exponent), do you need to add both lines for the functionality to work, or are you fine to add only one or the other?[/QUOTE]


I only have CertMinExponent=0 and have never noticed any issues.

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.

[QUOTE=Prime95;589236]
1) Help fine-tune the P-1 stage 1 vs stage 2 cost function. In preferences, set output iterations low -- like 10000. Report the typical P-1 stage 1 timings vs. typical stage 2 timings as well as minimal architectural info.[/QUOTE]

Are these numbers still of interest? I am running full-time P-1 on my Zen 2 laptop with 30.7b8 (Windows 11).

[QUOTE=techn1ciaN;592971]Are these numbers still of interest? I am running full-time P-1 on my Zen 2 laptop with 30.7b8 (Windows 11).[/QUOTE]

A little bit. Stage 2 per iteration time seems to be 30-70% slower. I could make it a prime.txt option, but I doubt many would bother with it. I'll just pick an average value and be done with it.

[QUOTE=Prime95;592975]A little bit.[/QUOTE]

OK, then — 107.3 M exponent using FMA3 FFT; 30.7b8; Zen 2 with dual-channel 3200 MHz RAM (Prime95 allowed max. 9 GB). Using automatic bounds with [c]tests_saved=1[/c]. Stage 1 appx. 12.5 sec. and stage 2 appx. 16 sec. with output every 7,000 iterations.

This is decidedly on the fast end of your average even though the bound selector is being decently generous with B2/B1 (around 38 for the exponent I got the timings from). I'm guessing this is due to my particular configuration somehow.

[QUOTE=Prime95;592975]I could make it a prime.txt option, but I doubt many would bother with it.[/QUOTE]

Great, I was asking for that (I know that I do not count as many). :smile: If that is easily implemented, maybe this would be fitting for undoc?

Speaking of asking for things… I seemed to recall that once somebody asked in the past how to set the default amount of curves when receiving ECM or ECM-CF work. Doing a quick search, I was not able to find it. While I am in full support of not changing that value to a smaller value than default for preventing cluttering the database, a higher number would decrease the work units one needs to keep locally and exchange with the server. Addtionally, it would presumably save even more database operations and space. Would this be a PrimeNet or Prime95 setting, if (!) it is deemed useful enough to being implemented?

After upgrading Windows 10 to Windows 11, there was no problem running LL and PRP tests with the prime95 app.
Then I attempted to run TF on M[M]337654321[/M] and v30.7b4 crashed.
The same happened after upgrading to the latest v30.7b8.
The green icon of the app appears on the taskbar for a moment and then it is gone.
When the TF task is removed from the worktodo.txt file, a pending PRP test is properly resumed.
Said TF test is now assigned to another computer with Windows 10 and is running just fine.
Therefore, there is some issue when running TF with the CPU in Windows 11. The CPU is Intel Core i7-1065G7.

[QUOTE=Dobri;593029]Therefore, there is some issue when running TF with the CPU in Windows 11.[/QUOTE]


Not to ignore the software problem, but is there a reason why you're doing CPU TF?

[QUOTE=nordi;592815]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.[/QUOTE]

I could not reproduce this. I get an "Illegal line in worktodo.txt message".

[QUOTE=techn1ciaN;593030]Not to ignore the software problem, but is there a reason why you're doing CPU TF?[/QUOTE]
I do not have suitable GPUs for TF tests and use only prime95 mainly for PRP, LL, and P-1 tests.
Occasionally, I may run a TF test before a P-1 test.

[QUOTE=Dobri;593032]I do not have suitable GPUs for TF tests and use only prime95 mainly for PRP, LL, and P-1 tests.
Occasionally, I may run a TF test before a P-1 test.[/QUOTE]

I am sure that myself or someone else on the forum who does have access to a good TF GPU would be happy to take an exponent to GPU72's recommended TF bit level for you if you asked (see [URL="https://www.mersenneforum.org/showthread.php?t=26844"]Uncwilly's post[/URL] in the old LMH sub-forum; I don't need anything in exchange, though / I'm happy just to save the cycles for the project). I could get the exponent you posted to 2[SUP]81[/SUP] TF bits in less than 48 hours with my laptop's GTX 1650. Is this of interest?

[QUOTE=techn1ciaN;593041]I could get the exponent you posted to 2[SUP]81[/SUP] TF bits in less than 48 hours with my laptop's GTX 1650. Is this of interest?[/QUOTE]
Thanks, your offer is appreciated, but I do not want anyone accusing me after that of diverting resources from the wavefront TF tests in the 229,xxx,xxx range. Also, the exponent in question is no 'special' to me.

My only intention is to report the TF bug I encountered with Windows 11.

[QUOTE=Dobri;593049]II do not want anyone accusing me after that of diverting resources from the wavefront TF tests in the 229,xxx,xxx range..[/QUOTE]
No one is entitled to accuse you (or anyone else, for that matter) of anything whatsoever. You are volunteering to take part in this project, so you are free to use your resources as you see fit.

Here is an update. I rolled back to v30.3b6 and the TF test is running properly in Windows 11.

[QUOTE=Dobri;593058]Here is an update. I rolled back to v30.3b6 and the TF test is running properly in Windows 11.[/QUOTE]Maybe you could post the assignment line (with the assignment ID masked or replaced with [c]N/A[/c]) so that George (or whomever) can easily test the same thing you're running.

[QUOTE=James Heinrich;593060]Maybe you could post the assignment line (with the assignment ID masked or replaced with [c]N/A[/c]) so that George (or whomever) can easily test the same thing you're running.[/QUOTE]
Factor=[c]N/A[/c],229279313,73,74
Factor=[c]N/A[/c],337654321,75,76
I tried with two different exponents to make sure that the exponent value is not an issue.
The test can run with v30.3b6 in Windows 11 but not with v30.7b4 and v30.7b8. The CPU is Intel Core i7-1065G7.
Note that the tests run properly with v30.7b4 and v30.7b8 in Windows 10 on another computer.

[QUOTE=James Heinrich;593060]Maybe you could post the assignment line (with the assignment ID masked or replaced with [c]N/A[/c]) so that George (or whomever) can easily test the same thing you're running.[/QUOTE]

Dobri's TF problem is already fixed. I'll upload a new build in a few days.

Build 9 available.

[QUOTE=Prime95;593122]Build 9 available.[/QUOTE]
The TF problem is fixed indeed. Thank you, George.

[QUOTE=Prime95;592975]A little bit.[/QUOTE]

[CODE][Work thread Nov 15 21:40] P-1 on M22487611 with B1=2000000, B2=TBD
[Work thread Nov 15 21:40] Using FMA3 FFT length 1152K, Pass1=384, Pass2=3K, clm=2, 8 threads
[Work thread Nov 15 22:10] M22487611 stage 1 complete. 5771296 transforms. Total time: 1799.401 sec.
[Work thread Nov 15 22:10] With trial factoring done to 2^75, optimal B2 is 61*B1 = 122000000.
[Work thread Nov 15 22:10] Using 12286MB of memory.
[Work thread Nov 15 23:11] M22487611 stage 2 complete. 7127841 transforms. Total time: 3696.155 sec.[/CODE]
Intel i7 10700 (non-K) @ 105 W set, 2x8GB 3,200 MT memory.

[QUOTE=Prime95;593122]Build 9 available.[/QUOTE]

Using it with my newest test which started today.

Early indications are about 15% faster with P-1
 

:w00t:

The user override in undoc.txt for the work file size limit (MaxExponents) doesn't seem to work for me. I'm running 30.7b8, although I never tried the functionality with an earlier build or version.

I picked up four DC wavefront PRP-DCs from the strategic DC thread and added them to my work file (with [c]N/A[/c] AIDs, since PrimeNet rejected registration attempts). Prime95 deleted the last three when I started it, so I added [c]MaxExponents=100[/c] to prime.txt and put the lines back, but they were still removed when I started Prime95 again.

Minus the PRP-DCs I was trying to add, my Prime95 work file currently has one wavefront LL DC, one PRP-CF on a 107,xxx,xxx exponent, and four FTC wavefront certs, for one worker.

George, what's the biggest value B2 can be in PM1 method?

[QUOTE=Miszka;593403]George, what's the biggest value B2 can be in PM1 method?[/QUOTE]

Before embarking on huge P-1 bounds, consider using GMP-ECM or waiting for version 30.8.

[QUOTE=Prime95;593407]Before embarking on huge P-1 bounds, consider using GMP-ECM or waiting for version 30.8.[/QUOTE]
George, see my problem: [URL="https://www.mersenneforum.org/showthread.php?t=27331"]https://www.mersenneforum.org/showthread.php?t=27331[/URL]
As if I used B2 maximum value then the task would end.

v30.7 b9
8600K Coffee Lake CPU, 1 worker, 6 threads. FMA3 FFT (6400K), 120.1M exponent: stage 1 = 72.6 sec, stage 2 = 116.0 sec

[QUOTE=Minty;593589]v30.7 b9
... stage 1 = 72.6 sec, stage 2 = 116.0 sec[/QUOTE]What bounds b1, b2 did it select or you specify? How much ram did you allow it? P-1 or something else?

V30.7b9 Coffee lake CPU, 6 cores 1 workers, FMA3 FFT (5760K), PFactor, 107.4M exp ([M]107485927[/M]) with b1: 853k, b2: 40M (primality tests_saved 2 chose these bounds, 22495MB ram in use during stage 2, 22gb allocated): stage 1 = 79 sec, stage 2 = 117 sec


V30.7b9 Coffee lake CPU, 6 cores 1 workers, FMA3 FFT (3200K), Pfactor, 60.2M exp ([M]60277039[/M]) with b1: 240k, b2: 9M (primality tests_saved 1 chose these bounds, 22512MB ram in use during stage 2, 22gb allocated): stage 1 = 44 sec, stage 2 = 67 sec

[QUOTE=Prime95;593407]Before embarking on huge P-1 bounds, consider using GMP-ECM or waiting for version 30.8.[/QUOTE]

I guess 30.8 will be ready soon?

v30.7 b9
8600K Coffee Lake CPU, 1 worker, 6 threads. FMA3 FFT (6400K), 120.1M exponent: stage 1 = 72.6 sec, stage 2 = 116.0 sec
[QUOTE=kriesel;593598]What bounds b1, b2 did it select or you specify? How much ram did you allow it? P-1 or something else?[/QUOTE]
b1=954000, b2=44734000, P-1, prime95 chose itself with 40GB allocated (think 40984mb actual). Thought it was ratio of stage 1 to 2 times that was mostly the important bit but will happily provide more detail in future

30.7 is now the official release. I'm not sure it is important enough to merit front page coverage.

[QUOTE=Prime95;594109]30.7 is now the official release. I'm not sure it is important enough to merit front page coverage.[/QUOTE]

The amount of P-1 being done by users running the PRP and GIMPS work preferences makes me throw in a vote for "yes." 30.7's significant P-1 improvements over 30.3 should create at least some boost to overall throughput even if most of the people reached by an announcement aren't doing P-1 full time.

[QUOTE=Prime95;594109]30.7 is now the official release. I'm not sure it is important enough to merit front page coverage.[/QUOTE]

Getting this response from the browser. looks like you mixed http in with https

Mixed Content: The site at 'https://www.mersenne.org/' was loaded over a secure connection, but the file at 'http://www.mersenne.org/ftp_root/gimps/p95v307b9.win64.zip' was loaded over an insecure connection. This file should be served over HTTPS. This download has been blocked.

[QUOTE=gjmccrac;594142]looks like you mixed http in with https[/QUOTE]Whoops, thanks for catching that, fixed now.

Small bug report for resumed P-1 work
 

Input

[CODE]
$ cat worktodo.txt

Pminus1=1,2,10061,-1,200000,200000
Pminus1=1,2,10061,-1,100000,5000000

$ ./mprime -d
(some lines omitted)
[Work thread Nov 30 02:05] P-1 on M10061 with B1=100000, B2=5000000
[Work thread Nov 30 02:05] M10061 stage 1 complete. 288828 transforms. Total time: 0.169 sec.
...
[Work thread Nov 30 02:05] Using 3168MB of memory. D: 510510, 46080x580022 polynomial multiplication.
[Work thread Nov 30 02:05] M10061 stage 2 complete. 4317618 transforms. Total time: 23.979 sec.
[Work thread Nov 30 02:05] M10061 completed P-1, B1=100000, B2=249059450640, Wi8: FD5E25C1
[/CODE]

Expected

[CODE]
$ cat results.txt
UID: ANONYMOUS, M10061 completed P-1, B1=200000, Wi8: 00431AF1
[Tue Nov 30 02:05:31 2021]
UID: ANONYMOUS, M10061 completed P-1, B1=[B]200000[/B], B2=249059450640, Wi8: FD5E25C1
[/CODE]

Actual

[CODE]
$ cat results.txt
UID: ANONYMOUS, M10061 completed P-1, B1=200000, Wi8: 00431AF1
[Tue Nov 30 02:05:31 2021]
UID: ANONYMOUS, M10061 completed P-1, B1=100000, B2=249059450640, Wi8: FD5E25C1
[/CODE]

I assume the P-1 is resumed from the residual after B1=200000 so it seems like prime95 should report the larger (and correct) B1 value in the 2nd result.

[QUOTE=techn1ciaN;594113]The amount of P-1 being done by users running the PRP and GIMPS work preferences makes me throw in a vote for "yes." 30.7's significant P-1 improvements over 30.3 should create at least some boost to overall throughput even if most of the people reached by an announcement aren't doing P-1 full time.[/QUOTE]

I agree as well. 30.3 had been around for only a year on the front page. I wouldn't have known about 30.7 unless I checked somewhere like majorgeeks (which is where I get my latest Prime95 version) or the forums.

I found a paper co-authored by George that talks about the new prime-pairing method used in P-1: [url]https://eprint.iacr.org/2021/1462[/url]

It seems that in the latest versions of Prime95 30.7 build 7 the successful communication with the server on completion of a successful LL test is entered in the prime.log without a date stamp.

[QUOTE=S485122;594309]It seems that in the latest versions of Prime95 30.7 build 7 the successful communication with the server on completion of a successful LL test is entered in the prime.log without a date stamp.[/QUOTE]

Looks like it's related to this issue: [url]https://mersenneforum.org/showthread.php?p=561866[/url]

[QUOTE=ixfd64;594311]Looks like it's related to this issue: [url]https://mersenneforum.org/showthread.php?p=561866[/url][/QUOTE]Indeed !

And I must conclude after a more thorough look at the log file that my impression that there was no problem with 30.7 build 5 is wrong as well.
I would prefer to have each communication session preceded by a time stamp in the log file even if seconds apart.

Icing on the cake would be to have Prime95 output all date and times in ISO format, on screen and in the log files, or have an option for choosing the time format. But this is only cosmetic and thus not urgent.

Some comments about the latest release:

1. It's probably a good idea to mention in [C]whatsnew.txt[/C] that the Brent-Suyama extension has been completely removed. Or at least I'm assuming that's the case because it's not even mentioned in [C]undoc.txt[/C] anymore.

2. You might also want to clarify that the new [C]tutorial.txt[/C] file is in the source code package. I was about to post that the file is missing until I thought to check the Prime95 source code.

3. I ran the documentation through a spell checker and found some typos:

[B]readme.txt[/B]

Line 560: "The most common [COLOR="red"]errors[/COLOR] message is [...]"

I assume you meant a singular "error" here.

[B]undoc.txt[/B]

Line 77: "This [COLOR="red"]let's[/COLOR] you do certifications [...]"

Line 101: "[...] if a hardware error has [COLOR="red"]occured[/COLOR] in the last [...]"

Line 640: "This may lead to more consistent benchmarks that are more [COLOR="Red"]indicitive[/COLOR] of what will happen running [...]"

Lines 674-675: "This tells the program how [COLOR="Red"]wany[/COLOR] workers are allowed to use lots of memory."

Lines 753-755: "[...] error check of doing each iteration twice and [COLOR="red"]periodicly[/COLOR] comparing residues. Set to 3 to force the much slower error check of doing each iteration twice and [COLOR="red"]periodicly[/COLOR] comparing residues."

Line 806: "In [COLOR="red"]linux[/COLOR] you can select [...]"

Should probably be capitalized.

[QUOTE=ixfd64;594378]I ran the documentation through a spell checker and found some typos:[/QUOTE]

Thanks!

I am running prim95 v30.7b9 WIN64 - latest version from [url]https://www.mersenne.org/download/[/url] .

I am/was in the middle of "factor P-1 large"/"PM1-L" for candidate 108043021 in the context of GIMPS project - [url]https://www.mersenne.org/report_exponent/?exp_lo=108043021&full=1[/url]

I paused the worker via GUI (opened window Test->Stop) as I had some other work to do on the PC.
Half an hour later I continued searching. Via opened window I went Test->Continue.

The logs are causing some concern to me - attachment [B]prime_95_feature.png[/B] .

When I clicked Stop stage 1 M108043021 was 71.23% complete. When I continued all of a sudden the stage 1 was at 71.78% complete.

I don't know if this is expected behaviour or is it a bug, it skipped a step, and my run is thus invalid. Any thoughts?

Screenshot is attached.

Thanks for the help.

Cheers.

[QUOTE=jakasi2;594654]I am running prim95 v30.7b9 WIN64 - latest version from [url]https://www.mersenne.org/download/[/url] .

I am/was in the middle of "factor P-1 large"/"PM1-L" for candidate 108043021 in the context of GIMPS project - [url]https://www.mersenne.org/report_exponent/?exp_lo=108043021&full=1[/url]

I paused the worker via GUI (opened window Test->Stop) as I had some other work to do on the PC.
Half an hour later I continued searching. Via opened window I went Test->Continue.

The logs are causing some concern to me - attachment [B]prime_95_feature.png[/B] .

When I clicked Stop stage 1 M108043021 was 71.23% complete. When I continued all of a sudden the stage 1 was at 71.78% complete.

I don't know if this is expected behaviour or is it a bug, it skipped a step, and my run is thus invalid. Any thoughts?

Screenshot is attached.

Thanks for the help.

Cheers.[/QUOTE]

Prime95 doesn't output at every step. It runs 100s of iterations per update. When you paused it will have written a save file wherever it was up to. This will be the point it resumed from. There is nothing to worry about.

Thanks for the answer

307MB for wavefront P-1... :sad:
This is why we need more dedicated P-1'ers at the wavefront.

[QUOTE=James Heinrich;594663]307MB for wavefront P-1... :sad:
This is why we need more dedicated P-1'ers at the wavefront.[/QUOTE]

Yes, 300MB is the default. The default should be higher. However, most likely moot point.

[QUOTE=James Heinrich;594663]307MB for wavefront P-1... :sad:
This is why we need more dedicated P-1'ers at the wavefront.[/QUOTE]

I run P-1 on my mid-range AMD Zen laptop (Zen 2 / 6 cores, 13 GB RAM allocated) and I get through eight runs a day with work lines manually rewritten to have [c]tests_saved=1[/c]. If the server-side [c]tests_saved[/c] value is adjusted downwards, then less than 50* other people like myself would be needed to keep ahead of primality testing — with huge RAM, potentially even fewer once 30.8 goes gold.

Concerningly, it seems that jakasi2 is actually running full-time P-1 himself, since his assignment for M[M]108043021[/M] cleared after he turned P-1 in. jakasi2 — if you are still reading this thread, you have not given Prime95 enough RAM for P-1 to be a productive use of your computing time. You turned in P-1 without doing stage 2, when allocating (for example) a few GB of RAM instead of the default 300 MB would allow you to run this stage, giving you a much better chance of finding a factor for similar or even less run time. If this is not an amount of RAM you can give up, consider running something other than P-1, like PRP or DC testing.

[QUOTE=axn;594664]Yes, 300MB is the default. The default should be higher.[/QUOTE]

I believe Mr. Woltman has said that a fresh Prime95 installation left at default settings can't be intrusive to normal PC use, which hogging GBs of RAM would fall under. Anything more than maybe 500 MB (which is still not enough for stage 2 at the PRP wavefront) is probably out of the question.

* Napkin math assuming that the mersenne.org daily "First Prime Tests" value is accurate and doesn't include PRP-CF tests.

[QUOTE=jakasi2;594654]I paused the worker via GUI (opened window Test->Stop) as I had some other work to do on the PC.
Half an hour later I continued searching. Via opened window I went Test->Continue.

...Any thoughts?
[/QUOTE]Welcome. Normally, pausing prime95 is unnecessary. It runs at lower priority. Read the documentation shipped with prime95. You can set it to pause when it detects specific other applications, such as unusually memory hungry apps. Check how much free ram you normally have. It's very likely that a mere 300MB is too conservatively low and slowing your prime95 P-1 work.
See also the reference info collection at [URL]https://mersenneforum.org/showthread.php?p=521922#post521922[/URL]
And if you have a capable GPU, it could be contributing more than your CPU, with the right software.

[QUOTE=techn1ciaN;594666]I believe Mr. Woltman has said that a fresh Prime95 installation left at default settings can't be intrusive to normal PC use, which hogging GBs of RAM would fall under. Anything more than maybe 500 MB (which is still not enough for stage 2 at the PRP wavefront) is probably out of the question.[/QUOTE]I posit that it would be better to have installations without at least a bare minimum of reasonable RAM (4GB? but this number will just get higher as the wavefront advances) allocated that they should just not do P-1 at all rather than do it badly. Have them do already-PM1'd PRP, or if none are available then PRP-DC. Even doing first-time PRP without P-1 would be better, even if it risks wasted cycles on the small chance of a P-1 factor, since those cycles will be wasted anyways if someone ends up re-doing the badly-done P-1 at a later date (and someone certainly will, eventually).

[QUOTE=James Heinrich;594679]I posit that it would be better to have installations without at least a bare minimum of reasonable RAM (4GB? but this number will just get higher as the wavefront advances) allocated that they should just not do P-1 at all rather than do it badly. Have them do already-PM1'd PRP, or if none are available then PRP-DC. Even doing first-time PRP without P-1 would be better, even if it risks wasted cycles on the small chance of a P-1 factor, since those cycles will be wasted anyways if someone ends up re-doing the badly-done P-1 at a later date (and someone certainly will, eventually).[/QUOTE]

My Xeon Phi barfs at P-1. I am running 32 workers with 16GB RAM. It would be nice to have the option to grab P-1-less tasks, assuming there is a great effort to do tons of P-1 by others at the wavefront.

jakasi2, please consider allocating more memory for P-1 if you can. This will allow Prime95 to run stage 2 and increase the chance of finding a factor.

[QUOTE=paulunderwood;594687]My Xeon Phi barfs at P-1. I am running 32 workers with 16GB RAM.[/QUOTE]Cut back to 4 workers. Latency will improve tremendously, and occasional P-1 runs are unlikely to coincide. The loss of total throughput is modest.

[QUOTE=ixfd64;594378]I ran the documentation through a spell checker and found some typos[/QUOTE]

In whatsnew.txt:
Section 30.7, second point, it should be [I]perspective[/I] instead of [I]perpective[/I].
Section 25.7, first point, it should be [I]used[/I] instead of [I]unsed[/I].
Section 22.2, third point, it should be [I]aggressive[/I] instead of [I]aggresive[/I].
Section 22.1, fourth point, it should be [I]override[/I] instead of [I]overide[/I].
Section 21.2, eighth point, it should be [I]occurred[/I] instead of [I]occured[/I].

Prime95 30.7 build 9 crash
 

Hi,


I just installed the latest build. And it is doing poorly at managing RAM.
It just crashes. If I run 4 workers, the first and second workers pick up to much ram.
It ends up having to restart the third and fourth with different size and crashes.

The previous version would divide equally the available ram to the 4 workers.
This build does not.

I have to give it all available RAM to make it work.

Anybody having the same issue ?

Is it possible to get a Mac OS 64 bit version or instructions for how to compile?

[QUOTE=emiller;595565]Is it possible to get a Mac OS 64 bit version or instructions for how to compile?[/QUOTE]

Try this: [url]https://www.dropbox.com/s/xo7psmmjfkb52pr/p95v303b6.MacOSX.tar.gz?dl=0[/url]

It is version 30.3 command line version which supports PRP proofs. As always, only for Intel CPUs.

Thanks for the link but this version is giving me the following:

[CODE]dyld: Symbol not found: _curl_mime_init
Referenced from: /Users/emiller/prime95/p95v303b6.MacOSX/./mprime
Expected in: /usr/lib/libcurl.4.dylib

Abort trap: 6[/CODE]

I found a link to this build earlier, thought I'd ask if there was a more recent build.

Maybe a build with only static linking?

[QUOTE=emiller;595593]Thanks for the link but this version is giving me the following:

[CODE]dyld: Symbol not found: _curl_mime_init
Referenced from: /Users/emiller/prime95/p95v303b6.MacOSX/./mprime
Expected in: /usr/lib/libcurl.4.dylib

Abort trap: 6[/CODE]

I found a link to this build earlier, thought I'd ask if there was a more recent build.[/QUOTE]

I just built 30.7 build 9. It likely has the same libcurl problem. If so, let me know and I'll see if static linking is possible.

[QUOTE=Prime95;596975]I just built 30.7 build 9. It likely has the same libcurl problem. If so, let me know and I'll see if static linking is possible.[/QUOTE]Available here, if that wasn't immediately apparent:
[url]https://mersenne.org/ftp_root/gimps/p95v307b9.MacOSX.tar.gz[/url]

[QUOTE=emiller;596313]Maybe a build with only static linking?[/QUOTE]

I think I figured out how to do this, please report on whether it worked.

A small advice to the Prime95 software
 

In the Prime95 software, when I clicked on 'Advanced--ECM', the default setting of the 'number to factor' is 2^1061-1. However, this number has been completely factored roughly ten years ago, so I wish the default could be changed to 2^1277-1, which is currently the smallest Mersenne composite that we haven't found any factors of.

[QUOTE=congsz;597547]In the Prime95 software, when I clicked on 'Advanced--ECM', the default setting of the 'number to factor' is 2^1061-1. However, this number has been completely factored roughly ten years ago, so I wish the default could be changed to 2^1277-1, which is currently the smallest Mersenne composite that we haven't found any factors of.[/QUOTE]
Yes, but millions of GHZ-days have already been spent on that exponent with no factor found. the smallest factor might be at least 2^300.
Maybe no default number?
(Happy to see another Chinese user :bounce:)
[spoiler](ps: why don't you suggest 2^1949001-1 ....)[/spoiler]

Segmentation fault on Debian Linux
 

Not very popular case, P-1 then TF-LMH, but still. Version mprime-30.7b9 on Linux Debian on 4-core E3-1240 v6 CPU crashes when completing P-1 and switching to trial factoring.
My configuration has 1 worker and 4 cores.

worktodo.txt
PFactor=3D003848AAF4D766D47DC6759098C9B1,1,2,108611647,-1,77,2
Factor=621092F3083ADEA698FF551DF07864ED,238617823,73,74

When trying to send the result to server and switch from 4 threads on P-1 (one main, three helpers) to 8 threads on TF the application crashes.

./mprime -d -c

This reports the completed work unit to server leaving only Factor= in the worktodo.

./mprime -d

[Main thread Jan 16 06:28] Mersenne number primality test program version 30.7
[Main thread Jan 16 06:28] Optimizing for CPU architecture: Core i3/i5/i7, L2 cache size: 4x256 KB, L3 cache size: 8 MB
[Main thread Jan 16 06:28] Starting worker.
[Work thread Jan 16 06:28] Worker starting
[Work thread Jan 16 06:28] Setting affinity to run worker on CPU core #1
[Work thread Jan 16 06:28] Setting affinity to run helper thread 1 on CPU core #1
[Work thread Jan 16 06:28] Setting affinity to run helper thread 3 on CPU core #2
[Work thread Jan 16 06:28] Setting affinity to run helper thread 5 on CPU core #3
[Work thread Jan 16 06:28] Setting affinity to run helper thread 7 on CPU core #4
[Work thread Jan 16 06:28] Starting trial factoring of M238617823 to 2^74
[Work thread Jan 16 06:28] Setting affinity to run helper thread 2 on CPU core #2
Segmentation fault

Manually run TF on mfaktc on Windows, so no work unit is lost.

Could somebody please look at the Seg fault issue.

With an AVX512F capable processor I see 2 to 4 % lower iteration times on bigger exponents using a 3200 K FFT than lower exponents using a 3136 K FFT. I could force the FFT length.
As far as I know, the benchmarks do not test different FFT length for a given exponent.

[QUOTE=pyajve;598068]Version mprime-30.7b9 on Linux Debian on 4-core E3-1240 v6 CPU crashes when completing P-1 and switching to trial factoring.

Could somebody please look at the Seg fault issue.[/QUOTE]

Will be fixed in next 30.8 build. Only affects TF using the AVX-512 instruction set. It is an assembler bug with an easy workaround.

Hello Prime95, I just ran into a small issue when compiling 30.7b9 with MingW64 in MSYS. I just needed to make two small changes to the makemw64 file to correct these issues and get the gwnum.a library to build.

First, on line 29 I needed to add a line continuation character [C]\[/C].
Second, I needed to add a target to build radix.o.

Third, I needed to add "#include <sys/time.h>" to line 68 of gwutil.h to get rid of a warning during compile:
[CODE]
gcc -I.. -I../sqlite-amalgamation-3180000 -DX86_64 -DWINDOWS64 -O2 -o mw64/giants.o -c giants.c
In file included from giants.c:23:
gwutil.h:68:26: warning: 'struct timeval' declared inside parameter list will not be visible outside of this definition or declaration
int gettimeofday (struct timeval *tp, void *tzp);
^~~~~~~
gcc -I.. -I../sqlite-amalgamation-3180000 -DX86_64 -DWINDOWS64 -O2 -o mw64/radix.o -c radix.c
In file included from radix.c:17:
gwutil.h:68:26: warning: 'struct timeval' declared inside parameter list will not be visible outside of this definition or declaration
int gettimeofday (struct timeval *tp, void *tzp);
^~~~~~~
[/CODE]
I have attached the updated makemw64.

[QUOTE=WraithX;598355]
Third, I needed to add "#include <sys/time.h>" to line 68 of gwutil.h to get rid of a warning during compile[/QUOTE]

Which, of course, breaks the MSVC build. Is there a MINGW ifdef I can test?

[QUOTE=Prime95;598365]Which, of course, breaks the MSVC build. Is there a MINGW ifdef I can test?[/QUOTE]

Ah, sorry. Good catch! Yes, there are two you can use:
[CODE]
#define __MINGW32__ 1
#define __MINGW64__ 1
[/CODE]
I'd recommend using the mingw64 target. If someone needs the mingw32 target, we can check at that time how to resolve any issues they have.

This is not relevant any more since there is no more GIMPS work with that FFT length, but it seems that 2940 KiB FFT's are slower than they should be.
That FFT size seems to be AVX512 specific, but shouldn't it be 2944 KiB instead ? (An odd multiple of 4096 while the "neighbouring" FFTs are multiples of 65536...)
Just curious.

2944 = 2^7 * 23. Ignore the powers of 2. AFAIK, George hasn't implemented a 23 FFT.
2940 = 2^2 * 3 * 5 * 7^2, which looks better. Still... a multiple of 735 is unusual. Probably will be slower than expected. 3072 ought to be faster.

2916 & 2880 seems to be more "normal" smaller sizes.

[QUOTE=axn;599518]2944 = 2^7 * 23. Ignore the powers of 2. AFAIK, George hasn't implemented a 23 FFT.
...[/QUOTE]In other words I just showed my ignorance of how the FFT innards work. [noparse]:-([/noparse]

[QUOTE=axn;599518]2944 = 2^7 * 23. Ignore the powers of 2. AFAIK, George hasn't implemented a 23 FFT.
2940 = 2^2 * 3 * 5 * 7^2, which looks better. Still... a multiple of 735 is unusual. Probably will be slower than expected. 3072 ought to be faster.

2916 & 2880 seems to be more "normal" smaller sizes.[/QUOTE]
I wonder if there's a 5888k FFT (which handles 110M exponents).
(5888=2^8*23, which is an auspicious number in Chinese, because it sounds roghly like "I'm rich rich rich") :grin:

prime95 or Win10 or hwloc confused by dimms added to xeon phi system
 

Xeon Phi 7250 is a 68-core & x4 HT CPU with 8 channels MCDRAM (totaling 16GiB). A 7210 is similar but 64-core.
The motherboard Supermicro K1SPE has 6 DIMM slots. With all DIMM slots empty, prime95 shows activity of one thread per physical core in Task Manager, where the hyperthreads of a specific core appear in succession. Windows 10 Task Manager displays the correct numbers of physical and logical cores, correct cache amounts, etc.

When DIMMs are added (observed with 1 32 or 64GiB in slot A, 3 32GiB in A-C, 6 32GiB in A-F), Task Manager shows 234 physical cores, 272 logical for the 7250, or 208 physical, 256 logical for the 7210, and odd figures for cache amounts. Prime95 shows core numbers higher than are physically present per Intel spec.
With any DIMMs installed, Task Manager shows a different pattern of logical core use that appears to be using multiple hyperthreads in prime95 when intending not to. Iteration times are noticeably longer than before the DIMMs were added.

In Ubuntu 18.04 atop WSL1 on Win10, after the DIMMs are added, stream.c shows ~30% higher memory bandwidth.

Run a prime95 benchmark (abort it). Results.bench.txt will contain hwloc's description of your machine.

hwloc's portion looks ok to me.

Very disparate ETAs on Xeon Phi 7210
 

Hi,

On Win10 pro, Xeon Phi 7210, prime95 v30.7b9, PrimeNet connected, manual assignments, I'm seeing very disparate ETAs between status output and worker windows, that leads to months discrepancies for exponents currently in progress, and YEARS difference in ETAs for following work (which should all complete within ~1 year).
Also the CPU clock rate ("Speed") is misrepresented on my Computer Properties page, and I have not found a way to fix that. Should be 1.3 GHz, is 0.346 GHz. (3.76:1 ratio)

W1 332897017 ~39. d vs. ~204. d ~5.23 ratio;
W2 344587487 ~18.27 d vs 126. d ~6.90 ratio.

Help!

CpuSpeed=1300 in local.txt might help

Thanks, had
[CODE]OldCpuSpeed=357
NewCpuSpeedCount=0
NewCpuSpeed=0
RollingAverage=1439
RollingAverageIsFromV27=1[/CODE]at front of local.txt, stopped, ripped it all out and replaced with
[CODE]CpuSpeed=1300[/CODE]and restarted, seemed to help somewhat, now instead of 2027 completion it's 2024, progress, still showing ~16 d for W2 current task in window, vs. ~50 d for test, status output, ratio ~3.125.

Ripped out also from local.txt after a stop,
[CODE]RollingHash=1658280022
RollingStartTime=1645375426
RollingCompleteTime=29035662[/CODE]restart, but no further improvement. (Saved ripped lines in case they need to be restored, in both cases.)

On prime95, Advanced, manual communication, update server now checked, ok.
My assignments page looks a little more sensible now.

The PrimeNet server still thinks there are 4 workers, but there are two, in prime95 GUI display, worktodo.txt, local.txt, prime.txt. There seems no way to remove the 3rd & 4th worker entries on the cpu properties web page from the server side, or from prime95.

Work preferences also do not match between client menus and server page; "what makes sense" x 1-4 on server page, DC LL with PRP/proof set on prime95, w1, w2 of two (displays as "other").

Server cpu page also indicates no benchmarks recorded. I know I did exhaustive benchmarking early on. Results.bench.txt is ~1.2 MB.

Mprime needs its own separate section away from Prime95. I am trying to find and/or remember what the command is to get mprime to display its output on the screen and I cannot...

[CODE]./mprime ????[/CODE]

:evil:

[QUOTE=storm5510;600622]I am trying to find and/or remember what the command is to get mprime to...[/QUOTE][code]./mprime -h
Usage: mprime [-bcdhmstv] [-aN] [-wDIR] [-pPIDFILE]
-b Run a predefined throughput benchmark, then exit.
-c Contact the PrimeNet server, then exit.
-d Print detailed information to stdout.
-h Print this.
-m Menu to configure mprime.
-s Display status.
-t Run the torture test.
-v Print the version number.
-aN Use an alternate set of INI and output files (obsolete).
-wDIR Run from a different working directory.
-pPIDFILE Filename for the PID file. Default is mprime.pid.[/code]

[QUOTE=James Heinrich;600623][code]./mprime -h
Usage: mprime [-bcdhmstv] [-aN] [-wDIR] [-pPIDFILE]
-b Run a predefined throughput benchmark, then exit.
-c Contact the PrimeNet server, then exit.
-d Print detailed information to stdout.
-h Print this.
-m Menu to configure mprime.
-s Display status.
-t Run the torture test.
-v Print the version number.
-aN Use an alternate set of INI and output files (obsolete).
-wDIR Run from a different working directory.
-pPIDFILE Filename for the PID file. Default is mprime.pid.[/code][/QUOTE]

Thank you! I remembered it [U]after[/U] I went to bed last night. It seems like this would be a default, but I guess not.

On prime95 v30.7b9, with options, preferences, days of work to queue up, set to zero to phase out / shut down a low power efficiency (core2 duo) system, startup to check there was no work queued resulted in it getting a Cert to run despite the zero work queue setting.

[QUOTE=kriesel;600982]On prime95 v30.7b9, with options, preferences, days of work to queue up, set to zero to phase out / shut down a low power efficiency (core2 duo) system, startup to check there was no work queued resulted in it getting a Cert to run despite the zero work queue setting.[/QUOTE]

Will fix.