|
Prime95 v30.4/30.5/30.6
Prime95 version 30.5 build 2 is available.
I consider this pretty stable software. Those doing P-1 and ECM work should upgrade. First time PRP testers can consider upgrading for the minor speed boost doing P-1 required prior to some first-time assignments. From whatsnew.txt: [CODE]1) Faster P-1 stage 2. 2) Faster ECM stage 1 and stage 2. 3) Gwnum library overhauled. Many functions deprecated. Replaced by more powerful gwmul3. New functions that compute (a+b)*c and (a-b)*c with less memory accesses. Faster conversion to and from binary. 4) ECM and P-1 can find the best B2 value for the amount of memory prime95 is allowed to use. For ECM, this happens when the worktodo.txt line sets B2=100*B1 which is the default assignment from the PrimeNet server. For P-1, the best B2 is chosen when the worktodo.txt line specifies the trial factoring depth. For example, "Pminus1=1,2,20000003,-1,500000,0,70" chooses the best B2 bound for B1=500000 given that M20000003 has been trial factored to 2^70. [/CODE] Download links: Windows 64-bit: [URL]https://mersenne.org/ftp_root/gimps/p95v305b2.win64.zip[/URL] Linux 64-bit: [URL]https://mersenne.org/ftp_root/gimps/p95v305b2.linux64.tar.gz[/URL] FreeBSD 64-bit: [URL]https://mersenne.org/ftp_root/gimps/p95v305b2.FreeBSD11-64.tar.gz[/URL] Source: [URL]https://mersenne.org/ftp_root/gimps/p95v305b2.source.zip[/URL] Windows 32-bit: [URL]https://mersenne.org/ftp_root/gimps/p95v305b2.win32.zip[/URL] Linux 32-bit: [URL]https://mersenne.org/ftp_root/gimps/p95v305b2.linux32.tar.gz[/URL] Windows Service 64-bit: [URL]https://mersenne.org/ftp_root/gimps/p95v305b2.win64.service.zip[/URL] Windows Service 32-bit: [URL]https://mersenne.org/ftp_root/gimps/p95v305b2.win32.service.zip[/URL] You can find info on the first 4 v30.4 builds as well as some questions and answers on new features starting here in the [URL="https://www.mersenneforum.org/showthread.php?p=566466#post566466"]20M thread[/URL] Please report any bugs you may find. |
1) After ECM stage 2 memory is not freed back to the OS in Linux leading to process killed due to out-of-memory. Fixed in build 6.
2) Continuing from an old P-1 save file in stage 2 crashes. Fixed in build 6. 3) Rare P-1 and ECM infinite loops during stage 2 init (well, technically until another worker exits stage 2). Fixed in build 6. 4) PRP on 1435648^131072+1 hangs. Fixed in build 6. 5) Memory corruption and crash possible when ECM chose N^2 modular inverse pooling (occurs when available stage 2 memory is very low). Fixed in build 7. 6) Possible crash bug in stage 2 init when initial stage 2 plan used too much memory. Fixed in build 9. 7) There were no small all-complex FFTs defined for Zen architecture. Thus, ECM on small Fermats gave a "cannot initialize FFT" error. Fixed in 30.5 build 1. 8) PRP roundoff errors during the last 50 iterations are possible (for a small range of exponents below the FFT limit). Fixed in 30.5 build 1. 9) Interrupting P-1 in stage 2, then changing worktodo.txt to a higher B1 and restarting could cause a crash. Fixed in 30.5 build 2. [B]10) Torture testing is broken!! Fixed in 30.6 build 4[/B] |
I have not yet installed Build 5, so the following observation relates to Build 4 (and possibly 3). I don´t think it will make a difference, though.
I have Prime95 running 24/7, and it has ever been running pretty smoothly on my quad core i5-7400 at default settings. I installed v30.4b2 just before Christmas and later upgraded to build 3 and then 4, as they were being made available. Everything ok, except for two times now I happened to note Prime95 had died while I was away from the computer. No messages on screen, the small green square had simply vanished and there was no trace of the process in Task Manager.. Digging Windows logs, I found that on the two occasions (first one on the 29th of December, second on the 3rd of January), the cause was an Application Error, said application being Prime95, with an Exception Code [B]0xc0000005[/B]. This code refers to a Address Violation, i.e., the program appears to have used non allocated memory and hence was shut down by the OS. I did a SFC and found no errors, and saw no other occurences of this error for a really long time (never on this machine, actually). Apart from this, the new version seems to be pretty stable and have already found some ECM factors, both on windows and Linux (I´m running it on several colab instances where, by the way, I didn´t (yet?) have this problem). Any ideas/thoughts/suggestions? Note: Upon installing build 3 and then 4, I got a message from the OS to confirm I was really willing to run the exe file, as its origin was not confirmed/trusted. I am not running any AV, just Windows Defender. |
I'm noticing a small speed decrease with ECM on M1277 (even with PracSearch=1) compared to 30.3b6 on Haswell i5.
Can someone confirm this? (I'm using OutputIterations=30000000) 30.3b6: [CODE] M1277 curve 2 stage 1 at prime 4520437637 [59.47%]. Time: 9.504 sec. M1277 curve 2 stage 1 at prime 4522699141 [59.50%]. Time: 9.598 sec. [/CODE]30.4 with PracSearch=1 (default gives around 10.xxx sec) [CODE] M1277 curve 1 stage 1 at prime 178990073 [2.35%]. Time: 9.711 sec. M1277 curve 1 stage 1 at prime 181260257 [2.38%]. Time: 9.712 sec. [/CODE] |
[QUOTE=UBR47K;568333]I'm noticing a small speed decrease with ECM on M1277 (even with PracSearch=1) compared to 30.3b6 on Haswell i5.[/QUOTE]
Are you using Prime95 or mprime? Several of us, including myself, have noticed minor slowdowns like that in mprime, triggered by simply stopping and restarting the program. So for linux at least, I would suggest that valid time comparisons can be made only if performed after a fresh reboot of the system it's running on. |
[QUOTE=PhilF;568335]Are you using Prime95 or mprime? Several of us, including myself, have noticed minor slowdowns like that in mprime, triggered by simply stopping and restarting the program.
So for linux at least, I would suggest that valid time comparisons can be made only if performed after a fresh reboot of the system it's running on.[/QUOTE] Using mprime here. You're right, the timings are a bit different after another run. I'm hitting another issue right now, mprime gets killed by OOM: [CODE] ... [Worker #4 Jan 4 15:24] M1277 curve 1 stage 1 at prime 333859213 [4.39%]. Time: 9.595 sec. [Worker #1 Jan 4 15:24] Stage 1 complete. 6467614 transforms, 1 modular inverses. Time: 324.497 sec. [Worker #1 Jan 4 15:24] Optimal B2 is 154*B1 = 38500000. [Worker #4 Jan 4 15:24] M1277 curve 1 stage 1 at prime 336129743 [4.42%]. Time: 9.594 sec. [Worker #1 Jan 4 15:24] D: 4620, relative primes: 6955, stage 2 primes: 2325683, pair%=92.66 [Worker #1 Jan 4 15:24] Stage 2 uses 5270MB of memory, 2 FFTs per prime pair, 3-mult modinv pooling, pool size 7693. [Worker #4 Jan 4 15:24] M1277 curve 1 stage 1 at prime 338402387 [4.45%]. Time: 9.722 sec. [Worker #1 Jan 4 15:24] Stage 2 init complete. 196757 transforms, 1 modular inverses. Time: 10.625 sec. [Worker #4 Jan 4 15:25] M1277 curve 1 stage 1 at prime 340669547 [4.48%]. Time: 9.713 sec. [Worker #4 Jan 4 15:25] M1277 curve 1 stage 1 at prime 342940799 [4.51%]. Time: 9.674 sec. [Worker #4 Jan 4 15:25] M1277 curve 1 stage 1 at prime 345207923 [4.54%]. Time: 9.672 sec. [Worker #4 Jan 4 15:25] M1277 curve 1 stage 1 at prime 347478463 [4.57%]. Time: 9.672 sec. [Worker #4 Jan 4 15:25] M1277 curve 1 stage 1 at prime 349751357 [4.60%]. Time: 9.672 sec. [Worker #4 Jan 4 15:25] M1277 curve 1 stage 1 at prime 352022999 [4.63%]. Time: 9.672 sec. [Worker #4 Jan 4 15:25] M1277 curve 1 stage 1 at prime 354290843 [4.66%]. Time: 9.673 sec. [Worker #4 Jan 4 15:26] M1277 curve 1 stage 1 at prime 356560163 [4.69%]. Time: 9.671 sec. [Worker #4 Jan 4 15:26] M1277 curve 1 stage 1 at prime 358833499 [4.72%]. Time: 9.672 sec. [Worker #4 Jan 4 15:26] M1277 curve 1 stage 1 at prime 361107037 [4.75%]. Time: 9.672 sec. [Worker #4 Jan 4 15:26] M1277 curve 1 stage 1 at prime 363374651 [4.78%]. Time: 9.672 sec. [Worker #4 Jan 4 15:26] M1277 curve 1 stage 1 at prime 365644387 [4.81%]. Time: 9.671 sec. [Worker #4 Jan 4 15:26] M1277 curve 1 stage 1 at prime 367912399 [4.84%]. Time: 9.672 sec. [Worker #1 Jan 4 15:27] Stage 2 complete. 2672527 transforms, 1 modular inverses. Time: 132.611 sec. [Worker #1 Jan 4 15:27] Stage 2 GCD complete. Time: 0.044 sec. [Worker #1 Jan 4 15:27] [Worker #1 Jan 4 15:27] ECM on M615749: curve #10 with s=8879663910729420, B1=250000, B2=TBD [Worker #4 Jan 4 15:27] M1277 curve 1 stage 1 at prime 370186381 [4.87%]. Time: 9.653 sec. [Worker #3 Jan 4 15:27] Stage 1 complete. 6467614 transforms, 1 modular inverses. Time: 356.077 sec. [Worker #3 Jan 4 15:27] Optimal B2 is 154*B1 = 38500000. [Worker #3 Jan 4 15:27] D: 4620, relative primes: 6955, stage 2 primes: 2325683, pair%=92.66 [Worker #3 Jan 4 15:27] Stage 2 uses 4921MB of memory, 2 FFTs per prime pair, 3-mult modinv pooling, pool size 7693. Killed [/CODE]Specs: i5-4690K, 2x4GB DDR3 RAM 4 Workers, 1 Core each: [CODE] [Worker #1] ECM2=N/A,1,2,615749,-1,250000,25000000,330 [Worker #2] ECM2=N/A,1,2,579331,-1,250000,25000000,330 [Worker #3] ECM2=N/A,1,2,588893,-1,250000,25000000,330 [Worker #4] ECM2=N/A,1,2,1277,-1,7600000000,7600000000,1 [/CODE] |
I don't remember if the P-1/ECM memory allocation refers to [I]per worker[/I] or not.
If it does, then you can't have more than one worker doing stage 2 at a time since you have only 8GB of total memory, unless you lower the memory allocation to 1GB per worker. |
I tried out the PracSearch parameter and compared the perfomance of stage 1 in 30.4b5 against version 29.8, using my Ryzen 3950X (=Zen2 architecture):
M1277 [LIST][*]PracSearch=1 [B]52.7[/B]s[*]PracSearch=7 57.0s[*]version 29.8 55.6s[/LIST]M10,061 [LIST][*]PracSearch=1 24.5s[*]PracSearch=7 [B]24.2s[/B][*]PracSearch=14 25.1s[*]version 29.8 24.6s[/LIST]M100,069 [LIST][*]PracSearch=7 33.3[*]PracSearch=10 [B]32.9[/B][*]PracSearch=14 33.1[*]version 29.8 37.5s[/LIST]M1,000,003 [LIST][*]PracSearch=7 [B]55.3[/B][*]PracSearch=14 55.8[*]version 29.8 69.5s[/LIST]Considering the measurements aren't super precise, it seems PracSearch=7 is a very good choice overall, except for extremely small exponents like M1277. With correct PracSearch parameter, the new version is always faster in stage 1. Very, very nice! |
[QUOTE]- deprecate Brent Suyama (more efficient to put that effort into a larger B1)[/QUOTE]
Is there a way to optionally enable the Brent–Suyama extension? Or has the feature been removed from the code entirely? |
[QUOTE=UBR47K;568338]
I'm hitting another issue right now, mprime gets killed by OOM:[/QUOTE]I was also running into OOM problems when testing earlier builds of 30.4. They were supposed to be fixed in the new version, though. Which operating system are you using? |
[QUOTE=ixfd64;568363]Is there a way to optionally enable the Brent–Suyama extension? Or has the feature been removed from the code entirely?[/QUOTE]
See undoc.txt. Please run a test on a known B-S factor. |
[QUOTE=lycorn;568304]I have not yet installed Build 5,
Any ideas/thoughts/suggestions?[/QUOTE] There was a bug or two in accessing the prime pairing bit array. Try build 5 and keep me updated. [QUOTE=UBR47K;568338] I'm hitting another issue right now, mprime gets killed by OOM[/QUOTE] Trying to replicate here on a Linux quad-core system with 8GB memory. Set max mem allocation to 7GB. [QUOTE=PhilF;568345]I don't remember if the P-1/ECM memory allocation refers to [I]per worker[/I] or not[/QUOTE] The memory allocation is per system, not per worker. Only PRP emergency memory allocation is per worker. One can get per-worker memory limits but not from the menus/dialog boxes. See undoc.txt. [QUOTE=nordi;568366]I was also running into OOM problems when testing earlier builds of 30.4. They were supposed to be fixed in the new version, though. Which operating system are you using?[/QUOTE] UBR47K's problem is different since the M1277 ECM was in stage 1. The primary fix for you was to limit stage 2 temporaries to 100,000. |
The overallocating memory problem seems to be specific to Linux. If I add a malloc_trim() call at the end of each curve, the mprime process is not killed.
If any Linux gurus have insights, I'd appreciate your sharing them. I'm a little baffled as my reading of the mallopt man page seems to indicate malloc_trim is called automatically once 128KB can be freed. |
[QUOTE=Prime95;568380]See undoc.txt. Please run a test on a known B-S factor.[/QUOTE]
Unless primes are being paired the exact same way from before, there is a good chance that 30.4 with B-S enabled will [B]not[/B] find the factor |
[QUOTE=axn;568426]Unless primes are being paired the exact same way from before, there is a good chance that 30.4 with B-S enabled will [B]not[/B] find the factor[/QUOTE]
Doh! Of course you are right. |
[QUOTE=axn;568426]Unless primes are being paired the exact same way from before, there is a good chance that 30.4 with B-S enabled will [B]not[/B] find the factor[/QUOTE]
Or will find factors that the first run didn't :razz: |
[CODE]
Your choice: [Work thread Jan 5 08:51] Worker starting [Work thread Jan 5 08:51] Setting affinity to run worker on CPU core #1 [Work thread Jan 5 08:51] [Work thread Jan 5 08:51] P-1 on M15575663 with B1=1500000, B2=30000000 [Work thread Jan 5 08:51] Setting affinity to run helper thread 1 on CPU core #2 [Work thread Jan 5 08:51] Using FMA3 FFT length 800K, Pass1=320, Pass2=2560, clm=4, 4 threads [Work thread Jan 5 08:51] Setting affinity to run helper thread 3 on CPU core #4 [Work thread Jan 5 08:51] Cannot continue stage 2 from old P-1 save file. Restarting stage 2 from the beginning. [Work thread Jan 5 08:51] Setting affinity to run helper thread 2 on CPU core #3 [Work thread Jan 5 08:51] D: 840, relative primes: 1713, stage 2 primes: 1743704, pair%=90.11 [Work thread Jan 5 08:51] Using 11061MB of memory. [Work thread Jan 5 08:51] Stage 2 init complete. 16961 transforms. Time: 12.169 sec. Segmentation fault (core dumped) [/CODE] reproducible I renamed the file mF57663 so mprime couldn't find it and restarted it. Seems to work. About 33% increase in speed, what is the background behind that? |
I turned on Brent–Suyama again manually to compare the results. About a 3% penalty for an occasional factor circumventing the B2 value. I leave it on.
|
[QUOTE=Prime95;568383]There was a bug or two in accessing the prime pairing bit array. Try build 5 and keep me updated.
[/QUOTE] I just got home to find Prime95 (Build 5) had stopped after ~ 20 hours of work. The symptoms and exception code are the same as before. In case you´re willing to do some debugging, the fault offset is [B]0x0000000002345399[/B]. This was the only error recorded. The application had been functioning perfectly since I launched it. Just restarted it and it´s happily chugging along. |
[QUOTE=Prime95;568415]The overallocating memory problem seems to be specific to Linux. If I add a malloc_trim() call at the end of each curve, the mprime process is not killed.[/QUOTE]
I'm still working on this. A Ubuntu build with debugging on seems to work. A CentOS build without debugging (the way official versions are built) does not. I presume the -g command line arg links in a different heap allocator. [QUOTE=tha;568446][CODE] [Work thread Jan 5 08:51] Cannot continue stage 2 from old P-1 save file. Restarting stage 2 from the beginning. Segmentation fault (core dumped) [/CODE] About 33% increase in speed, what is the background behind that?[/QUOTE] I have a fix for this. Making new builds will be spotty as my wife has my laptop. Her Mac is in the shop for butterfly keyboard repair. Dig around in the 20M thread. The speed boost comes from new gwnum feature that does (a+b)*c in one call saving some memory bandwidth. More speed comes from better prime pairing ~90% vs. ~30% using a Mihai Preda idea. [QUOTE=tha;568468]I turned on Brent–Suyama again manually to compare the results. About a 3% penalty for an occasional factor circumventing the B2 value. I leave it on.[/QUOTE] BS will find fewer factors than before. With 3x better prime pairing, there are 1/3 fewer opportunities for a BS prime > B2 to be included. [QUOTE=lycorn;568508]I just got home to find Prime95 (Build 5) had stopped after ~ 20 hours of work. The symptoms and exception code are the same as before. In case you´re willing to do some debugging, the fault offset is [B]0x0000000002345399[/B]. This was the only error recorded. The application had been functioning perfectly since I launched it. Just restarted it and it´s happily chugging along.[/QUOTE] Can you send me details as to your machine, worktodo, and memory settings? Thanks. |
[QUOTE=Prime95;568530]
Can you send me details as to your machine, worktodo, and memory settings? Thanks.[/QUOTE] CPU: Intel i5-7400 (kaby Lake) @ 3GHz. 16 GB DDR4 2400 memory (dual channel - 2 x 8GB). Everything at default settings. The machine was made by Dell, and has been rock solid since November 2018, when I started using it. Never had crashes, BSODs, etc, and it has found a fair number of ECM factors for exponents < 1M. It came pre installed with Windows 10, and the regular updates have been done without any problems. The first time Prime95 died was on December, 29th, while running v 30.4 build 3 (or 4, I´m not 100% sure). Then it happened again on January, 3rd, running build 4, and then today, running build 5. As I posted earlier, the symptoms were similar on all occasions. The worktodo I´m currently using is: [Worker #1] ECM2=blah-blah,1,2,547273,-1,250000,25000000,400 ECM2=blah-blah,1,2,547291,-1,250000,25000000,400 ECM2=blah-blah,1,2,542911,-1,250000,25000000,300 [Worker #2] ECM2=blah-blah,1,2,547453,-1,250000,25000000,400 ECM2=blah-blah,1,2,547487,-1,250000,25000000,400 ECM2=blah-blah,1,2,542987,-1,250000,25000000,300 [Worker #3] ECM2=blah-blah,1,2,547583,-1,250000,25000000,400 ECM2=blah-blah,1,2,543019,-1,250000,25000000,300 [Worker #4] ECM2=blah-blah,1,2,547397,-1,250000,25000000,400 ECM2=blah-blah,1,2,547609,-1,250000,25000000,400 |
[QUOTE=lycorn;568536]The machine [...] has been rock solid since November 2018, when I started using it. Never had crashes, BSODs, etc, and it has found [/QUOTE]
How much are the temperatures of the toy? (that's the most important info, which I didn't see in the post). It may be, or not be related to switching to v30, or just be coincidental. The machine is old, so it may need some maintenance, you know, removing the dust clogs from the fans, re-seating of the CPU (change/reapply the thermal paste), etc. We do this yearly, or even every 6 months or so. You know, my grandma was virgin for a very long time, but suddenly she wasn't. Luckily for me, otherwise I won't be anymore, and who would post stupid things on mersenneforum? Haha. Your system may as well need nothing of it, but the new version of the program may be stressing the hardware a bit more than the old one, pushing it over the limit of stability. When you (general you) say your computer is stable, it is/was for the conditions you used it at. Any stable computer becomes unstable if you push it, and any crap computer is stable if you only type text documents in it. You may try to temporarily revert to v29 (or v30.3?) that was stable before, and see if the machine is still stable for a week or so. If you do only ECM, it won't matter much anyhow. If it is not stable anymore, you need dusting/re-seating, change or oil the fans, etc., like I said. Stable computers can become suddenly unstable sometimes. If it is still stable with the old version, you still don't know if the issue is the new version of the program. It may be a bug in the new version, but it also could be that the new version is pushing the system a bit more, behind of its stability limit, of which you were very close before. The best way in that case, after upgrading to v30.4 again, is to try reducing the clocks just a little. If it becomes stable again, then the issue is not with P95. You still need dusting. Take the mop. On the other hand, it still could be some new introduced bug in v30.4, it happened in the past, so you did well reporting it. If so, George will fix it, as usual (for sure, he is now at home in quarantine and has absolutely nothing else to do :razz:) |
[QUOTE=lycorn;568536]CPU: Intel i5-7400 (kaby Lake) @ 3GHz. 16 GB DDR4 2400 memory (dual channel - 2 x 8GB). [/QUOTE]
What are your day and night memory settings? |
[QUOTE=Prime95;568549]What are your day and night memory settings?[/QUOTE]
12 GB (for both day and night). Prime95, as far as I could see, don´t usually goes anywhere close to these values, though. I observed the memory usage for some time noting that, for this size of exponents, the allocation was 4921 MB for the first and second worker entering stage 2 and 2247 MB for the third. When the fourth joined, the first and second were restarted with 3304 and 3227 MB.These values were kept for the rest of the 4 runs The total mem used would amount to 12,216 MB, slightly over the allowed value, but the usage reported by Task Manager never went above ~9.6 GB. This is a recurrent behaviour, I have observed it more than once. Although the values might fluctuate somehow (for example, the first worker entering S2 may restart twice, from 4921 MB to 3227 MB then 2247 MB), the general pattern holds. But I have also observed Prime95 using 11.5GB total, for a brief period, with all workers in S2 That´s probably when there are several workers performing the modular inverse at the same time. So, all in all, I guess Prime95 is working as expected. I´ll leave as it is for a couple of days to see how it does, and if another crash happens I´ll reduce the memory setting to 10 GB to see if it helps. Unless, of course, you have some other suggestion or ask me to try something else. |
[QUOTE=LaurV;568544]How much are the temperatures of the toy? (that's the most important info, which I didn't see in the post). [/QUOTE]
You didn´t see it in the post for a good reason. Temps are stable at 60 - 62 celsius, under full load, which totally harmless. I didn´t even bother to mention that. [QUOTE=LaurV;568544]The machine is old, so it may need some maintenance, you know, removing the dust clogs from the fans, re-seating of the CPU (change/reapply the thermal paste), etc. We do this yearly, or even every 6 months or so. You know, my grandma was virgin for a very long time, but suddenly she wasn't. Luckily for me, otherwise I won't be anymore, and who would post stupid things on mersenneforum? Haha. [/QUOTE] The machine is two years old. I never saw the need to reseat the CPU and/or reapply new paste on a 2-year old machine. The heatsink is not clogged with dust either. Probably I´ll clean it this summer. Anyhow, the machine is certainly a lot younger than your grandma, so I reckon it´s still virgin... :smile: [QUOTE=LaurV;568544] If you do only ECM, it won't matter much anyhow. [/QUOTE] Yes, that´s the case, for the foreseeable future. |
I put this in worktodo.txt:
[CODE] [Worker #1] Pminus1=N/A,1,2,15510977,-1,1500000,30000000 Pminus1=N/A,1,2,15511381,-1,1500000 Pminus1=N/A,1,2,15511403,-1,1500000,30000000 [/CODE] Which resulted in this output: [CODE] Your choice: [Main thread Jan 6 20:13] Starting worker. [Work thread Jan 6 20:13] Worker starting [Work thread Jan 6 20:13] Setting affinity to run worker on CPU core #1 [Work thread Jan 6 20:13] [Work thread Jan 6 20:13] P-1 on M15510977 with B1=1500000, B2=30000000 [Work thread Jan 6 20:13] Setting affinity to run helper thread 1 on CPU core #2 [Work thread Jan 6 20:13] Setting affinity to run helper thread 2 on CPU core #3 [Work thread Jan 6 20:13] Setting affinity to run helper thread 3 on CPU core #4 [Work thread Jan 6 20:13] Using FMA3 FFT length 800K, Pass1=320, Pass2=2560, clm=4, 4 threads [Work thread Jan 6 20:13] Using 11057MB of memory. [Work thread Jan 6 20:14] Stage 2 init complete. 110047 transforms. Time: 60.167 sec. [Work thread Jan 6 20:14] M15510977 stage 2 is 43.88% complete. [Work thread Jan 6 20:18] M15510977 stage 2 is 65.04% complete. Time: 265.576 sec. [Work thread Jan 6 20:22] M15510977 stage 2 is 85.40% complete. Time: 255.297 sec. [Work thread Jan 6 20:26] M15510977 stage 2 complete. 1358614 transforms. Time: 715.411 sec. [Work thread Jan 6 20:26] Stage 2 GCD complete. Time: 2.544 sec. [Work thread Jan 6 20:26] M15510977 completed P-1, B1=1500000, B2=30000000, E=12, Wi8: 9088F10D [Comm thread Jan 6 20:26] Sending result to server: UID: Tha/Z-170, M15510977 completed P-1, B1=1500000, B2=30000000, E=12, Wi8: 9088F10D [Comm thread Jan 6 20:26] [Work thread Jan 6 20:26] [Work thread Jan 6 20:26] Using minimum bound #1 of 30 [Work thread Jan 6 20:26] P-1 on M1 with B1=30, B2=15511381 [Work thread Jan 6 20:26] Cannot initialize FFT code, errcode=1008 [Work thread Jan 6 20:26] Worker stopped. [Main thread Jan 6 20:26] Execution halted. [Main thread Jan 6 20:26] Choose Test/Continue to restart. [Comm thread Jan 6 20:26] PrimeNet success code with additional info: [Comm thread Jan 6 20:26] CPU credit is 2.2200 GHz-days. [Comm thread Jan 6 20:26] Done communicating with server. [/CODE] It also wiped out most of the worktodo.txt file! It put this in there: [CODE] Pminus1=N/A,1,2,1,-1,2,15511381,1500000 [/CODE] |
I put those 3 lines in my worktodo build 3
1 Attachment(s)
And saw this in Status.
Maybe it can't handle having no B2? |
1 Attachment(s)
I started a ECM range on F19 with mprime v.29.8. Restarted it on stage 1, with v30.4b5, 14GB of RAM assigned to each of the 2 workers, and got this message:
[code]ECM on F19: curve #1 with s=7741023751586926, B1=44000000, B2=[COLOR="Red"]TBD[/COLOR] ... ... [Worker #1 Jan 7 00:52] Stage 1 complete. 348387014 transforms, 1 modular inverses. Time: 0.088 sec. [Worker #1 Jan 7 00:52] [COLOR="red"]Optimal B2 is 189*B1[/COLOR] = 8316000000. [Worker #1 Jan 7 00:52] D: 6930, relative primes: 17543, stage 2 primes: 41752603, pair%=92.77 [/code] Now I am happily crunching on Stage2 :smile: BTW, switching from Stage1 to Stage2 of F19 I had theis strange behavior: |
Build 5 also suffers from Infinite loop bug. This is linux, btw.
The setup is: Memory = 57g Each of the 6 worker is restricted to 9.5g. mprime however uses 9966m actual per worker (instead of the 9728m allowed) . Somehow when all 6 workers entered stage 2 together, I got the infinite loop for one of the worker (it just loops printing "Available memory is xxxx"). Had to quit and change total memory to 9966*6= 59796m (without changing per-worker allocation). Now seems to be working fine. Let's see if this recurs. |
After a week running 30.4 b3 without issue it "disappeared" this morning.
I just upgraded to this b5. Keep you posted. |
[QUOTE=petrw1;568748]After a week running 30.4 b3 without issue it "disappeared" this morning.
I just upgraded to this b5. Keep you posted.[/QUOTE] On restart it backed up and redid some work and found the same factor for the same exponent LOL. Second was not needed of course. |
[QUOTE=petrw1;568748]After a week running 30.4 b3 without issue it "disappeared" this morning.
I just upgraded to this b5. Keep you posted.[/QUOTE] Welcome to the club. See posts #3 and 19 on this thread. |
This is a tricky one for you George. I am running build 30.3b2 but no reason why the same issue (won't call it a bug) doesn't exist in this version.
Kaspersky was bugging me so I said yes to some security fixes it wanted to do. I'm running Prime95 from the Program Files folder in Windows 7. Always have. I know it's frowned upon now but old habits die hard. So Prime95 stopped being able to write to the folder because Kaspersky had messed wth the ownership. I'm also running as admin so basically security nightmare. So far so good. But now when Prime95 runs the Jacobi benchmarks it is unable to write a checkpoint so forgets about progress and restarts from the last checkpoint written on disk. This seems undesirable in my opinion. If for whatever reason the disk becomes temporarily unavailable, running the Jacobi benchmarks can wipe all progress. |
[QUOTE=garo;568950] I'm also running as admin so basically security nightmare. So far so good. But now when Prime95 runs the Jacobi benchmarks it is unable to write a checkpoint so forgets about progress and restarts from the last checkpoint written on disk. This seems undesirable in my opinion. If for whatever reason the disk becomes temporarily unavailable, running the Jacobi benchmarks can wipe all progress.[/QUOTE]
This has nothing to do with Jacobi. Since Prime95 cannot write a save file to resume from Jacobi, it will also not be able to write to the results file, nor the spool file prior to sending results to PrimeNet, nor the worktodo file when getting new work. Why running as Administrator does not solve your problem? I have no idea. |
[QUOTE=garo;568950]...
Kaspersky was bugging me so I said yes to some security fixes it wanted to do. I'm running Prime95 from the Program Files folder in Windows 7. Always have. I know it's frowned upon now but old habits die hard. So Prime95 stopped being able to write to the folder because Kaspersky had messed wth the ownership. ...[/QUOTE] [QUOTE=Prime95;568956]This has nothing to do with Jacobi. Since Prime95 cannot write a save file to resume from Jacobi, it will also not be able to write to the results file, nor the spool file prior to sending results to PrimeNet, nor the worktodo file when getting new work. Why running as Administrator does not solve your problem? I have no idea.[/QUOTE]If the folder is owned by "NT Service/TrustedInstaller", the members of the Administrator group might not have access. Better install the program in "Program Data" or in a user folder if Kapersky makes a mess of the permissions. Jacob |
Thanks for confirming that George. This is exactly what I meant: [QUOTE]Since Prime95 cannot write a save file to resume from Jacobi,[/QUOTE]Resuming from Jacobi requires reading from a savefile.
@Jacob: The owner of that folder is Administrators but Kaspersky has basically stopped my user (who is an Administrator) from doing things that require admin privileges automatically. (I accepted that setting when it asked). This means a process I own couldn't write to the Prime95 folder automatically. I changed the owner of that folder to myself and it works fine now. But really I should probably use a different folder. :no: (Edit: Moved to Users/garo/Roaming Data) |
[QUOTE=Prime95;568530]I'm still working on this. A Ubuntu build with debugging on seems to work. A CentOS build without debugging (the way official versions are built) does not. [/QUOTE]
I have my laptop back and can now work though some of the bugs backlog. The good news is the CentOS/Ubuntu difference was a mirage -- simply a typo on my part. This nasty bug seems to be squashed. |
[QUOTE=tha;568588]I put this in worktodo.txt:
Pminus1=N/A,1,2,15511381,-1,1500000[/QUOTE] You triggered some really old code. It handles the old-format Pminus1 lines (circa 2002??). Ignoring the "N/A," if there are 4 commas or less the old syntax is assumed: Pminus1=exponent,B1,B2,plus1[,B2_start] I'll remove support for this ancient syntax. Edit: I'm removing the ancient ECM= syntax as well. |
People, just make a C:\Prime95 or D:\PrimeWork, or whatever you like. P95 won't look out of this folder, you can copy everything there and restart from there, delete the old one. It is much easier to find when you look for it, it is accessible by all users in case your wife, kid, cat, dog, gerbil, snake, login to your computer when you are not at home, and it doesn't miss with the system or system files.
|
[QUOTE=axn;568649]Build 5 also suffers from Infinite loop bug.
Somehow when all 6 workers entered stage 2 together, I got the infinite loop for one of the worker (it just loops printing "Available memory is xxxx")..[/QUOTE] I think I know what caused this. The P-1 stage 2 planner was told it could use X amount of memory, but it came up with a plan to use substantially more than X. The planner told the prime95 memory manager it was going to use this more than X value and the memory manager said "No, come up with a different plan". Infinite loop ensued. I've coded 3 fixes for this. 1) The P-1 and ECM stage 2 planner now figures in the amount of memory expected to be used by the prime pairing bit map -- which can be up to 250MB. I believe this was the root cause of creating plans that used too much memory. 2) The memory manager allowed over-allocating by 32MB. This has been raised to 64MB. 3) When told to replan, which should only happen when another worker changes its memory use, P-1 and ECM now come up with a new plan using 1% less memory. |
[QUOTE=petrw1;568748]After a week running 30.4 b3 without issue it "disappeared" this morning.[/QUOTE]
In re-reading this thread, I believe this is the only open issue. Unfortunately, I have no good ideas. I've started up a run with 4 ECM workers under the debugger hoping for a crash. I have one last bug to fix before releasing build 6. It is not related to P-1 or ECM. |
Is this a good time to ask about the issue that I raised last summer regarding the server not accepting new B1/B2 values if a factor has already been found and reported to the server?
Basically I want to be able to do P-1 work on exponents which have no previous P-1 work being done on them because they were already factored in the trial factoring stage. And then have the server storing the B1/B2 values. And of course find additional factors for that exponent. (see [URL="https://www.mersenneforum.org/showpost.php?p=483083&postcount=1452"]original request[/URL]) I have no idea if this is a solemn server issue or if requires any mprime and prime95 modifications. |
[QUOTE=tha;569198]Is this a good time to ask about the issue that I raised last summer regarding the server not accepting new B1/B2 values if a factor has already been found and reported to the server? ([URL="https://www.mersenneforum.org/showpost.php?p=483083&postcount=1452"]original request[/URL])
I have no idea if this is a solemn server issue or if requires any mprime and prime95 modifications.[/QUOTE]It should be a purely server-side issue. I'm not very familiar with the data tables used on primenet, but as I recall the table that stores P-1 bounds is only applicable to unfactored exponent. I have no idea what would be involved in extending those tables to store bounds for factored exponents. I have elsewhere received a similar request about adding a tool on mersenne.ca to both help find such factoring work and store results. Mersenne.ca does intrinsically store P-1 bounds no matter if the exponent is factored or not. But it would of course much better to have such data stored authoritatively on primenet. |
[QUOTE=tha;569198]Is this a good time to ask about the issue that I raised last summer regarding the server not accepting new B1/B2 values if a factor has already been found and reported to the server?
Basically I want to be able to do P-1 work on exponents which have no previous P-1 work being done on them because they were already factored in the trial factoring stage. And then have the server storing the B1/B2 values. And of course find additional factors for that exponent. (see [URL="https://www.mersenneforum.org/showpost.php?p=483083&postcount=1452"]original request[/URL]) I have no idea if this is a solemn server issue or if requires any mprime and prime95 modifications.[/QUOTE] What is supposed to happen is the text message is recorded in the exponent history. Mersenne.ca should pick this up. It did not happen in your case. This would be a server issue. |
[QUOTE=James Heinrich;569200] But it would of course much better to have such data stored authoritatively on primenet.[/QUOTE]
OK, so who would be the one(s) to go to? Last time I came to understand that this issue was not something trivial and required input from George. Is that (still) the case? Who would need to communicate with whom to make a start on this? |
[QUOTE=tha;569209]Last time I came to understand that this issue was not something trivial and required input from George. Is that (still) the case? Who would need to communicate with whom to make a start on this?[/QUOTE]Send an email to me and George with a sample result line (new P-1 effort with higher bounds on an already-factored exponent) and we'll look into why it's not behaving as it should.
|
The results.txt was included in Tha's description.
I just submitted the P-1 line via the web page and the exponent's history now shows the P-1 activity. So, it looks like the problem is limited to the automatic reporting of results. If possible, can you resubmit your P-1 results via the manual web page? |
Build 6 (see post #1 for links) is now available.
|
[QUOTE=Prime95;569237]Build 6 (see post #1 for links) is now available.[/QUOTE]You misnamed the Windows file, you called it [c]p95v306b6.win64.zip[/c] instead of [c]p95v304b6.win64.zip[/c]
|
[QUOTE=James Heinrich;569238]You misnamed the Windows file, you called it [c]p95v306b6.win64.zip[/c] instead of [c]p95v304b6.win64.zip[/c][/QUOTE]
Thanks, all fixed. The build process is not automated and prone to human error. |
[QUOTE=Prime95;569240]Thanks, all fixed. The build process is not automated and prone to human error.[/QUOTE]
Is it safe to update the executable in the middle of a run? |
[QUOTE=ET_;569267]Is it safe to update the executable in the middle of a run?[/QUOTE]
Depends on from which version you are upgrading and what type of work you are doing. Generally, yes. |
[QUOTE=Prime95;569224]
I just submitted the P-1 line via the web page and the exponent's history now shows the P-1 activity. So, it looks like the problem is limited to the automatic reporting of results. If possible, can you resubmit your P-1 results via the manual web page?[/QUOTE] How did you do that? I tried submitting the following again today through the manual results web page to no avail: [CODE] [Wed Jun 3 17:05:41 2020] P-1 found a factor in stage #2, B1=600000, B2=2400000, E=6. UID: Tha/Z-170, M5000081 has a factor: 898903979816332515777287 (P-1, B1=600000, B2=2400000, E=6) [Wed Jun 3 17:11:00 2020] P-1 found a factor in stage #2, B1=600000, B2=12000000, E=12. UID: Tha/Z-170, M5000081 has a factor: 898903979816332515777287 (P-1, B1=600000, B2=12000000, E=12) [Wed Jun 3 17:26:12 2020] P-1 found a factor in stage #2, B1=600000, B2=12000000, E=12. UID: Tha/Z-170, M5000087 has a factor: 66121150489 (P-1, B1=600000, B2=12000000, E=12) [Wed Jun 3 17:33:41 2020] P-1 found a factor in stage #2, B1=600000, B2=12000000, E=12. UID: Tha/Z-170, M5000111 has a factor: 10000223 (P-1, B1=600000, B2=12000000, E=12) [Wed Jun 3 17:41:13 2020] P-1 found a factor in stage #2, B1=600000, B2=12000000, E=12. UID: Tha/Z-170, M5000113 has a factor: 421679529743 (P-1, B1=600000, B2=12000000, E=12) [Wed Jun 3 17:48:57 2020] P-1 found a factor in stage #2, B1=600000, B2=12000000, E=12. UID: Tha/Z-170, M5000153 has a factor: 801278124548029343009 (P-1, B1=600000, B2=12000000, E=12) [Wed Jun 3 17:57:21 2020] P-1 found a factor in stage #2, B1=600000, B2=12000000, E=12. UID: Tha/Z-170, M5000161 has a factor: 321746416845124826763793108931856482497 (P-1, B1=600000, B2=12000000, E=12) [Wed Jun 3 18:04:55 2020] P-1 found a factor in stage #2, B1=600000, B2=12000000, E=12. UID: Tha/Z-170, M5000167 has a factor: 85845347138833 (P-1, B1=600000, B2=12000000, E=12) [Wed Jun 3 18:12:22 2020] P-1 found a factor in stage #2, B1=600000, B2=12000000, E=12. UID: Tha/Z-170, M5000197 has a factor: 8024361661463183185195903 (P-1, B1=600000, B2=12000000, E=12) [Wed Jun 3 18:19:48 2020] P-1 found a factor in stage #2, B1=600000, B2=12000000, E=12. UID: Tha/Z-170, M5000201 has a factor: 160006433 (P-1, B1=600000, B2=12000000, E=12) [Wed Jun 3 18:27:17 2020] UID: Tha/Z-170, M5000213 completed P-1, B1=600000, B2=12000000, E=12, Wh8: 81B183A6 [Wed Jun 3 18:34:45 2020] P-1 found a factor in stage #2, B1=600000, B2=12000000, E=12. UID: Tha/Z-170, M5000251 has a factor: 12716165173572083629852580988754282904745159025062875599 (P-1, B1=600000, B2=12000000, E=12) [Wed Jun 3 18:42:20 2020] P-1 found a factor in stage #2, B1=600000, B2=12000000, E=12. UID: Tha/Z-170, M5000257 has a factor: 135007849246784281 (P-1, B1=600000, B2=12000000, E=12) [Wed Jun 3 18:50:26 2020] P-1 found a factor in stage #2, B1=600000, B2=12000000, E=12. UID: Tha/Z-170, M5000263 has a factor: 1112931111836131843069343747412575527033 (P-1, B1=600000, B2=12000000, E=12) [Wed Jun 3 18:58:06 2020] P-1 found a factor in stage #2, B1=600000, B2=12000000, E=12. UID: Tha/Z-170, M5000299 has a factor: 5466489982287803835718093520778434569 (P-1, B1=600000, B2=12000000, E=12) [Wed Jun 3 19:05:37 2020] P-1 found a factor in stage #2, B1=600000, B2=12000000, E=12. UID: Tha/Z-170, M5000311 has a factor: 50003111 (P-1, B1=600000, B2=12000000, E=12) [Wed Jun 3 19:13:10 2020] P-1 found a factor in stage #2, B1=600000, B2=12000000, E=12. UID: Tha/Z-170, M5000339 has a factor: 8648356318807 (P-1, B1=600000, B2=12000000, E=12) [Wed Jun 3 19:20:47 2020] P-1 found a factor in stage #2, B1=600000, B2=12000000, E=12. UID: Tha/Z-170, M5000381 has a factor: 189654450569 (P-1, B1=600000, B2=12000000, E=12) [Wed Jun 3 19:28:32 2020] P-1 found a factor in stage #2, B1=600000, B2=12000000, E=12. UID: Tha/Z-170, M5000389 has a factor: 1444519814898833 (P-1, B1=600000, B2=12000000, E=12) [Wed Jun 3 19:36:02 2020] P-1 found a factor in stage #2, B1=600000, B2=12000000, E=12. UID: Tha/Z-170, M5000399 has a factor: 10000799 (P-1, B1=600000, B2=12000000, E=12) [Wed Jun 3 19:43:27 2020] P-1 found a factor in stage #2, B1=600000, B2=12000000, E=12. UID: Tha/Z-170, M5000423 has a factor: 1495626578426712834017461794151 (P-1, B1=600000, B2=12000000, E=12) [Wed Jun 3 19:50:54 2020] P-1 found a factor in stage #2, B1=600000, B2=12000000, E=12. UID: Tha/Z-170, M5000473 has a factor: 209330976360004991784025594343086488165867134495557474039114517517233285534935270447 (P-1, B1=600000, B2=12000000, E=12) [/CODE] |
[QUOTE=tha;569275]How did you do that? I tried submitting the following again today through the manual results web page to no avail[/QUOTE]Thank you for the example. I think I've spotted a problem in the code, we need to examine it more closely and devise a fix.
|
If I recall it correctly there used to be an option listed in undoc.txt about forcing mprime/prime95 to do a stage2 even if a factor is found in stage 1. I couldn't find anything about it in the current version. Did we ever have that option and if so, do we still have that option or can we have it?
|
Perhaps this one?
[code]You can skip the GCD in stage 1 of P-1 factoring with this prime.txt setting: Stage1GCD=0[/code] |
[QUOTE=ixfd64;569306]Perhaps this one?
[/QUOTE] Ah! |
Is stage 1 P-1 factoring now supposed to fit completely in the L3 cache? Is that where the speedup came from?
[CODE]top - 05:19:52 up 6:14, 1 user, load average: 63.25, 59.63, 50.47 Tasks: 588 total, 1 running, 587 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.0 us, 0.3 sy, 96.6 ni, 3.1 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st MiB Mem : 128925.9 total, 127437.0 free, 803.2 used, 685.7 buff/cache MiB Swap: 0.0 total, 0.0 free, 0.0 used. 127236.8 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 13527 james 30 10 4483612 134276 7880 S 1556 0.1 186:08.48 mprime 13680 james 30 10 4483616 134428 7988 S 1553 0.1 180:02.59 mprime 13834 james 30 10 4483480 133496 7496 S 1551 0.1 174:31.16 mprime 13377 james 30 10 4483480 134888 7636 S 1542 0.1 189:46.74 mprime [/CODE]The prime.log makes no reference to the new version yet. This is my 4 CPU [URL="https://www.amd.com/en/products/cpu/6272"]Opteron[/URL] system running 4 separate instances (because mprime is not NUMA aware). Having trouble verifying but I think the L3 cache on that chip is actually 2 8MB caches. Edit: Because I was only using half of my L3 cache, I doubled the number of workers per instance. Got some reassuring messages in prime.log: [CODE][Fri Jan 15 06:27:57 2021 - ver 30.4] Exchanging program options with server Getting assignment from server PrimeNet success code with additional info: Server assigned P-1 factoring work. Got assignment 6914F714740D2AF13BE05BCE07ABA42D: P-1 M102220457 Sending expected completion date for M102220457: Jan 21 2021[/CODE] Edit: or is the resource usage 135MB, not 135kB? |
[QUOTE=phillipsjk;569345]Is stage 1 P-1 factoring now supposed to fit completely in the L3 cache? Is that where the speedup came from?
[/QUOTE] I think I just got confused about kiB vs byte units. Disadvantage of only running the machine at night is that upgrades happen when I am tired. |
I just installed build 6. After a couple of P-1 jobs done I had to cut the internet connectiion to do some rewiring of the electric system in my house. Meanwhile mprime tried to connect to the server every 2 minutes. This while it is set to retry a connection every 70 minutes. I used option 15 to set it to 71 minutes. To no avail, it continued to retry a connection every 2 minutes until the electric system was re-enabled and the internet connection was restored.
|
[QUOTE=tha;569403]I just installed build 6. After a couple of P-1 jobs done I had to cut the internet connectiion to do some rewiring of the electric system in my house. Meanwhile mprime tried to connect to the server every 2 minutes. This while it is set to retry a connection every 70 minutes. I used option 15 to set it to 71 minutes. To no avail, it continued to retry a connection every 2 minutes until the electric system was re-enabled and the internet connection was restored.[/QUOTE]
Look in prime.txt. You will see two lines: [CODE]NetworkRetryTime=2 NetworkRetryTime2=70 [/CODE] I suppose you need to change the first one. |
[QUOTE=axn;569422]Look in prime.txt. You will see two lines:
[CODE]NetworkRetryTime=2 NetworkRetryTime2=70 [/CODE] I suppose you need to change the first one.[/QUOTE] Hmm. I must have missed the change in that functionality. Probably to be found somewhere in a file with changes from version to version. What is the ratio behind having a menu option that has no apparent effect even though suggesting so and a hidden feature that requires to delve into the details to do what the menu option suggest to do? |
I believe they are both used, but for different purposes. If there is no internet connectivity, the first parameter is used. If there is internet connectivity, but mersenne.org is down, the second parameter is used.
Or something like that. I don't remember exactly. Maybe George knows. Regardless, you can manually edit the entry and see if that takes care of things for the future. |
[QUOTE=axn;569451]I believe they are both used, but for different purposes. If there is no internet connectivity, the first parameter is used. If there is internet connectivity, but mersenne.org is down, the second parameter is used.
[/QUOTE] Ah, that would make sense. Something though that should be documented in the readme or undoc.txt file. |
[QUOTE=axn;569451]I believe they are both used, but for different purposes. If there is no internet connectivity, the first parameter is used. If there is internet connectivity, but mersenne.org is down, the second parameter is used.
Or something like that. I don't remember exactly. Maybe George knows. Regardless, you can manually edit the entry and see if that takes care of things for the future.[/QUOTE] It might be a good idea to rename the second parameter to [C]ServerRetryTime[/C] or something similar. George, any thoughts? |
Using build 6, I'm running ECM on cofactor work on the 8 cores of my AMD 1700X, and since yesterday, every time I start it, it quietly quits after a few minutes of running with no visible error message. It had been running fine for a while so it may be due to the specific exponents it's trying to work on, or maybe the combination of stages they're each on.
This was also occurring on build 5. The Windows event viewer does log it as an error with the following: [CODE]Faulting application name: prime95.exe, version: 30.4.1.0, time stamp: 0x5ff269ce Faulting module name: ntdll.dll, version: 10.0.19041.662, time stamp: 0x27bfa5f0 Exception code: 0xc0000374 Fault offset: 0x00000000000ff0f9 Faulting process ID: 0x4320 Faulting application start time: 0x01d6ecc8686d0967 Faulting application path: D:\Portable apps\Prime\prime95.exe Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll Report ID: a81e32ea-f964-4056-bbf0-7662f567fc9b Faulting package full name: Faulting package-relative application ID: [/CODE] |
[QUOTE=seatsea;569497]Using build 6, I'm running ECM on cofactor work on the 8 cores of my AMD 1700X, and since yesterday, every time I start it, it quietly quits after a few minutes of running with no visible error message[/QUOTE]
Interesting! Can you send me the worktodo.txt, prime.txt, local.txt and savefiles? |
I had previously done work on M36001457 with these settings: B1=800000, B2=16000000, E=12. The files of the work I do I keep in storage. I now added to worktodo a new assignment on this exponent with the same B1 value to see what B2 value it would choose and how much time it would use. (So to see how much time would be saved from using the previous done B2 value.)
To my surprise no line ended up in the screen about choosing a B2 value which turned out to be 80000000, exactly 100*B1. I then added a line to worktodo on doing P-1 on M36024379 on which no previous work had been done on my machine. To my surprise it chose a very different B2 value. I just wonder what causes this behaviour and if that is intended, Next I will try to do work on a similar exponent with work done before and force E=12 to match up with the previous work done [CODE] [Work thread Jan 17 21:22] [Work thread Jan 17 21:22] P-1 on M36001457 with B1=800000, B2=TBD [Comm thread Jan 17 21:22] PrimeNet success code with additional info: [Comm thread Jan 17 21:22] CPU credit is 4.2008 GHz-days. [Comm thread Jan 17 21:22] Done communicating with server. [Work thread Jan 17 21:22] Setting affinity to run helper thread 1 on CPU core #2 [Work thread Jan 17 21:22] Using FMA3 FFT length 1920K, Pass1=320, Pass2=6K, clm=2, 4 threads [Work thread Jan 17 21:22] Setting affinity to run helper thread 2 on CPU core #3 [Work thread Jan 17 21:22] Setting affinity to run helper thread 3 on CPU core #4 [Work thread Jan 17 21:22] D: 420, relative primes: 722, stage 2 primes: 3638252, pair%=85.35 [Work thread Jan 17 21:22] Using 11072MB of memory. [Work thread Jan 17 21:22] Stage 2 init complete. 7326 transforms. Time: 15.964 sec. [Work thread Jan 17 21:22] M36001457 stage 2 is 0.00% complete. [Work thread Jan 17 21:28] M36001457 stage 2 is 4.02% complete. Time: 370.062 sec. [Work thread Jan 17 21:34] M36001457 stage 2 is 8.07% complete. Time: 345.577 sec. [Work thread Jan 17 21:39] M36001457 stage 2 is 12.14% complete. Time: 317.657 sec. [Work thread Jan 17 21:45] M36001457 stage 2 is 16.23% complete. Time: 312.608 sec. [Work thread Jan 17 21:49] M36001457 stage 2 is 20.33% complete. Time: 287.018 sec. [Work thread Jan 17 21:55] M36001457 stage 2 is 24.45% complete. Time: 314.309 sec. [Work thread Jan 17 21:59] M36001457 stage 2 is 28.58% complete. Time: 281.240 sec. [Work thread Jan 17 22:04] M36001457 stage 2 is 32.73% complete. Time: 284.123 sec. [Work thread Jan 17 22:09] M36001457 stage 2 is 36.89% complete. Time: 280.684 sec. [Work thread Jan 17 22:13] M36001457 stage 2 is 41.07% complete. Time: 276.842 sec. [Work thread Jan 17 22:18] M36001457 stage 2 is 45.25% complete. Time: 276.602 sec. [Work thread Jan 17 22:23] M36001457 stage 2 is 49.44% complete. Time: 276.825 sec. [Work thread Jan 17 22:27] M36001457 stage 2 is 53.64% complete. Time: 276.762 sec. [Work thread Jan 17 22:32] M36001457 stage 2 is 57.85% complete. Time: 276.737 sec. [Work thread Jan 17 22:36] M36001457 stage 2 is 62.08% complete. Time: 276.761 sec. [Work thread Jan 17 22:41] M36001457 stage 2 is 66.32% complete. Time: 277.043 sec. [Work thread Jan 17 22:46] M36001457 stage 2 is 70.55% complete. Time: 276.781 sec. [Work thread Jan 17 22:50] M36001457 stage 2 is 74.80% complete. Time: 276.830 sec. [Work thread Jan 17 22:55] M36001457 stage 2 is 79.05% complete. Time: 310.911 sec. [Comm thread Jan 17 22:57] Updating computer information on the server [Comm thread Jan 17 22:57] Done communicating with server. [Work thread Jan 17 23:02] M36001457 stage 2 is 83.31% complete. Time: 412.623 sec. [Work thread Jan 17 23:09] M36001457 stage 2 is 87.57% complete. Time: 371.106 sec. [Work thread Jan 17 23:14] M36001457 stage 2 is 91.84% complete. Time: 309.076 sec. [Work thread Jan 17 23:19] M36001457 stage 2 is 96.11% complete. Time: 306.492 sec. [Work thread Jan 17 23:24] M36001457 stage 2 complete. 4780896 transforms. Time: 7306.344 sec. [Work thread Jan 17 23:24] Stage 2 GCD complete. Time: 7.897 sec. [Work thread Jan 17 23:24] M36001457 completed P-1, B1=800000, B2=80000000, Wi8: A7BE996F [Comm thread Jan 17 23:24] Sending result to server: UID: Tha/Z-170, M36001457 completed P-1, B1=800000, B2=80000000, Wi8: A7BE996F ... ^C[Main thread Jan 17 23:37] Stopping all worker windows. [Work thread Jan 17 23:37] Worker stopped. [Main thread Jan 17 23:37] Execution halted. [Main thread Jan 17 23:37] Choose Test/Continue to restart. 5 ... Your choice: Starting worker. [Work thread Jan 17 23:38] Worker starting [Work thread Jan 17 23:38] Setting affinity to run worker on CPU core #1 [Work thread Jan 17 23:38] [Work thread Jan 17 23:38] P-1 on M36024379 with B1=800000, B2=TBD [Work thread Jan 17 23:38] Setting affinity to run helper thread 1 on CPU core #2 [Work thread Jan 17 23:38] Using FMA3 FFT length 1920K, Pass1=320, Pass2=6K, clm=2, 4 threads [Work thread Jan 17 23:38] Setting affinity to run helper thread 3 on CPU core #4 [Work thread Jan 17 23:38] Setting affinity to run helper thread 2 on CPU core #3 [Work thread Jan 17 23:42] M36024379 stage 1 is 8.65% complete. Time: 225.016 sec. [Work thread Jan 17 23:46] M36024379 stage 1 is 17.32% complete. Time: 232.572 sec. [Work thread Jan 17 23:49] M36024379 stage 1 is 25.98% complete. Time: 206.288 sec. [Work thread Jan 17 23:53] M36024379 stage 1 is 34.64% complete. Time: 209.199 sec. [Work thread Jan 17 23:56] M36024379 stage 1 is 43.31% complete. Time: 206.483 sec. [Work thread Jan 18 00:00] M36024379 stage 1 is 51.97% complete. Time: 208.038 sec. [Work thread Jan 18 00:03] M36024379 stage 1 is 60.63% complete. Time: 208.205 sec. [Work thread Jan 18 00:07] M36024379 stage 1 is 69.30% complete. Time: 212.216 sec. [Work thread Jan 18 00:10] M36024379 stage 1 is 77.96% complete. Time: 211.049 sec. [Work thread Jan 18 00:13] M36024379 stage 1 is 86.62% complete. Time: 188.892 sec. [Work thread Jan 18 00:16] M36024379 stage 1 is 95.29% complete. Time: 185.072 sec. [Work thread Jan 18 00:18] M36024379 stage 1 complete. 2308722 transforms. Time: 2393.415 sec. [Work thread Jan 18 00:18] With trial factoring done to 2^73, optimal B2 is 56*B1 = 44800000. [Work thread Jan 18 00:18] If no prior P-1, chance of a new factor is 5.19% [Work thread Jan 18 00:18] D: 462, relative primes: 722, stage 2 primes: 2642907, pair%=88.37 [Work thread Jan 18 00:18] Using 11065MB of memory. [Work thread Jan 18 00:18] Stage 2 init complete. 6552 transforms. Time: 12.568 sec. [Work thread Jan 18 00:23] M36024379 stage 2 is 6.50% complete. Time: 277.216 sec. [Work thread Jan 18 00:27] M36024379 stage 2 is 12.84% complete. Time: 277.227 sec. [Work thread Jan 18 00:32] M36024379 stage 2 is 18.94% complete. Time: 277.211 sec. [Work thread Jan 18 00:37] M36024379 stage 2 is 25.00% complete. Time: 277.229 sec. [Work thread Jan 18 00:41] M36024379 stage 2 is 30.96% complete. Time: 277.348 sec. [Work thread Jan 18 00:46] M36024379 stage 2 is 36.93% complete. Time: 277.073 sec. [Work thread Jan 18 00:51] M36024379 stage 2 is 42.94% complete. Time: 277.102 sec. [Work thread Jan 18 00:55] M36024379 stage 2 is 49.01% complete. Time: 277.137 sec. [Work thread Jan 18 01:00] M36024379 stage 2 is 55.10% complete. Time: 277.083 sec. [Work thread Jan 18 01:04] M36024379 stage 2 is 61.20% complete. Time: 277.657 sec. [Work thread Jan 18 01:09] M36024379 stage 2 is 67.32% complete. Time: 277.730 sec. [Work thread Jan 18 01:14] M36024379 stage 2 is 73.46% complete. Time: 277.135 sec. [Work thread Jan 18 01:18] M36024379 stage 2 is 79.62% complete. Time: 277.102 sec. [Work thread Jan 18 01:23] M36024379 stage 2 is 85.77% complete. Time: 277.094 sec. [Work thread Jan 18 01:28] M36024379 stage 2 is 91.94% complete. Time: 277.182 sec. [Work thread Jan 18 01:32] M36024379 stage 2 is 98.12% complete. Time: 277.142 sec. [Work thread Jan 18 01:34] M36024379 stage 2 complete. 3260556 transforms. Time: 4519.832 sec. [Work thread Jan 18 01:34] Stage 2 GCD complete. Time: 7.101 sec. [Work thread Jan 18 01:34] M36024379 completed P-1, B1=800000, B2=44800000, Wi8: A14FBC47 [Comm thread Jan 18 01:34] Sending result to server: UID: Tha/Z-170, M36024379 completed P-1, B1=800000, B2=44800000, Wi8: A14FBC47 [Comm thread Jan 18 01:34] [/CODE] |
[QUOTE=seatsea;569497]Using build 6, I'm running ECM on cofactor work on the 8 cores of my AMD 1700X, and since yesterday, every time I start it, it quietly quits after a few minutes of running with no visible error message.[/QUOTE]
Found a memory corruption problem when limited stage 2 memory resulted in selecting N^2 pooling instead of 3-mult pooling. Will be fixed in build 7. |
Build 7 now available, see first post in this thread for links. The only fix is the memory corruption bug. If you've experienced crashes with earlier builds, please upgrade so that we can see if this fix addresses the crashes you were experiencing.
|
Hmm, no idea what to do with this. No idea about the stability of this machine either.
[CODE] [Work thread Jan 21 14:28] M22100047 stage 1 is 73.45% complete. Time: 52.978 sec. [Work thread Jan 21 14:29] M22100047 stage 1 is 74.02% complete. Time: 52.880 sec. [Work thread Jan 21 14:29] M22100047 stage 1 is 74.60% complete. Time: 53.050 sec. [Work thread Jan 21 14:30] M22100047 stage 1 is 75.18% complete. Time: 52.868 sec. [Work thread Jan 21 14:31] M22100047 stage 1 is 75.76% complete. Time: 52.936 sec. [Main thread Jan 21 14:32] In write_gwnum, unexpected gwtogiant failure, retcode -1 [Work thread Jan 21 14:32] M22100047 stage 1 is 76.33% complete. Time: 52.828 sec. [Work thread Jan 21 14:33] M22100047 stage 1 is 76.91% complete. Time: 52.891 sec. [Work thread Jan 21 14:34] M22100047 stage 1 is 77.49% complete. Time: 52.884 sec. [Work thread Jan 21 14:35] M22100047 stage 1 is 78.06% complete. Time: 52.716 sec. [/CODE] Getting even weirder: After having interrupted mprime (^C) and restarting mprime, it continued from a a backup file I did not expect to be used as first choice. I am lettting this machine run to see if the error is reproducible. [CODE] Accept the answers above? (Y): Main Menu 1. Test/Primenet 2. Test/Workers 3. Test/Status 4. Test/Continue 5. Test/Exit 6. Advanced/Test 7. Advanced/Time 8. Advanced/P-1 9. Advanced/ECM 10. Advanced/Manual Communication 11. Advanced/Unreserve Exponent 12. Advanced/Quit Gimps 13. Options/CPU 14. Options/Resource Limits 15. Options/Preferences 16. Options/Torture Test 17. Options/Benchmark 18. Help/About 19. Help/About PrimeNet Server Your choice: 4 Main Menu 1. Test/Primenet 2. Test/Workers 3. Test/Status 4. Test/Continue 5. Test/Exit 6. Advanced/Test 7. Advanced/Time 8. Advanced/P-1 9. Advanced/ECM 10. Advanced/Manual Communication 11. Advanced/Unreserve Exponent [Main thread Jan 21 13:02] Starting worker. 12. Advanced/Quit Gimps 13. Options/CPU 14. Options/Resource Limits 15. Options/Preferences 16. Options/Torture Test 17. Options/Benchmark 18. Help/About 19. Help/About PrimeNet Server Your choice: [Work thread Jan 21 13:02] Worker starting [Work thread Jan 21 13:02] Setting affinity to run worker on CPU core #1 [Work thread Jan 21 13:02] [Work thread Jan 21 13:02] P-1 on M22100047 with B1=1200000, B2=TBD [Work thread Jan 21 13:02] Setting affinity to run helper thread 1 on CPU core #2 [Work thread Jan 21 13:02] Using FFT length 1152K, Pass1=256, Pass2=4608, clm=4, 4 threads [Work thread Jan 21 13:02] Setting affinity to run helper thread 3 on CPU core #4 [Work thread Jan 21 13:02] Setting affinity to run helper thread 2 on CPU core #3 [Work thread Jan 21 13:02] M22100047 stage 1 is 19.18% complete. [Work thread Jan 21 13:02] M22100047 stage 1 is 19.75% complete. Time: 51.076 sec. [Work thread Jan 21 13:03] M22100047 stage 1 is 20.33% complete. Time: 54.607 sec. [Work thread Jan 21 13:04] M22100047 stage 1 is 20.91% complete. Time: 61.303 sec. [Work thread Jan 21 13:05] M22100047 stage 1 is 21.48% complete. Time: 56.263 sec. [Work thread Jan 21 13:06] M22100047 stage 1 is 22.06% complete. Time: 55.852 sec. [Work thread Jan 21 13:07] M22100047 stage 1 is 22.64% complete. Time: 56.152 sec. [Work thread Jan 21 13:08] M22100047 stage 1 is 23.22% complete. Time: 55.523 sec. [Work thread Jan 21 13:09] M22100047 stage 1 is 23.79% complete. Time: 55.678 sec. [Work thread Jan 21 13:10] M22100047 stage 1 is 24.37% complete. Time: 55.528 sec. [Work thread Jan 21 13:11] M22100047 stage 1 is 24.95% complete. Time: 55.625 sec. [Work thread Jan 21 13:12] M22100047 stage 1 is 25.53% complete. Time: 55.589 sec. [Work thread Jan 21 13:13] M22100047 stage 1 is 26.10% complete. Time: 55.603 sec. [Work thread Jan 21 13:14] M22100047 stage 1 is 26.68% complete. Time: 55.459 sec. [Work thread Jan 21 13:15] M22100047 stage 1 is 27.26% complete. Time: 55.465 sec. [Work thread Jan 21 13:15] M22100047 stage 1 is 27.84% complete. Time: 55.682 sec. [Work thread Jan 21 13:16] M22100047 stage 1 is 28.41% complete. Time: 55.654 sec. [Work thread Jan 21 13:17] M22100047 stage 1 is 28.99% complete. Time: 55.660 sec. [Work thread Jan 21 13:18] M22100047 stage 1 is 29.57% complete. Time: 55.613 sec. [Work thread Jan 21 13:19] M22100047 stage 1 is 30.14% complete. Time: 55.623 sec. [Work thread Jan 21 13:20] M22100047 stage 1 is 30.72% complete. Time: 55.612 sec. [Work thread Jan 21 13:21] M22100047 stage 1 is 31.30% complete. Time: 55.483 sec. [Work thread Jan 21 13:22] M22100047 stage 1 is 31.88% complete. Time: 55.143 sec. [Work thread Jan 21 13:23] M22100047 stage 1 is 32.45% complete. Time: 55.294 sec. [Work thread Jan 21 13:24] M22100047 stage 1 is 33.03% complete. Time: 55.456 sec. [Work thread Jan 21 13:25] M22100047 stage 1 is 33.61% complete. Time: 55.331 sec. [Work thread Jan 21 13:26] M22100047 stage 1 is 34.19% complete. Time: 55.268 sec. [Work thread Jan 21 13:27] M22100047 stage 1 is 34.76% complete. Time: 55.366 sec. [Work thread Jan 21 13:27] M22100047 stage 1 is 35.34% complete. Time: 55.097 sec. [Work thread Jan 21 13:28] M22100047 stage 1 is 35.92% complete. Time: 55.266 sec. [Work thread Jan 21 13:29] M22100047 stage 1 is 36.50% complete. Time: 55.375 sec. [Work thread Jan 21 13:30] M22100047 stage 1 is 37.07% complete. Time: 55.404 sec. [Work thread Jan 21 13:31] M22100047 stage 1 is 37.65% complete. Time: 55.216 sec. [Work thread Jan 21 13:32] M22100047 stage 1 is 38.23% complete. Time: 55.326 sec. [Work thread Jan 21 13:33] M22100047 stage 1 is 38.81% complete. Time: 55.459 sec. [Work thread Jan 21 13:34] M22100047 stage 1 is 39.38% complete. Time: 55.444 sec. [Work thread Jan 21 13:35] M22100047 stage 1 is 39.96% complete. Time: 55.532 sec. [Work thread Jan 21 13:36] M22100047 stage 1 is 40.54% complete. Time: 55.517 sec. [Work thread Jan 21 13:37] M22100047 stage 1 is 41.11% complete. Time: 55.601 sec. [Work thread Jan 21 13:38] M22100047 stage 1 is 41.69% complete. Time: 55.697 sec. [Work thread Jan 21 13:39] M22100047 stage 1 is 42.27% complete. Time: 55.633 sec. [Work thread Jan 21 13:40] M22100047 stage 1 is 42.85% complete. Time: 55.710 sec. [Work thread Jan 21 13:40] M22100047 stage 1 is 43.42% complete. Time: 55.665 sec. [Work thread Jan 21 13:41] M22100047 stage 1 is 44.00% complete. Time: 55.661 sec. [Work thread Jan 21 13:42] M22100047 stage 1 is 44.58% complete. Time: 55.641 sec. [Work thread Jan 21 13:43] M22100047 stage 1 is 45.16% complete. Time: 55.659 sec. [Work thread Jan 21 13:44] M22100047 stage 1 is 45.73% complete. Time: 55.610 sec. [Work thread Jan 21 13:45] M22100047 stage 1 is 46.31% complete. Time: 55.562 sec. [Work thread Jan 21 13:46] M22100047 stage 1 is 46.89% complete. Time: 55.586 sec. [Work thread Jan 21 13:47] M22100047 stage 1 is 47.47% complete. Time: 55.514 sec. [Work thread Jan 21 13:48] M22100047 stage 1 is 48.04% complete. Time: 55.460 sec. [Work thread Jan 21 13:49] M22100047 stage 1 is 48.62% complete. Time: 55.514 sec. [Work thread Jan 21 13:50] M22100047 stage 1 is 49.20% complete. Time: 55.599 sec. [Work thread Jan 21 13:51] M22100047 stage 1 is 49.77% complete. Time: 55.516 sec. [Work thread Jan 21 13:52] M22100047 stage 1 is 50.35% complete. Time: 55.474 sec. [Work thread Jan 21 13:52] M22100047 stage 1 is 50.93% complete. Time: 55.408 sec. [Work thread Jan 21 13:53] M22100047 stage 1 is 51.51% complete. Time: 55.382 sec. [Work thread Jan 21 13:54] M22100047 stage 1 is 52.08% complete. Time: 55.295 sec. [Work thread Jan 21 13:55] M22100047 stage 1 is 52.66% complete. Time: 55.286 sec. [Work thread Jan 21 13:56] M22100047 stage 1 is 53.24% complete. Time: 55.356 sec. [Work thread Jan 21 13:57] M22100047 stage 1 is 53.82% complete. Time: 55.589 sec. [Work thread Jan 21 13:58] M22100047 stage 1 is 54.39% complete. Time: 55.567 sec. [Work thread Jan 21 13:59] M22100047 stage 1 is 54.97% complete. Time: 55.311 sec. [Work thread Jan 21 14:00] M22100047 stage 1 is 55.55% complete. Time: 55.221 sec. [Work thread Jan 21 14:01] M22100047 stage 1 is 56.13% complete. Time: 55.333 sec. [Work thread Jan 21 14:02] M22100047 stage 1 is 56.70% complete. Time: 55.431 sec. [Work thread Jan 21 14:03] M22100047 stage 1 is 57.28% complete. Time: 55.218 sec. [Work thread Jan 21 14:04] M22100047 stage 1 is 57.86% complete. Time: 55.364 sec. [Work thread Jan 21 14:04] M22100047 stage 1 is 58.43% complete. Time: 55.205 sec. [Work thread Jan 21 14:05] M22100047 stage 1 is 59.01% complete. Time: 55.127 sec. [Work thread Jan 21 14:06] M22100047 stage 1 is 59.59% complete. Time: 55.160 sec. [Work thread Jan 21 14:07] M22100047 stage 1 is 60.17% complete. Time: 55.390 sec. [Work thread Jan 21 14:08] M22100047 stage 1 is 60.74% complete. Time: 55.472 sec. [Work thread Jan 21 14:09] M22100047 stage 1 is 61.32% complete. Time: 55.423 sec. [Work thread Jan 21 14:10] M22100047 stage 1 is 61.90% complete. Time: 55.288 sec. [Work thread Jan 21 14:11] M22100047 stage 1 is 62.48% complete. Time: 54.623 sec. [Work thread Jan 21 14:12] M22100047 stage 1 is 63.05% complete. Time: 52.968 sec. [Work thread Jan 21 14:13] M22100047 stage 1 is 63.63% complete. Time: 52.919 sec. [Work thread Jan 21 14:14] M22100047 stage 1 is 64.21% complete. Time: 52.865 sec. [Work thread Jan 21 14:14] M22100047 stage 1 is 64.79% complete. Time: 52.858 sec. [Work thread Jan 21 14:15] M22100047 stage 1 is 65.36% complete. Time: 52.848 sec. [Work thread Jan 21 14:16] M22100047 stage 1 is 65.94% complete. Time: 52.877 sec. [Work thread Jan 21 14:17] M22100047 stage 1 is 66.52% complete. Time: 52.946 sec. [Work thread Jan 21 14:18] M22100047 stage 1 is 67.10% complete. Time: 52.814 sec. [Work thread Jan 21 14:19] M22100047 stage 1 is 67.67% complete. Time: 52.894 sec. [Work thread Jan 21 14:20] M22100047 stage 1 is 68.25% complete. Time: 52.965 sec. [Work thread Jan 21 14:21] M22100047 stage 1 is 68.83% complete. Time: 52.799 sec. [Work thread Jan 21 14:21] M22100047 stage 1 is 69.40% complete. Time: 52.674 sec. [Work thread Jan 21 14:22] M22100047 stage 1 is 69.98% complete. Time: 52.849 sec. [Work thread Jan 21 14:23] M22100047 stage 1 is 70.56% complete. Time: 52.797 sec. [Work thread Jan 21 14:24] M22100047 stage 1 is 71.14% complete. Time: 52.841 sec. [Work thread Jan 21 14:25] M22100047 stage 1 is 71.71% complete. Time: 52.817 sec. [Work thread Jan 21 14:26] M22100047 stage 1 is 72.29% complete. Time: 52.910 sec. [Work thread Jan 21 14:27] M22100047 stage 1 is 72.87% complete. Time: 52.929 sec. [Work thread Jan 21 14:28] M22100047 stage 1 is 73.45% complete. Time: 52.978 sec. [Work thread Jan 21 14:29] M22100047 stage 1 is 74.02% complete. Time: 52.880 sec. [Work thread Jan 21 14:29] M22100047 stage 1 is 74.60% complete. Time: 53.050 sec. [Work thread Jan 21 14:30] M22100047 stage 1 is 75.18% complete. Time: 52.868 sec. [Work thread Jan 21 14:31] M22100047 stage 1 is 75.76% complete. Time: 52.936 sec. [Main thread Jan 21 14:32] In write_gwnum, unexpected gwtogiant failure, retcode -1 [Work thread Jan 21 14:32] M22100047 stage 1 is 76.33% complete. Time: 52.828 sec. [Work thread Jan 21 14:33] M22100047 stage 1 is 76.91% complete. Time: 52.891 sec. [Work thread Jan 21 14:34] M22100047 stage 1 is 77.49% complete. Time: 52.884 sec. [Work thread Jan 21 14:35] M22100047 stage 1 is 78.06% complete. Time: 52.716 sec. [Work thread Jan 21 14:36] M22100047 stage 1 is 78.64% complete. Time: 52.590 sec. [Work thread Jan 21 14:36] M22100047 stage 1 is 79.22% complete. Time: 52.851 sec. [Work thread Jan 21 14:37] M22100047 stage 1 is 79.80% complete. Time: 52.837 sec. [Work thread Jan 21 14:38] M22100047 stage 1 is 80.37% complete. Time: 52.709 sec. [Work thread Jan 21 14:39] M22100047 stage 1 is 80.95% complete. Time: 52.756 sec. [Work thread Jan 21 14:40] M22100047 stage 1 is 81.53% complete. Time: 52.742 sec. [Work thread Jan 21 14:41] M22100047 stage 1 is 82.11% complete. Time: 52.755 sec. [Work thread Jan 21 14:42] M22100047 stage 1 is 82.68% complete. Time: 52.703 sec. [Work thread Jan 21 14:43] M22100047 stage 1 is 83.26% complete. Time: 52.687 sec. [Work thread Jan 21 14:43] M22100047 stage 1 is 83.84% complete. Time: 52.679 sec. [Work thread Jan 21 14:44] M22100047 stage 1 is 84.42% complete. Time: 52.769 sec. [Work thread Jan 21 14:45] M22100047 stage 1 is 84.99% complete. Time: 52.736 sec. [Work thread Jan 21 14:46] M22100047 stage 1 is 85.57% complete. Time: 52.642 sec. [Work thread Jan 21 14:47] M22100047 stage 1 is 86.15% complete. Time: 52.606 sec. [Work thread Jan 21 14:48] M22100047 stage 1 is 86.73% complete. Time: 52.650 sec. [Work thread Jan 21 14:49] M22100047 stage 1 is 87.30% complete. Time: 52.762 sec. [Work thread Jan 21 14:50] M22100047 stage 1 is 87.88% complete. Time: 52.893 sec. [Work thread Jan 21 14:51] M22100047 stage 1 is 88.46% complete. Time: 52.827 sec. [Work thread Jan 21 14:51] M22100047 stage 1 is 89.03% complete. Time: 52.874 sec. [Work thread Jan 21 14:52] M22100047 stage 1 is 89.61% complete. Time: 52.732 sec. [Work thread Jan 21 14:53] M22100047 stage 1 is 90.19% complete. Time: 52.829 sec. [Work thread Jan 21 14:54] M22100047 stage 1 is 90.77% complete. Time: 52.743 sec. [Work thread Jan 21 14:55] M22100047 stage 1 is 91.34% complete. Time: 52.736 sec. [Work thread Jan 21 14:56] M22100047 stage 1 is 91.92% complete. Time: 52.645 sec. [Work thread Jan 21 14:57] M22100047 stage 1 is 92.50% complete. Time: 53.867 sec. [Work thread Jan 21 14:58] M22100047 stage 1 is 93.08% complete. Time: 54.018 sec. [Work thread Jan 21 14:59] M22100047 stage 1 is 93.65% complete. Time: 57.697 sec. [Work thread Jan 21 14:59] M22100047 stage 1 is 94.23% complete. Time: 53.998 sec. [Work thread Jan 21 15:00] M22100047 stage 1 is 94.81% complete. Time: 53.155 sec. [Work thread Jan 21 15:01] M22100047 stage 1 is 95.39% complete. Time: 54.124 sec. ^C[Main thread Jan 21 15:02] Stopping all worker windows. [Main thread Jan 21 15:02] In write_gwnum, unexpected gwtogiant failure, retcode -1 [Work thread Jan 21 15:02] Worker stopped. [Main thread Jan 21 15:02] Execution halted. [Main thread Jan 21 15:02] Choose Test/Continue to restart. 5 henk@henk-MS-7588:~/mersenne$ ls -l total 45468 lrwxrwxrwx 1 henk henk 16 jan 21 12:13 libgmp.so -> libgmp.so.10.4.0 lrwxrwxrwx 1 henk henk 16 jan 21 12:13 libgmp.so.10 -> libgmp.so.10.4.0 -rwxr-xr-x 1 henk henk 644436 jan 18 23:54 libgmp.so.10.3.2 -rwxr-xr-x 1 henk henk 702428 jan 18 23:54 libgmp.so.10.4.0 -rw-r--r-- 1 henk henk 2110 jan 18 23:54 license.txt -rw-rw-r-- 1 henk henk 293 jan 21 13:02 local.txt -rw-rw-r-- 1 henk henk 2762584 jan 21 14:02 mM100047 -rw-rw-r-- 1 henk henk 2762584 jan 21 13:32 mM100047.bu -rw-rw-r-- 1 henk henk 2762584 jan 21 13:01 mM100047.bu2 -rwxrwxr-x 1 henk henk 36734440 jan 18 23:54 mprime -rw-rw-r-- 1 henk henk 328 jan 21 12:28 prime.txt -rw-r--r-- 1 henk henk 34812 jan 18 23:54 readme.txt -rw-rw-r-- 1 henk henk 168 jan 21 15:02 results.txt -rw-r--r-- 1 henk henk 9134 jan 18 23:54 stress.txt -rw-r--r-- 1 henk henk 43108 jan 18 23:54 undoc.txt -rw-r--r-- 1 henk henk 58120 jan 18 23:54 whatsnew.txt -rw-rw-r-- 1 henk henk 176 jan 21 12:21 worktodo.txt henk@henk-MS-7588:~/mersenne$ ./mprime -m [Main thread Jan 21 15:05] Mersenne number primality test program version 30.4 [Main thread Jan 21 15:05] Optimizing for CPU architecture: Core i3/i5/i7, L2 cache size: 4x256 KB, L3 cache size: 8 MB Main Menu 1. Test/Primenet 2. Test/Workers 3. Test/Status 4. Test/Continue 5. Test/Exit 6. Advanced/Test 7. Advanced/Time 8. Advanced/P-1 9. Advanced/ECM 10. Advanced/Manual Communication 11. Advanced/Unreserve Exponent 12. Advanced/Quit Gimps 13. Options/CPU 14. Options/Resource Limits 15. Options/Preferences 16. Options/Torture Test 17. Options/Benchmark 18. Help/About 19. Help/About PrimeNet Server Your choice: 4 Main Menu 1. Test/Primenet 2. Test/Workers 3. Test/Status 4. Test/Continue 5. Test/Exit 6. Advanced/Test 7. Advanced/Time 8. Advanced/P-1 9. Advanced/ECM 10. Advanced/Manual Communication 11. Advanced/Unreserve Exponent 12. Advanced/Quit Gimps 13. Options/CPU 14. Options/Resource Limits 15. Options/Preferences 16. Options/Torture Test 17. Options/Benchmark 18. Help/About 19. Help/About PrimeNet Server Your choice: [Main thread Jan 21 15:05] Starting worker. [Work thread Jan 21 15:05] Worker starting [Work thread Jan 21 15:05] Setting affinity to run worker on CPU core #1 [Work thread Jan 21 15:05] [Work thread Jan 21 15:05] P-1 on M22100047 with B1=1200000, B2=TBD [Work thread Jan 21 15:05] Setting affinity to run helper thread 1 on CPU core #2 [Work thread Jan 21 15:05] Setting affinity to run helper thread 2 on CPU core #3 [Work thread Jan 21 15:05] Setting affinity to run helper thread 3 on CPU core #4 [Work thread Jan 21 15:05] Using FFT length 1152K, Pass1=256, Pass2=4608, clm=4, 4 threads [Work thread Jan 21 15:05] M22100047 stage 1 is 56.61% complete. [Work thread Jan 21 15:05] M22100047 stage 1 is 57.19% complete. Time: 48.506 sec. [/CODE] By the way, why does the menu get rewritten to screen after option 4 is chosen? |
[QUOTE]
Getting even weirder: After having interrupted mprime (^C) and restarting mprime, it continued from a a backup file I did not expect to be used as first choice. I am lettting this machine run to see if the error is reproducible. [/QUOTE] Second run had no errors reporting |
error -1 is bad FFT data, which raises a few questions. Why is this only detected during write save file process? Should getting this error during a write save file continue on with P-1 or should it restart from last save file?
|
Build 8 is now ready.
No bug fixes. There are 2 new modular inverse pooling algorithms. Previously there were two algorithms for pooling N values: 1) 3*N multiplies, N extra temporaries 2) N^2 multiplies, 1 extra temporary The two new methods: 3) 3.44*N multiplies, N/3 extra temporaries 4) 3.57*N multiplies, N/7 extra temporaries This gives prime95 more options in picking an ECM stage 2 plan especially in low memory situations. Expect a small speed increase in some situations. |
I got a crash with build 7 doing ECM work on Linux:
[code] show_signal_msg: 17 callbacks suppressed mprime[18320]: segfault at 7fd563f78000 ip 00000000004511b2 sp 00007ff0cc98f860 error 6 in mprime[400000+2190000] [/code]When it happened, Worker #6 was restarting with new memory settings (138MB instead of the ~10GB it was using before): [code] [Worker #6 Jan 24 08:28] Using FMA3 FFT length 168K, Pass1=896, Pass2=192, clm=2 [Worker #6 Jan 24 08:28] 0.759 bits-per-word below FFT limit (more than 0.5 allows extra optimizations) [Worker #6 Jan 24 08:28] ECM on M3287587: curve #1 with s=4277217782961047, B1=50000, B2=TBD ... [Worker #6 Jan 24 09:05] Stage 1 complete. 1271230 transforms, 1 modular inverses. Time: 2209.706 sec. [Worker #6 Jan 24 09:05] Available memory is 70122MB. [Worker #6 Jan 24 09:05] Optimal B2 is 135*B1 = 6750000. [Worker #6 Jan 24 09:05] D: 2310, relative primes: 2202, stage 2 primes: 455574, pair%=89.19 [Worker #6 Jan 24 09:05] Stage 2 uses 9994MB of memory, 2 FFTs per prime pair, 3-mult modinv pooling, pool size 2698. [Worker #6 Jan 24 09:06] Stage 2 init complete. 62496 transforms, 1 modular inverses. Time: 113.305 sec. ... [Worker #30 Jan 24 09:23] Stage 1 complete. 1271230 transforms, 1 modular inverses. Time: 1094.399 sec. [Worker #30 Jan 24 09:23] Available memory is 7753MB. [Worker #30 Jan 24 09:23] Optimal B2 is 135*B1 = 6750000. [Worker #30 Jan 24 09:23] D: 2310, relative primes: 2202, stage 2 primes: 455574, pair%=89.19 [Worker #6 Jan 24 09:23] Restarting worker with new memory settings. [Worker #6 Jan 24 09:23] [Worker #6 Jan 24 09:23] Using FMA3 FFT length 168K, Pass1=896, Pass2=192, clm=2 [Worker #6 Jan 24 09:23] 0.759 bits-per-word below FFT limit (more than 0.5 allows extra optimizations) [Worker #6 Jan 24 09:23] ECM on M3287587: curve #1 with s=4277217782961047, B1=50000, B2=6750000 [Worker #6 Jan 24 09:23] Available memory is 7999MB. [Worker #6 Jan 24 09:23] D: 420, relative primes: 48, stage 2 primes: 40421, pair%=182.86 [Worker #6 Jan 24 09:23] Stage 2 uses 138MB of memory, 4 FFTs per prime pair, 3-mult modinv pooling. [Worker #30 Jan 24 09:23] Stage 2 uses 6770MB of memory, 2 FFTs per prime pair, 3-mult modinv pooling, pool size 2698. [/code]The Out Of Memory issues I experienced before are gone, though! |
P
The auto calculation of the P-1 bound does not work for numbers with known factors. Example line in worktodo: [CODE]Pminus1=N/A,1,2,3333313,-1,500000,0,68,220665927262967[/CODE]Example Output (note that it is using the old B2=100*B1):
[CODE] [Main thread Jan 25 20:37] Mersenne number primality test program version 30.4 [Main thread Jan 25 20:37] Optimizing for CPU architecture: Core i3/i5/i7, L2 cache size: 2x256 KB, L3 cache size: 3 MB [Main thread Jan 25 20:37] Starting worker. [Work thread Jan 25 20:37] Worker starting [Work thread Jan 25 20:37] Setting affinity to run worker on CPU core #1 [Work thread Jan 25 20:37] [Work thread Jan 25 20:37] P-1 on M3333313 with B1=500000, B2=50000000 [Work thread Jan 25 20:37] Chance of finding a factor is an estimated -nan% [Work thread Jan 25 20:37] Setting affinity to run helper thread 1 on CPU core #2 [Work thread Jan 25 20:37] Using FMA3 FFT length 168K, Pass1=896, Pass2=192, clm=2, 2 threads [Work thread Jan 25 20:38] M3333313 stage 1 is 13.85% complete. Time: 65.602 sec. [Work thread Jan 25 20:39] M3333313 stage 1 is 27.71% complete. Time: 65.743 sec. [Work thread Jan 25 20:40] M3333313 stage 1 is 41.57% complete. Time: 65.683 sec. [/CODE] But maybe that is intentional, I don't known if one can calculate the probability for a second factor... |
[QUOTE=gLauss;570091][CODE]Pminus1=N/A,1,2,3333313,-1,500000,0,68,220665927262967[/CODE][/QUOTE]
AFAIK, the known factors should be formatted as ,"xxx": [CODE]Pminus1=N/A,1,2,3333313,-1,500000,0,68,"220665927262967"[/CODE] This should work properly. |
[QUOTE=nordi;570074]I got a crash with build 7 doing ECM work on Linux:
[/quote] I have not been able to replicate the problem. [quote]D: 420, relative primes: 48, stage 2 primes: 40421, pair%=182.86[/QUOTE] I did fix a bug that caused the pairing % to exceed 100. |
I use Prime95 for years on my personal, and CRUS search. I like all extra checks ,but can I disable generating proof file, since it will use disk space for nothing,and I dont need to upload proff file to no one.
Thanks |
[QUOTE=pepi37;570301]I use Prime95 for years on my personal, and CRUS search. I like all extra checks ,but can I disable generating proof file, since it will use disk space for nothing,and I dont need to upload proff file to no one.
Thanks[/QUOTE] Try setting the disk space prime95 is allowed to use to zero. |
I think it might be better to change prime pairing format from [c]pair%=xx.xx[/c] to [c]pair: xx.xx%[/c] so that it's consistent with the rest of the output line.
|
There seems to be a problem with fetching work in some cases. I have one of my cores set to get P-1 work, while the others do PRP. When one or more of the PRP tests also want to do a P-1 test before starting, only one stage 2 can run at a time. If the P-1 core is blocked from doing stage 2 it will do stage 1 work on the exponents it has, but if it finishes all of them and still cannot start a stage 2 because of another core, it will stop and wait instead of getting some new work to do.
|
[QUOTE=1997rj7;570585]it will stop and wait instead of getting some new work to do.[/QUOTE]You can increase [c]DaysOfWork[/c] in prime.txt (or the equivalent GUI setting).
But looking at the broader picture, it might not be a bad idea in a situation like this, if Prime95 can't find anything else to do while waiting for RAM availability, it could start working on the PRP, on the 95% probability that the P-1 test will not find a factor, rather than leaving idle cycles. |
Are the ECM B1 and B2 bounds not allowed to be changed from their nominal settings?
I ´ve been using Build 8, and didn´t have a single problem so far. Today I fetched some manual ECM assignments in the 500k range, and the worktodo lines came with the expected values of 250000 / 25000000 for B1 and B2. I changed them to 500000 and 50000000 and restarted Prime95.The program rejected those lines, giving out the message:"Illegal line in worktodo.txt file: ECM2=blablabla". The lines were not deleted from worktodo.txt, though. Is this the expected behaviour? I /think/ in previous versions one were able to change the bounds at will. |
[QUOTE=James Heinrich;570587]But looking at the broader picture, it might not be a bad idea in a situation like this, if Prime95 can't find anything else to do while waiting for RAM availability, it could start working on the PRP, on the 95% probability that the P-1 test will not find a factor, rather than leaving idle cycles.[/QUOTE]
PRP (and LL) are already coded to do this. I'll see if I can replicate the problem. |
[QUOTE=lycorn;570601]Is this the expected behaviour? I /think/ in previous versions one were able to change the bounds at will.[/QUOTE]
This is not the expected behavior. |
Stable mprime version for the next GPU72 Colab build?
Hey.
So, I've had a few requests to upgrade the mprime build sent out in the Payload. Since several of us are now being given at least a few hours of compute each day, I'd like to program a day for me to do this (along with some other change requests). George, your counsel? It will be solely doing P-1'ing; and yes, I know about the non-backward compatibility for stage 2... :smile: I'm modeling next weekend. |
[QUOTE=chalsall;570858]
So, I've had a few requests to upgrade the mprime build sent out in the Payload. Since several of us are now being given at least a few hours of compute each day, I'd like to program a day for me to do this (along with some other change requests). George, your counsel? [/QUOTE] 30.4 seems stable enough to make the transition. The improved P-1 bounds is worth the effort. |
I had this last on 30.3
[CODE] [Worker #4 Feb 6 18:35] M104099027 stage 2 is 47.60% complete. Time: 936.607 sec. [Worker #4 Feb 6 18:48] Worker stopped. [/CODE] Then after updating to 30.4 build 8 [CODE] [Worker #4 Feb 6 19:50] Waiting 15 seconds to stagger worker starts. [Worker #4 Feb 6 19:50] Worker starting [Worker #4 Feb 6 19:50] Setting affinity to run worker on CPU core #4 [Worker #4 Feb 6 19:50] Optimal P-1 factoring of M104099027 using up to 24576MB of memory. [Worker #4 Feb 6 19:50] Assuming no factors below 2^76 and 2 primality tests saved if a factor is found. [Worker #4 Feb 6 19:50] Optimal bounds are B1=834000, B2=41687000 [Worker #4 Feb 6 19:50] Chance of finding a factor is an estimated 4.43% [Worker #4 Feb 6 19:50] [Worker #4 Feb 6 19:50] Using FMA3 FFT length 5600K, Pass1=448, Pass2=12800, clm=4 [Worker #4 Feb 6 19:50] Cannot continue stage 2 from old P-1 save file. Restarting stage 2 from the beginning. [Worker #4 Feb 6 19:50] M104099027 stage 1 is 0.00% complete. [Worker #4 Feb 6 21:31] Waiting 15 seconds to stagger worker starts. [Worker #4 Feb 6 21:32] Worker starting [Worker #4 Feb 6 21:32] Setting affinity to run worker on CPU core #4 [Worker #4 Feb 6 21:32] Optimal P-1 factoring of M104099027 using up to 24576MB of memory. [Worker #4 Feb 6 21:32] Assuming no factors below 2^76 and 2 primality tests saved if a factor is found. [Worker #4 Feb 6 21:32] Optimal bounds are B1=834000, B2=41687000 [Worker #4 Feb 6 21:32] Chance of finding a factor is an estimated 4.43% [Worker #4 Feb 6 21:32] [Worker #4 Feb 6 21:32] Using FMA3 FFT length 5600K, Pass1=448, Pass2=12800, clm=4 [Worker #4 Feb 6 21:32] Cannot continue stage 2 from old P-1 save file. Restarting stage 2 from the beginning. [Worker #4 Feb 6 21:32] M104099027 stage 1 is 0.00% complete. [Worker #4 Feb 6 21:41] M104099027 stage 1 is 92.24% complete. Time: 547.831 sec. [Worker #4 Feb 6 21:43] Worker stopped. [Worker #4 Feb 6 21:45] Waiting 15 seconds to stagger worker starts. [Worker #4 Feb 6 21:45] Worker starting [Worker #4 Feb 6 21:45] Setting affinity to run worker on CPU core #4 [Worker #4 Feb 6 21:45] Optimal P-1 factoring of M104099027 using up to 24576MB of memory. [Worker #4 Feb 6 21:45] Assuming no factors below 2^76 and 2 primality tests saved if a factor is found. [Worker #4 Feb 6 21:45] Optimal bounds are B1=834000, B2=41687000 [Worker #4 Feb 6 21:45] Chance of finding a factor is an estimated 4.43% [Worker #4 Feb 6 21:45] [Worker #4 Feb 6 21:45] Using FMA3 FFT length 5600K, Pass1=448, Pass2=12800, clm=4 [Worker #4 Feb 6 21:45] M104099027 stage 1 is 92.38% complete. [Worker #4 Feb 6 21:54] M104099027 stage 1 is 92.93% complete. Time: 539.559 sec. [Worker #4 Feb 6 21:56] Worker stopped. [/CODE] Is this normal? It says stage 2 has to be restarted, but then stage 1 is at 0%, then next time I start Stage one jumps to 92%. |
[QUOTE=ZFR;571036]Is this normal? It says stage 2 has to be restarted, but then stage 1 is at 0%, then next time I start Stage one jumps to 92%.[/QUOTE]That seems about right. v30.4 has new optimizations that allow it to select higher bounds for P-1. So it selected a higher B1 and a higher B2 than before. The partially-completed stage2 has to be thrown out because of the new starting point (B1), but stage1 can be continued to the new higher B1 from the point it previously stopped, so your entire stage1 was useful and now it's doing 8% more, and will redo stage2 entirely.
The 0.00% is perhaps confusing, but I think just a display artifact. I would presume that it output that when it restarted prior to validating the savefile as valid for resuming stage1. |
[QUOTE=James Heinrich;571042]That seems about right. [/QUOTE]
Ah. Thanks for explaining. The 0% threw me off. Those new bounds are nice. B2 almost doubled, and chance of finding a factor increased by 30%. |
I have another question. On 30.4 I get this on resume.
[CODE] [Worker #4 Feb 7 07:42] Stage 2 init complete. 5489 transforms. Time: 198.902 sec. [Worker #4 Feb 7 07:42] M104099027 stage 2 is 15.94% complete. [/CODE] It took just over 3 minutes for Stage 2 to resume. In 30.3 I used to get this every time I resume [CODE] [Worker #4 Feb 6 16:41] Using 22337MB of memory. Processing 480 relative primes (0 of 480 already processed). [Worker #4 Feb 6 17:12] M104099027 stage 2 is 43.43% complete. [/CODE] Taking roughly 30 minutes, every time I restart mprime. Is the "stage 2 init" same as "Processing relative primes" from the previous version. If so, did its time drop from 30 mins to 3 mins? |
[QUOTE=ZFR;571062]On 30.4 I get ... just over 3 minutes for Stage 2 to resume.
In 30.3 I used to get ... roughly 30 minutes, every time I restart mprime.[/quote] [QUOTE=ZFR;571062]Is the "stage 2 init" same as "Processing relative primes" from the previous version. If so, did its time drop from 30 mins to 3 mins? [/QUOTE]Yes. Your numbers are proportionately the same as my testing, it used to take me 10 mins to resume stage2 and now it takes 1. The stage2 implementation is quite [url=https://www.mersenneforum.org/showpost.php?p=567795&postcount=297]different[/url] from earlier versions, one side effect of which is that resuming stage2 is now about 10x faster than before. As described by George:[QUOTE=Prime95;567707]Relative primes are no longer processed in passes. They are all done at once as prime95 steps from B1 to B2 in steps of size D.[/QUOTE] |
[QUOTE=James Heinrich;571081]Yes. Your numbers are proportionately the same as my testing, it used to take me 10 mins to resume stage2 and now it takes 1. The stage2 implementation is quite [URL="https://www.mersenneforum.org/showpost.php?p=567795&postcount=297"]different[/URL] from earlier versions, one side effect of which is that resuming stage2 is now about 10x faster than before. [/QUOTE]
That's amazing. Those 30 mins on every resume were a huge time hog in my case, since I had to stop/resume Stage 2 fairly often during the day when I needed the memory for other programs. If we take that saved time into consideration, and the increased probabilities from higher bounds, this new version is about 60% more effiecient for me. I love it. |
The new stage 2 uses E=2 by default (i.e. only prime pairing, no Brent-Suyama extension). If the old stage 2 was using E=12 it will take 6 times longer to initialize compared to E=2.
Apart from that, I don't know why it'd be faster by 10x, especially since the new version typically uses more temporaries. |
I am having a reproducible issue with mprime 30.4 build 7.
The issue: At start, F20 declares B1=44000000 and B2=TBD As soon as I complete (100%) stage 1 of curve 1 (of 5) of F20, mprime aborts and exits. It looks like 14000MB are not enough for the calculated stage2 / B2 value, but instead of rolling back to a smaller bound, the program stops. The other worker is running PRP-DC-CF (double check on composite PRP), and certifications from time to time. I have plenty of disk space. Before trying to increase the memory for the ECM-F worker, I wanted to know if this issue could hide a bug... My rig: Intel 9800x with 32GB of RAM DDR4 quad-channel. My worktodo: [code] PRPDC=[stuff deleted],1,2,10182587,-1,99,0,3,5,"59140465297,36146723563243273297" PRPDC=[stuff deleted],1,2,10183231,-1,99,0,3,5,"1900508377009657" PRPDC=[stuff deleted],1,2,10184123,-1,99,0,3,5,"515631552344276287" PRPDC=[stuff deleted],1,2,10184491,-1,99,0,3,5,"36740546801323961" PRPDC=[stuff deleted],1,2,10185011,-1,99,0,3,5,"20370023,16621937953" PRPDC=[stuff deleted],1,2,10185521,-1,99,0,3,5,"561099980849,559876498184068369" PRPDC=[stuff deleted],1,2,10185991,-1,99,0,3,5,"5622667033" PRPDC=[stuff deleted],1,2,10186381,-1,99,0,3,5,"2424358679,317868117499487,4533577375432697" PRPDC=[stuff deleted],1,2,10187239,-1,99,0,3,5,"101872391,156801609855427079" PRPDC=[stuff deleted],1,2,10187923,-1,99,0,3,5,"4801303223903,54845732759627098727" PRPDC=[stuff deleted],1,2,10188359,-1,99,0,3,5,"1711644313" PRPDC=[stuff deleted],1,2,10189841,-1,99,0,3,5,"9863766089,11983253017" PRPDC=[stuff deleted],1,2,10190603,-1,99,0,3,5,"1811073965161" PRPDC=[stuff deleted],1,2,10190941,-1,99,0,3,5,"8138139153661057" PRPDC=[stuff deleted],1,2,10192277,-1,99,0,3,5,"1610379767" [Worker #2] ECM2=N/A,1,2,1048576,1,44000000,4400000000,5 ECM2=[stuff deleted],1,2,16777216,1,3000000,300000000,5 ECM2=N/A,1,2,1048576,1,44000000,4400000000,5 [/code] My Prime.txt: [code] V24OptionsConverted=1 V30OptionsConverted=1 WGUID_version=2 StressTester=0 UsePrimenet=1 DialUp=0 V5UserID=ET_ OutputIterations=100000 ResultsFileIterations=999999999 DiskWriteTime=30 NetworkRetryTime=2 NetworkRetryTime2=70 DaysOfWork=7 DaysBetweenCheckins=1 NumBackupFiles=3 SilentVictory=1 Priority=1 RunOnBattery=1 PRPGerbiczCompareIntervalAdj=1 [PrimeNet] Debug=0 ProxyHost= UploadRateLimit=0.25 UploadStartTime=00:00 UploadEndTime=24:00 DownloadDailyLimit=40 [Worker #1] WorkPreference=161 [Worker #2] WorkPreference=6 [/code] My local.txt: [code] OldCpuSpeed=3800 NewCpuSpeedCount=0 NewCpuSpeed=0 RollingAverage=1000 RollingAverageIsFromV27=1 WorkerThreads=2 ComputerGUID= ComputerID=9800 WorkerDiskSpace=6 ProofResiduesDir= ProofArchiveDir= Memory=14000 during 7:30-23:30 else 14000 MaxEmergencyMemory=1024 CertDailyCPULimit=15 CertWork=1 Pid=[...] SrvrUID=[...] SrvrComputerName=[...] SrvrPO2=1 SrvrPO3=7 SrvrPO4=14000 SrvrPO5=14000 SrvrPO6=450 SrvrPO7=1410 SrvrPO8=1 SrvrPO9=2 SrvrP00=8 LastEndDatesSent=1612645886 CertDailyRemainingLastUpdate=1612645886 CertDailyMBRemaining=40 CertDailyCPURemaining=15 RollingHash=934404953 RollingStartTime=0 RollingCompleteTime=415141 [Worker #1] SrvrPO1=161 CoresPerTest=3 [Worker #2] SrvrPO1=6 CoresPerTest=4 [/code] |
[QUOTE=ET_;571098]I am having a reproducible issue with mprime 30.4 build 7.
The issue: At start, F20 declares B1=44000000 and B2=TBD As soon as I complete (100%) stage 1 of curve 1 (of 5) of F20, mprime aborts and exits.[/QUOTE] Good find. Fixed in build 9, which is now available. |
| All times are UTC. The time now is 04:22. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2023, Jelsoft Enterprises Ltd.