[QUOTE=Prime95;571111]Good find. Fixed in build 9, which is now available.[/QUOTE]

Thank you George :smile:

(Re an F20 issue:)[QUOTE=Prime95;571111]Good find. Fixed in build 9, which is now available.[/QUOTE]Does the prime95 v30.4 b9/b8 differential only affect Fermats? What if anything in the b9 update relates to Mersennes?

Note, in prime95 v30.4b8, it's possible to enter in Options, Preferences, Days of work to queue up, 0.5 or presumably other decimal values. It quietly truncates that 0.5 to 0 days when OK is clicked, and no work is obtained for the workers after that. Other fields may have a similar behavior; I did not test for that much.
A quick try in v30.3b6 shows all preferences fields will allow decimal values to be entered. This allows nonsensical input such as 3.1 backup files.
For short assignments such as P-1 factoring on fast systems it could be useful to limit the number queued up by accepting and applying less than a whole day. There's nothing on the child window to advise users to enter integers or that real inputs will be truncated to integer.

I am still using build 6.

A few times since I installed 30.4 the process got killed, but very infrequent. Restarting mprime than solves the problem.

I now have reached a point where mprime gets killed every time it is restarted.

I have left terminal open so I could run some tests if desired.

Should I just install build 9 or run some kind of test to see what causes this crashing?

[CODE]

[Work thread Feb 8 20:19]
[Work thread Feb 8 20:19] P-1 on M15435689 with B1=1200000, B2=TBD
[Work thread Feb 8 20:19] Setting affinity to run helper thread 1 on CPU core #2
[Work thread Feb 8 20:19] Using FMA3 FFT length 800K, Pass1=320, Pass2=2560, clm=4, 4 threads
[Work thread Feb 8 20:19] Setting affinity to run helper thread 2 on CPU core #3
[Work thread Feb 8 20:19] Setting affinity to run helper thread 3 on CPU core #4
[Comm thread Feb 8 20:19] PrimeNet success code with additional info:
[Comm thread Feb 8 20:19] CPU credit is 4.2008 GHz-days.
[Comm thread Feb 8 20:19] Done communicating with server.
[Work thread Feb 8 20:31] M15435689 stage 1 is 57.73% complete. Time: 768.708 sec.
[Work thread Feb 8 20:42] M15435689 stage 1 complete. 3464242 transforms. Time: 1396.240 sec.
[Work thread Feb 8 20:42] With trial factoring done to 2^69, optimal B2 is 71*B1 = 85200000.
[Work thread Feb 8 20:42] If no prior P-1, chance of a new factor is 7.73%
[Work thread Feb 8 20:42] D: 840, relative primes: 1713, stage 2 primes: 4861699, pair%=92.99
[Work thread Feb 8 20:42] Using 11073MB of memory.
[Work thread Feb 8 20:42] Stage 2 init complete. 16975 transforms. Time: 14.521 sec.
Killed
henk@Z170:~/mersenne$ ./mprime -m
[Main thread Feb 8 21:01] Mersenne number primality test program version 30.4
[Main thread Feb 8 21:01] 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 thread Feb 8 21:01] Starting worker.
[Work thread Feb 8 21:01] Worker starting
[Work thread Feb 8 21:01] Setting affinity to run worker on CPU core #1
[Work thread Feb 8 21:01]
[Work thread Feb 8 21:01] P-1 on M15435689 with B1=1200000, B2=TBD
[Work thread Feb 8 21:01] Setting affinity to run helper thread 1 on CPU core #2
[Work thread Feb 8 21:01] Setting affinity to run helper thread 3 on CPU core #4
[Work thread Feb 8 21:01] Using FMA3 FFT length 800K, Pass1=320, Pass2=2560, clm=4, 4 threads
[Work thread Feb 8 21:01] Setting affinity to run helper thread 2 on CPU core #3
[Work thread Feb 8 21:01] Resuming P-1 in stage 2 with B2=85200000
[Work thread Feb 8 21:01] Using 11073MB of memory.
Killed
henk@Z170:~/mersenne$ ./mprime -m
[Main thread Feb 8 21:02] Mersenne number primality test program version 30.4
[Main thread Feb 8 21:02] 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


Starting worker.
[Work thread Feb 8 21:02] Worker starting
[Work thread Feb 8 21:02] Setting affinity to run worker on CPU core #1
[Work thread Feb 8 21:02]
[Work thread Feb 8 21:02] P-1 on M15435689 with B1=1200000, B2=TBD
[Work thread Feb 8 21:02] Setting affinity to run helper thread 1 on CPU core #2
[Work thread Feb 8 21:02] Setting affinity to run helper thread 2 on CPU core #3
[Work thread Feb 8 21:02] Setting affinity to run helper thread 3 on CPU core #4
[Work thread Feb 8 21:02] Using FMA3 FFT length 800K, Pass1=320, Pass2=2560, clm=4, 4 threads
[Work thread Feb 8 21:02] Resuming P-1 in stage 2 with B2=85200000
[Work thread Feb 8 21:02] Using 11073MB of memory.
Killed
henk@Z170:~/mersenne$ ./mprime -m
[Main thread Feb 8 21:03] Mersenne number primality test program version 30.4
[Main thread Feb 8 21:03] 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


[Work thread Feb 8 21:03] Worker starting
[Work thread Feb 8 21:03] Setting affinity to run worker on CPU core #1
[Work thread Feb 8 21:03]
[Work thread Feb 8 21:03] P-1 on M15435689 with B1=1200000, B2=TBD
[Work thread Feb 8 21:03] Setting affinity to run helper thread 1 on CPU core #2
[Work thread Feb 8 21:03] Using FMA3 FFT length 800K, Pass1=320, Pass2=2560, clm=4, 4 threads
[Work thread Feb 8 21:03] Setting affinity to run helper thread 2 on CPU core #3
[Work thread Feb 8 21:03] Setting affinity to run helper thread 3 on CPU core #4
[Work thread Feb 8 21:03] Resuming P-1 in stage 2 with B2=85200000
[Work thread Feb 8 21:03] Using 11073MB of memory.
Killed
henk@Z170:~/mersenne$

[/CODE]

I'm not sure how much memory you have installed in that machine, but it looks to me like you should try lowering the amount of memory that P-1 testing is allowed to use.

OTOH, post #97 indicates the problem you are seeing might be fixed in build 9, so if I were you I would just go ahead update and worry about it only if it isn't fixed.

[QUOTE=kriesel;571154](Re an F20 issue:)Does the prime95 v30.4 b9/b8 differential only affect Fermats? What if anything in the b9 update relates to Mersennes?.[/QUOTE]

It affects Fermats and Mersennes, P-1 and ECM.

[QUOTE=tha;571172].
I now have reached a point where mprime gets killed every time it is restarted.

Should I just install build 9 or run some kind of test to see what causes this crashing?[/QUOTE]

Try build 9. If that fails, send me the save file, worktodo.txt, prime.txt, and local.txt.

[QUOTE=Prime95;571179]
Try build 9. [/QUOTE]

Worked!

In mprime -m if the menu is displayed and an option is chosen the menu will again be displayed first which does not add any value and only clutters things. Can the redisplay of the menu be removed?

Maybe an error?
 

I accidentally duplicated the same P-1 test line in my worktodo.txt file twice. It ran the first test and found a factor! But then it ran the second test (starting in the second stage) and failed to find a factor. Ran using mprime v30.4b8. My expectation is that it should find the same factor again, right? Thank you!!!

Exponent: [M]102597787[/M]

[CODE][Wed Feb 10 22:14:47 2021]
{"status":"F", "exponent":102597787, "worktype":"P-1", "factors":["1023696064449201832067818657"], "b1":1200000, "b2":67200000, "fft-length":5898240, "security-code":"5A5F339B", "program":{"name":"Prime95", "version":"30.4", "build":8, "port":8}, "timestamp":"2021-02-11 03:14:47", "user":"XXXXX"}

[Thu Feb 11 07:45:49 2021]
{"status":"NF", "exponent":102597787, "worktype":"P-1", "b1":1200000, "b2":120000000, "fft-length":5898240, "security-code":"5975DD9B", "program":{"name":"Prime95", "version":"30.4", "build":8, "port":8}, "timestamp":"2021-02-11 12:45:49", "user":"XXXXX"}
[/CODE]

[CODE][Wed Feb 10 17:14:19 2021]
M102597787 stage 1 is 57.73% complete.
[Wed Feb 10 19:45:56 2021]
M102597787 stage 2 is 41.43% complete.
[Wed Feb 10 21:27:04 2021]
M102597787 stage 2 is 82.68% complete.
[Wed Feb 10 22:14:47 2021]
P-1 found a factor in stage #2, B1=1200000, B2=67200000.
UID: XXXXXX, M102597787 has a factor: 1023696064449201832067818657 (P-1, B1=1200000, B2=67200000)

< snip >

[Thu Feb 11 06:08:11 2021]
M102597787 stage 2 is 51.34% complete.
[Thu Feb 11 07:45:49 2021]
UID: XXXXXX, M102597787 completed P-1, B1=1200000, B2=120000000, Wi8: 5975DD9B
[/CODE]

Dropbox link for backup files:
[url]https://www.dropbox.com/sh/4iabn36d88zj9mm/AADhDrXXMg_5ybEg5SZWD-Esa?dl=0[/url]

[QUOTE=Runtime Error;571431]I accidentally duplicated the same P-1 test line in my worktodo.txt file twice. It ran the first test and found a factor! My expectation is that it should find the same factor again, right? [/QUOTE]

Maybe not. I believe when the first P-1 finished it created a save file indicating that P-1 had been run to B1=1.2M, B2=67.2M. When the second P-1 line was processed prime95 took B2 from 67.2M to 120M and thus did not find a factor.

Doing that with gpuOwl will drop the second line (so, do no test, found no factor, save the time). That's because if a factor is found, the tool checks the rest of the worktodo and discards other tests for the same exponent which are scheduled further, to avoid doing the long PRP (if both P-1 and PRP scheduled) for an exponent which already has a factor. Doesn't P95 behave the same?

[QUOTE=LaurV;572298]Doing that with gpuOwl will drop the second line (so, do no test, found no factor, save the time). That's because if a factor is found, the tool checks the rest of the worktodo and discards other tests for the same exponent which are scheduled further, to avoid doing the long PRP (if both P-1 and PRP scheduled) for an exponent which already has a factor. Doesn't P95 behave the same?[/QUOTE]

Prime95 does not do that.

[QUOTE=Prime95;572296]Maybe not. I believe when the first P-1 finished it created a save file indicating that P-1 had been run to B1=1.2M, B2=67.2M. When the second P-1 line was processed prime95 took B2 from 67.2M to 120M and thus did not find a factor.[/QUOTE]

Interesting, thank you!

Build 30.5 build 1 is available. It fixes the PRP problem described here: [url]https://www.mersenneforum.org/showthread.php?p=573197#post573197[/url]

[QUOTE=Prime95;573558]Build 30.5 build 1 is available. It fixes the PRP problem described here: [url]https://www.mersenneforum.org/showthread.php?p=573197#post573197[/url][/QUOTE]

There is no prime95.exe in the windows folders.

Oops. Fixed.

OK.
Restarted with 30.5.1 a session initiated with 30.4.9, and had the following message:

[code]
Worker #1 Mar 13 13:46] Worker starting
[Worker #1 Mar 13 13:46] Setting affinity to run worker on CPU core #1
[Worker #2 Mar 13 13:46] Waiting 5 seconds to stagger worker starts.
[Worker #1 Mar 13 13:46] Setting affinity to run helper thread 1 on CPU core #1
[Worker #1 Mar 13 13:46] Setting affinity to run helper thread 4 on CPU core #3
[Worker #1 Mar 13 13:46] Setting affinity to run helper thread 5 on CPU core #3
[Worker #1 Mar 13 13:46] Setting affinity to run helper thread 6 on CPU core #4
[Worker #1 Mar 13 13:46] Resuming trial factoring of M216166681 to 2^74
[Worker #1 Mar 13 13:46] Setting affinity to run helper thread 3 on CPU core #2
[Worker #1 Mar 13 13:46] Trial factoring M216166681 to 2^74 is 24.56% complete.
[Worker #1 Mar 13 13:46] Setting affinity to run helper thread 2 on CPU core #2
[Worker #1 Mar 13 13:46] Setting affinity to run helper thread 7 on CPU core #4
[Worker #2 Mar 13 13:46] Worker starting
[Worker #2 Mar 13 13:46] Setting affinity to run worker on CPU core #5
[Worker #2 Mar 13 13:46] Setting affinity to run helper thread 1 on CPU core #6
[Worker #2 Mar 13 13:46] Setting affinity to run helper thread 3 on CPU core #8
[/code]

while with version 30.4.9 I had the following allorment for the CPUs:

[code]
[Worker #1 Mar 13 13:47] Worker starting
[Worker #1 Mar 13 13:47] Setting affinity to run worker on CPU core #1
[Worker #2 Mar 13 13:47] Waiting 5 seconds to stagger worker starts.
[Worker #1 Mar 13 13:47] Setting affinity to run helper thread 1 on CPU core #1
[Worker #1 Mar 13 13:47] Setting affinity to run helper thread 5 on CPU core #3
[Worker #1 Mar 13 13:47] Setting affinity to run helper thread 6 on CPU core #4
[Worker #1 Mar 13 13:47] Setting affinity to run helper thread 3 on CPU core #2
[Worker #1 Mar 13 13:47] Setting affinity to run helper thread 4 on CPU core #3
[Worker #1 Mar 13 13:47] Setting affinity to run helper thread 7 on CPU core #4
[Worker #1 Mar 13 13:47] Resuming trial factoring of M216166681 to 2^74
[Worker #1 Mar 13 13:47] Setting affinity to run helper thread 2 on CPU core #2
[Worker #1 Mar 13 13:47] Trial factoring M216166681 to 2^74 is 24.56% complete.
[Worker #2 Mar 13 13:47] Worker starting
[Worker #2 Mar 13 13:47] Setting affinity to run worker on CPU core #5
[Worker #2 Mar 13 13:47] Setting affinity to run helper thread 1 on CPU core #6
[Worker #2 Mar 13 13:47] Setting affinity to run helper thread 2 on CPU core #7
[Worker #2 Mar 13 13:47] Setting affinity to run helper thread 3 on CPU core #8
[Worker #2 Mar 13 13:47]
[/code]

Something went wrong with the assignatio of the CPUs at the worker threads...? or maybe it's just me.

Luigi

[QUOTE=ET_;573572]OK.
Restarted with 30.5.1 a session initiated with 30.4.9, and had the following message:

[code]
[...]
[Worker #1 Mar 13 13:46] Resuming trial factoring of M216166681 to 2^74
[...]
[Worker #2 Mar 13 13:46] Setting affinity to run worker on CPU core #5
[Worker #2 Mar 13 13:46] Setting affinity to run helper thread 1 on CPU core #6
[Worker #2 Mar 13 13:46] Setting affinity to run helper thread 3 on CPU core #8
[/code]

while with version 30.4.9 I had the following allorment for the CPUs:

[code]
[...]
[Worker #1 Mar 13 13:47] Resuming trial factoring of M216166681 to 2^74
[...]
[Worker #2 Mar 13 13:47] Setting affinity to run worker on CPU core #5
[Worker #2 Mar 13 13:47] Setting affinity to run helper thread 1 on CPU core #6
[Worker #2 Mar 13 13:47] Setting affinity to run helper thread 2 on CPU core #7
[Worker #2 Mar 13 13:47] Setting affinity to run helper thread 3 on CPU core #8
[Worker #2 Mar 13 13:47]
[/code]

Something went wrong with the assignatio of the CPUs at the worker threads...? or maybe it's just me.[/QUOTE]

The only difference I can see (apart from the line ordering) is that 30.5 is missing helper thread 2 on worker #2 (which I've clipped your log to in the quote). And of course there's the obligatory question of why you're doing TF on a CPU.

[QUOTE=Happy5214;573576]And of course there's the obligatory question of why you're doing TF on a CPU.[/QUOTE]

Because the PRP-CF-DC category is getting TF assignments right now when there are no DCs.

[QUOTE=ATH;573583]Because the PRP-CF-DC category is getting TF assignments right now when there are no DCs.[/QUOTE]
Still? I thought George fixed that. I've been following since my computers run that work type and received TFs as well, but they were queued far enough in advance that I still have a couple of days worth of PRPs before I run out.

[QUOTE=Happy5214;573587]Still? I thought George fixed that. I've been following since my computers run that work type and received TFs as well, but they were queued far enough in advance that I still have a couple of days worth of PRPs before I run out.[/QUOTE]

I usually get 3 days of work in advance, that's why there was that single TF range on my worktodo :smile:

[QUOTE=ET_;573598]I usually get 3 days of work in advance, that's why there was that single TF range on my worktodo :smile:[/QUOTE]
I cut mine back to 1 day ahead and released the TFs. Two of the machines were only attached to GIMPS for the PRP-CF-DC backlog clearing push. They normally run clients for my personal PRPNet servers, and they're slated to resume that work once their queues dry up. I haven't decided what I'll do with the third (by far the most powerful). I have a few backlogged P-1 and ECM exponents to run, but I don't know if I'll do first-time PRP-CF or start BOINC work after that (which was the original plan post-clearing).

[QUOTE=Happy5214;573587]Still? I thought George fixed that. I've been following since my computers run that work type and received TFs as well, but they were queued far enough in advance that I still have a couple of days worth of PRPs before I run out.[/QUOTE]

Fix is not working, I'm still getting TF just now.

On a completely unrelated note, my PRP-CF-DC test of [M]10841147[/M] somehow ran without even attempting to generate a proof. It's not a big deal, since it was a DC and the residues matched, but this is the first time I recall this happening since I switched to 30.3 (of which I was an early adopter). I don't know if the worktodo line was wrong (it's complete, so the line is gone), but I didn't see anything unusual in the log files. But it didn't even attempt to create a residue file at the beginning of the test, and it sent periodic residues like in the pre-proof era. Actually, looking at the console printouts again, it didn't use Gerbicz on it either. I upgraded from 30.4 to 30.5 midway, but I don't think that had an impact, since 30.4 had already decided the test type (though strangely it did lower the FFT lengths back to 560K from 576K on those tests).

Edit: From my laptop, here's the printout line:
[code][Worker #1 Mar 13 02:16] Starting PRP test of M10841147/24023981753 using FMA3 FFT length 576K, Pass1=384, Pass2=1536, clm=2, 2 threads[/code]

Edit 2: Oh, now I see what happened. Some clown did the first-time test as a type-1 instead of a type-5. Would I get first-time or DC credit if I redid that as a type-5 with proof?

[QUOTE=Happy5214;573602]Edit 2: Oh, now I see what happened. Some clown did the first-time test as a type-1 instead of a type-5. Would I get first-time or DC credit if I redid that as a type-5 with proof?[/QUOTE]

I think you would get a credit.

[QUOTE=Viliam Furik;573612]I think you would get a credit.[/QUOTE]
I know. I meant which one. If it weren't for that winter storm that ravaged Texas, I'd have probably reached 27th place on the all-time PRP-CF-DC rankings. If it counted toward that, I might be able to justify the extra 3 or so hours of work on my laptop to run a type-5.

In that case, I am not sure... Both seem logical, for different reasons, but my guess would be DC since it already has some results.

I've checked my results from CF type 5 after a newly found factor (there were already 4, I found the 5th). Primenet registered them as double-check because there already were some results with fewer factors.

So most probably DC.

I still use 30.4 and found a reproducible way to cause a segmentation fault resulting in a core dump. Don't know if 30.5 fixes this, I can try, but not this week.

- Add this line to worktodo.txt:

[CODE]Pminus1=1,2,9221683,-1,1080000,21600000,69[/CODE]

- Start mprime -m

- Press ^C whilst in stage 2 well after the init stage.

- Choose option 5: quit mprime.

- Change the line in worktodo.txt to

[CODE]Pminus1=1,2,9221683,-1,2000000,21600000,69[/CODE]

- Restart mprime -m

Result:

[CODE]
[Work thread Mar 18 08:45] M9221683 stage 1 complete. 3931780 transforms. Time: 873.316 sec.
[Work thread Mar 18 08:45] With trial factoring done to 2^69, optimal B2 is 81*B1 = 162000000.
[Work thread Mar 18 08:45] If no prior P-1, chance of a new factor is 8.42%
Segmentation fault (core dumped)
henk@Z170:~/mersenne$ ./mprime -m
[/CODE]

Restarting mprime -m leads to same result at same point in execution.
Renaming the file solves the issue:

[CODE]mv m9221683 copy_of_m9221683[/CODE]

[QUOTE=tha;574013]I still use 30.4 and found a reproducible way to cause a segmentation fault resulting in a core dump. Don't know if 30.5 fixes this, I can try, but not this week.
[/QUOTE]

Confirm on 30.5

[QUOTE=tha;574046]Confirm on 30.5[/QUOTE]

Will fix in 30.5 build 2

30.5 build 2 available. It fixes the one reported bug.

When getting P-1 assignments from PrimeNet, is it expected to not trigger the special B2 selection? Example: [M]M103163903[/M]. With Pfactor I'm getting B1=819,000, B2=39,053,000. When manually editing worktodo.txt to the new format of Pminus1 with the B1 from above, I got B2=51*B1=41,769,000. The values are close, but not identical; I have not yet tried other amounts of RAM and would assume that the B2's can differ much more with other settings.

It occurred to me, that stage 2 takes more than double the time of stage 1 in my case, given the bounds above. The system is an AMD 3800X, 32 GB of 3,600 MHz RAM, 16 GB allocated to Prime95, version 30.5b2, only one worker using eight cores. Is this also intentional? I always thought optimal P-1 (timewise) was to have equal time spent on both stages. I understand that it is impossible to estimate this in code for all the different hardware that is out there, but would it be possible to have a parameter for manipulating the B2? E.g. Stage2EffortFactor: 1 would be Prime95's full automatic selection, 0.5 would result in a B2 such that stage 2 takes around half the time. Having that value, one could increase B1 and lower B2 (in my personal case) such that the most efficient work is done per time unit. So that value could also influence the optimal B1 and B2 selection. Of course that only makes sense when my assumption is correct that there should be equal time spent on both stages.

[QUOTE=kruoli;574423]When getting P-1 assignments from PrimeNet, is it expected to not trigger the special B2 selection? Example: [M]M103163903[/M]. With Pfactor I'm getting B1=819,000, B2=39,053,000. When manually editing worktodo.txt to the new format of Pminus1 with the B1 from above, I got B2=51*B1=41,769,000. The values are close, but not identical; I have not yet tried other amounts of RAM and would assume that the B2's can differ much more with other settings.[/quote]

Pfactor uses slightly different optimization criteria than "Pminus1=". Pfactor is optimizing for minimizing the total time spent doing P-1, LL, and DC. That is, it is maximizing the LL/DC CPU savings per unit of P-1 work invested. "Pminus1=" is maximizing the number of factors found per unit of P-1 work invested.

[quote]It occurred to me, that stage 2 takes more than double the time of stage 1 in my case, given the bounds above. The system is an AMD 3800X, 32 GB of 3,600 MHz RAM, 16 GB allocated to Prime95, version 30.5b2, only one worker using eight cores. Is this also intentional? I always thought optimal P-1 (timewise) was to have equal time spent on both stages. I understand that it is impossible to estimate this in code for all the different hardware that is out there, but would it be possible to have a parameter for manipulating the B2? E.g. Stage2EffortFactor: 1 would be Prime95's full automatic selection, 0.5 would result in a B2 such that stage 2 takes around half the time. Having that value, one could increase B1 and lower B2 (in my personal case) such that the most efficient work is done per time unit. So that value could also influence the optimal B1 and B2 selection. Of course that only makes sense when my assumption is correct that there should be equal time spent on both stages.[/QUOTE]

The equal time rule was a general rule of thumb that may have worked back in the day. Prime95 carefully counts every stage 1 and stage 2 transform in making it's decisions.

[QUOTE=Prime95;574261]30.5 build 2 available. It fixes the one reported bug.[/QUOTE]

Thank you for all the support and updating of Prime95! I think it's been 20 years now since I first used it...was it on a Pentium 3 Coppermine or something? My god ...

George, Would it be possible to reduce the size of P-1 stage 2 checkpoint files? Using this with colab / google drive, it takes a very long time to stop/restart during stage 2 - it writes 100-200 MB of save file. I am guessing it is somehow saving the stage 2 prime bitmap or something? I think it would be faster to recompute the state, rather than load it from disk (with google drive).

[QUOTE=axn;575242]I think it would be faster to recompute the state, rather than load it from disk (with google drive).[/QUOTE]Conversely on a local system it works quickly. Any such changes should probably be an optional codepath for special use-cases and not affect the majority of users who don't read/write from Drive.

I suspect that on a local system, you wouldn't be able to tell the difference. But anyways, George will have to confirm if this is even possible or not.

[QUOTE=axn;575242]George, Would it be possible to reduce the size of P-1 stage 2 checkpoint files? Using this with colab / google drive, it takes a very long time to stop/restart during stage 2 - it writes 100-200 MB of save file. I am guessing it is somehow saving the stage 2 prime bitmap or something? I think it would be faster to recompute the state, rather than load it from disk (with google drive).[/QUOTE]

Theoretically possible but I'm very afraid I'd make a mistake. Even the most subtle change in initial state can affect how the primes are paired.

You might try MaximumBitArraySize=n in prime.txt. This limits the maximum bit array size to n MB (default is 250). This will have some negative impact on performance, make a few runs yourself to see if it is significant.

[QUOTE=Prime95;575274]You might try MaximumBitArraySize=n in prime.txt. This limits the maximum bit array size to n MB (default is 250). This will have some negative impact on performance, make a few runs yourself to see if it is significant.[/QUOTE]

Is it safe to change this in the middle of a Stage 2 run?

[QUOTE=axn;575536]Is it safe to change this in the middle of a Stage 2 run?[/QUOTE]

Probably. Never tested.

P95/mprime really needs a way to manually force a proof upload. I periodically have Wi-Fi issues on my laptop (my primary GIMPS computer), and would like a way to upload proofs (I do PRP-CF, so there are quite a few of them) that have backlogged while the Wi-Fi has been out (especially if it will go out again soon). Perhaps add it to the manual communication menu?

An unrelated gripe. I have 5 workers on 8 cores on my laptop. They're never all running at the same time (I run 3 max at a time, 2 cores each). But the benchmarks still use all 5 workers on all 8 cores, a usecase that never happens and causes inaccurate timing due to the core overlap and throttling. It also causes issues on my desktop, as it runs benchmarks with 3 workers on 3 cores, an unused-in-practice scenario which causes it to overheat (it's an old Core 2 box). Can you add a setting to tune the automated benchmarking to a particular worker/core combination other than the full max?

[QUOTE=Happy5214;575933]An unrelated gripe. I have 5 workers on 8 cores on my laptop. They're never all running at the same time (I run 3 max at a time, 2 cores each). [/QUOTE]
Then why not have just 3 workers (or 2 workers)? You're putting the program in an impossible situation. It'd be best to just turn off the benchmark altogether.

[QUOTE=axn;575935]Then why not have just 3 workers (or 2 workers)? You're putting the program in an impossible situation. It'd be best to just turn off the benchmark altogether.[/QUOTE]
Because I run 3 different work types in rotation (3 PRP-CF, 1 ECM, 1 P-1).

[QUOTE=Happy5214;575939]Because I run 3 different work types in rotation (3 PRP-CF, 1 ECM, 1 P-1).[/QUOTE]

Why not have just three workers and change their worktype as and when you want to switch over? Should be just as easy as bringing workers up/down.

Or ... Have two instances of P95 and keep PRP workers in one, and ECM/P-1 in another.

Anyway, with the current setup, your best bet is to just turn off automated benchmarking.

[QUOTE=Prime95;575562]Probably. Never tested.[/QUOTE]

I may have found a "bug" with the FFT speed or size or iterations.

I don't know if it's the same for 10900k (it probably is), but on 11900k, if you disable FMA3, AVX512F and AVX in local.txt and run a small FFT stress test, each loop (multiple loops per FFT size though) finishes in 1 minute. Example, small FFT -->48k, finishes each loop in 1 minute. After several loops it goes to the next FFT.

If you disable AVX512, AVX2 and AVX in the stress test options instead, each loop lasts I think 2 or 3 minutes.

So the loop speed is different if you disable all the AVX settings in local.txt (from undoc.txt) versus disabling them in the stress test options.

Is this intended?

I'm running a P-1 in stage 2, and it's saying it's 100% complete, but it's still running and printing "100% complete" reports at the normal rate. Is there a data issue or is this a problem with the printout that can be safely ignored without compromising the validity of the data until a fix is posted?

[QUOTE=Happy5214;576048]I'm running a P-1 in stage 2, and it's saying it's 100% complete, but it's still running and printing "100% complete" reports at the normal rate. Is there a data issue or is this a problem with the printout that can be safely ignored without compromising the validity of the data until a fix is posted?[/QUOTE]

This also happened to me a few times with older versions. So far nothing with the new versions. Which one are you using?

[QUOTE=Viliam Furik;576049]This also happened to me a few times with older versions. So far nothing with the new versions. Which one are you using?[/QUOTE]
I was using build 1 of mprime 30.5. I upgraded to build 2 with the same results.

[QUOTE=Happy5214;576048]I'm running a P-1 in stage 2, and it's saying it's 100% complete, but it's still running and printing "100% complete" reports at the normal rate. Is there a data issue or is this a problem with the printout that can be safely ignored without compromising the validity of the data until a fix is posted?[/QUOTE]

I've seen the same issue with stage 1 in earlier versions. Restarting the workers resolves the issue.

[QUOTE=ixfd64;576076]I've seen the same issue with stage 1 in earlier versions. Restarting the workers resolves the issue.[/QUOTE]
That didn't help, nor did restarting mprime completely and resuming from there. Will mprime be able to figure out when this test is actually done, display issues aside, or do I need to restart the test/release the exponent?

[QUOTE=Happy5214;576167]That didn't help, nor did restarting mprime completely and resuming from there. Will mprime be able to figure out when this test is actually done, display issues aside, or do I need to restart the test/release the exponent?[/QUOTE]

Can you send the save file and worktodo.txt? Thanks.

[QUOTE=Prime95;576171]Can you send the save file and worktodo.txt? Thanks.[/QUOTE]

I don't have them anymore, because the assignment already finished and got uploaded to PrimeNet (no factor found). :brian-e: You got the PRP test (it was [M]103482079[/M], for future reference). I'll send the files if/when it happens again with another exponent. Sorry for not being helpful.

For the adventurous
 

Prime95 version 30.6 build 2 is available.

I consider the new features to be lightly tested. No need to upgrade unless you are doing ECM or care to try out the new P+1 factoring work.

You could be the first to find a new factor using P+1. I've tried about 10 times without success.

Think of P+1 as a special fast ECM curve -- same chances of success, several times faster than ECM, but you only get to do it once. My thoughts are to choose B1 well above the current B1's being handed out by the server for ECM. For the few exponents I tried in the 4.7M area, ECM is presently being done at B1=50K, I chose P+1 with B1=1M.

From whatsnew.txt:

[CODE]1) P+1 factoring. A worktodo.txt entry looks like this:
Pplus1=k,b,n,c,B1,B2,nth_run[,how_far_factored][,"known_factors"]
Unlike P-1, the fact that factors of Mersenne numbers is 1 mod 2p is of no value.
Thus, P-1 is vastly more effective at finding factors. A P+1 run is about as
valuable as running one ECM curve. P+1 stage 1 is 50% slower than P-1 stage 1
but several times faster than ECM stage 1. P+1 stage 2 is a little faster than
P-1 stage 2 which in turn is a little faster than ECM stage 2.
Unlike P-1, P+1 has only a 50% chance of finding a factor if factor+1 is B1/B2 smooth.
Thus, it makes sense to do 1 or 2 (maybe 3) runs. That is what the nth_run argument is for.
There are two special starting values for P+1 that have a slightly higher chance of
finding a factor. These special starting values correspond to nth_run=1 and nth_run=2.
Like P-1, if how_far_factored is specified, prime95 will ignore B2 and calculate the
best B2 value for the given B1.
2) Faster ECM stage 1 when factoring exponents near the limit of an FFT size.
3) Gwnum library new functions give a programmer more tools to reduce normalized adds.
A tutorial.txt file is now available to help a programmer use the gwnum library.
[/CODE]

Download links:
[B][COLOR="Red"]
Before downloading, make sure prime.spl is uploaded to the server. There is a bug reading spool files created by previous versions.
[/COLOR][/B]
Windows 64-bit: [URL]https://mersenne.org/ftp_root/gimps/p95v306b2.win64.zip[/URL]
Linux 64-bit: [URL]https://mersenne.org/ftp_root/gimps/p95v306b2.linux64.tar.gz[/URL]

George, this is excellent. Thank you!

Would it be possible to add another value to nth_flag, like -1, that signals to the code to run each of the (2, 3?) starting seeds? Also, it's not clear how to make the code do 3 distinct runs on the same number with the same bounds.

[QUOTE=masser;576310]George, this is excellent. Thank you!

Would it be possible to add another value to nth_flag, like -1, that signals to the code to run each of the (2, 3?) starting seeds? Also, it's not clear how to make the code do 3 distinct runs on the same number with the same bounds.[/QUOTE]

Yes, nth_run=3 selects a random starting value.

Given the massive number of exponents in need of P+1, I recommend not doing two P+1 runs on the same exponent. That said, do whatever you find fun.

Is the server set up to handle P+1 result submissions (both "no factor" as well as "factor found")?

Is mersenne.ca?

[QUOTE=axn;576318]Is the server set up to handle P+1 result submissions (both "no factor" as well as "factor found")?
Is mersenne.ca?[/QUOTE]Yes, and yes. Largely untested in both cases of course, so let me know if you find something not working as it should.

[QUOTE=James Heinrich;576319]Yes, and yes. Largely untested in both cases of course, so let me know if you find something not working as it should.[/QUOTE]

Great. Thanks for the confirmation.

P+1 crashes for me when resuming from a save file in stage 2. That's on Windows 7, 64 bit, AVX FFT, example worktodo line: [C]
Pplus1=N/A,1,2,100069,-1,10000000,4000000000,1[/C]

[QUOTE=kruoli;576366]P+1 crashes for me when resuming from a save file in stage 2. That's on Windows 7, 64 bit, AVX FFT, example worktodo line: [C]
Pplus1=N/A,1,2,100069,-1,10000000,4000000000,1[/C][/QUOTE]

Fixed. Build 2 now available. Links in post #150.

I'm testing PP1 with 30.6b2 on Linux and it looks good so far. Resuming in stage 2 worked and I can see the results on mersenne.org. :smile:

The only thing that's missing is automated work assignment. I cannot set the worker preference to PP1 and the manual assignment page also does not offer it.

I got the first new factor with PP1:

P+1 found a factor in stage #2, B1=10000000, B2=1000000000.
[URL="https://www.mersenne.org/report_exponent/?exp_lo=287873&full=1"]M287873[/URL] has a factor: 167460871862758047584571103871 (P+1, B1=10000000, B2=1000000000)


As expected, the factor is very P+1 smooth:

167460871862758047584571103872: 2 2 2 2 2 2 2 3 7 149 31153 137737 1326817 73440613


That's 1 factor out of 73 attempts.

[QUOTE=nordi;576466]I got the first new factor with PP1:

P+1 found a factor in stage #2, B1=10000000, B2=1000000000.
[URL="https://www.mersenne.org/report_exponent/?exp_lo=287873&full=1"]M287873[/URL] has a factor: 167460871862758047584571103871 (P+1, B1=10000000, B2=1000000000)
[/QUOTE]

:party:

Incidentally, even the P-1 is kinda smooth-ish. A B1 of 60m (with a suitable sized B2) could have found it, but of course would've been a lot costlier.

[QUOTE=nordi;576466]I got the first new factor with PP1:
[/QUOTE]

Congrats! Running the early P+1 attempts is going to be so much fun.

[QUOTE=Prime95;576418]Fixed. Build 2 now available. Links in post #150.[/QUOTE]If it's not too much trouble, could it also log the other worktodo entry parameters present after B2 in the worker window? It's not logging the required nth_run parameter.
FYI, the server displays a [URL="https://www.mersenne.org/report_exponent/?exp_lo=103598543&exp_hi=&full=1"]stage1-only result[/URL] for my attempts.

Does build 2 also fix failure to resume in stage 1 from save files after the program interrrupts its own progress for benchmarking, finding all its save files to be bad as build 1 has in my initial testing? Possibly there was no save file saved before the start of benchmarking. That was preceded by some sort of crash that rendered it unusable until I commented out a worktodo entry. (Would not even appear on screen or in Task Manager displays; just hourglass cursor briefly.)
Worktodo for reference, with comments added:
[CODE][Worker #1]
;;Pplus1=N/A,1,2,103598543,-1,1000000,30000000,1 this line ran but 0.3GB default memory was too small for the 367MB stage 2 requirement, stage 2 skipped, and entry was removed by program
;;Pplus1=N/A,1,2,103598543,-1,1000000,30000000,2 this line crashed program and stopped successful relaunch until commented out
Pplus1=N/A,1,2,103598543,-1,1000000,30000000,3 this line ran and generated worker window contents shown below

;;Pplus1=N/A,1,2,103598543,-1,1000000,30000000,2 This line was always commented out, a saved copy

Pfactor=(AID),1,2,103598543,-1,76,2
DoubleCheck=(AID),61020931,74,1
[/CODE]Worker window contents from after the comment out of "Pplus1=N/A,1,2,103598543,-1,1000000,30000000,2" and restart, from entry "Pplus1=N/A,1,2,103598543,-1,1000000,30000000,3":
[CODE][Apr 22 00:05] Worker starting
[Apr 22 00:05] Setting affinity to run worker on CPU core #1
[Apr 22 00:05]
[Apr 22 00:05] P+1 on M103598543 with B1=1000000, B2=30000000
[Apr 22 00:05] Setting affinity to run helper thread 1 on CPU core #2
[Apr 22 00:05] Setting affinity to run helper thread 2 on CPU core #3
[Apr 22 00:05] Setting affinity to run helper thread 3 on CPU core #4
[Apr 22 00:05] Using AVX-512 FFT length 5760K, Pass1=3K, Pass2=1920, clm=1, 4 threads
[Apr 22 00:05] Error reading intermediate file: n103598543
[Apr 22 00:05] Renaming n103598543 to n103598543.bad1
[Apr 22 00:05] Trying backup intermediate file: n103598543.bu
[Apr 22 00:05] Error reading intermediate file: n103598543.bu
[Apr 22 00:05] Renaming n103598543.bu to n103598543.bad2
[Apr 22 00:05] Trying backup intermediate file: n103598543.bu2
[Apr 22 00:05] Error reading intermediate file: n103598543.bu2
[Apr 22 00:05] Renaming n103598543.bu2 to n103598543.bad3
[Apr 22 00:05] All intermediate files bad. Temporarily abandoning work unit.
[Apr 22 00:05] Optimal P-1 factoring of M103598543 using up to 8192MB of memory.
[Apr 22 00:05] Assuming no factors below 2^76 and 2 primality tests saved if a factor is found.
[Apr 22 00:05] Optimal bounds are B1=796000, B2=34294000
[Apr 22 00:05] Chance of finding a factor is an estimated 4.25%
[Apr 22 00:05]
[Apr 22 00:05] Using AVX-512 FFT length 5760K, Pass1=3K, Pass2=1920, clm=1, 4 threads
[Apr 22 00:05] Setting affinity to run helper thread 1 on CPU core #2
[Apr 22 00:05] Setting affinity to run helper thread 2 on CPU core #3
[Apr 22 00:05] Setting affinity to run helper thread 3 on CPU core #4
[Apr 22 00:05] M103598543 stage 1 is 0.07% complete.
[Apr 22 00:17] M103598543 stage 1 is 3.33% complete. Time: 732.338 sec.
[Apr 22 00:30] M103598543 stage 1 is 6.58% complete. Time: 748.808 sec.
[Apr 22 00:42] M103598543 stage 1 is 9.83% complete. Time: 754.124 sec.
[Apr 22 00:56] M103598543 stage 1 is 13.08% complete. Time: 805.479 sec.
[Apr 22 01:09] M103598543 stage 1 is 16.34% complete. Time: 798.707 sec.
[Apr 22 01:22] M103598543 stage 1 is 19.59% complete. Time: 772.745 sec.
[Apr 22 01:35] M103598543 stage 1 is 22.84% complete. Time: 770.437 sec.
[Apr 22 01:48] M103598543 stage 1 is 26.09% complete. Time: 765.248 sec.
[Apr 22 02:00] M103598543 stage 1 is 29.35% complete. Time: 747.334 sec.
[Apr 22 02:12] M103598543 stage 1 is 32.60% complete. Time: 745.663 sec.
[Apr 22 02:25] M103598543 stage 1 is 35.85% complete. Time: 744.883 sec.
[Apr 22 02:37] M103598543 stage 1 is 39.10% complete. Time: 744.670 sec.
[Apr 22 02:50] M103598543 stage 1 is 42.36% complete. Time: 740.006 sec.
[Apr 22 03:02] M103598543 stage 1 is 45.61% complete. Time: 735.905 sec.
[Apr 22 03:14] M103598543 stage 1 is 48.86% complete. Time: 737.190 sec.
[Apr 22 03:27] M103598543 stage 1 is 52.12% complete. Time: 738.341 sec.
[Apr 22 03:39] M103598543 stage 1 is 55.37% complete. Time: 741.178 sec.
[Apr 22 03:51] M103598543 stage 1 is 58.62% complete. Time: 739.355 sec.
[Apr 22 04:04] M103598543 stage 1 is 61.87% complete. Time: 741.066 sec.
[Apr 22 04:16] M103598543 stage 1 is 65.13% complete. Time: 740.033 sec.
[Apr 22 04:28] M103598543 stage 1 is 68.38% complete. Time: 742.332 sec.
[Apr 22 04:42] M103598543 stage 1 is 71.63% complete. Time: 812.386 sec.
[Apr 22 04:55] M103598543 stage 1 is 74.88% complete. Time: 813.312 sec.
[Apr 22 05:05] Worker stopped while running needed benchmarks.
[Apr 22 05:13] Benchmarks complete, restarting worker.
[Apr 22 05:13]
[Apr 22 05:13] P+1 on M103598543 with B1=1000000, B2=30000000
[Apr 22 05:13] Setting affinity to run helper thread 1 on CPU core #2
[Apr 22 05:13] Setting affinity to run helper thread 2 on CPU core #3
[Apr 22 05:13] Setting affinity to run helper thread 3 on CPU core #4
[Apr 22 05:13] Using AVX-512 FFT length 5760K, Pass1=3K, Pass2=1920, clm=1, 4 threads
[Apr 22 05:13] Trying backup intermediate file: n103598543.bad3
[Apr 22 05:13] Error reading intermediate file: n103598543.bad3
[Apr 22 05:13] Trying backup intermediate file: n103598543.bad2
[Apr 22 05:13] Error reading intermediate file: n103598543.bad2
[Apr 22 05:13] Trying backup intermediate file: n103598543.bad1
[Apr 22 05:13] Error reading intermediate file: n103598543.bad1
[Apr 22 05:28] M103598543 stage 1 is 2.21% complete. Time: 948.760 sec.
[Apr 22 05:44] M103598543 stage 1 is 4.51% complete. Time: 916.776 sec.
[Apr 22 05:59] M103598543 stage 1 is 6.82% complete. Time: 917.519 sec.
[Apr 22 06:14] M103598543 stage 1 is 9.13% complete. Time: 916.504 sec.
[Apr 22 06:30] M103598543 stage 1 is 11.44% complete. Time: 919.619 sec.
[Apr 22 06:45] M103598543 stage 1 is 13.73% complete. Time: 917.141 sec.
[Apr 22 07:00] M103598543 stage 1 is 16.03% complete. Time: 914.089 sec.
[Apr 22 07:15] M103598543 stage 1 is 18.35% complete. Time: 914.598 sec.
[Apr 22 07:31] M103598543 stage 1 is 20.64% complete. Time: 913.989 sec.
[Apr 22 07:46] M103598543 stage 1 is 22.92% complete. Time: 912.264 sec.
[/CODE]Will abandon the build 1 run and try again with build 2 shortly.

Build 2 calls all the build 1 P+1 save files bad. Perhaps resulting from a mismatch of nth_run parameter. I don't see anything in file naming that would prevent that mismatch from occurring.
Build 2 also calls bad, but appears to resume from its own stage 1 save file .bad(x) for same nth_run.
Test sequence:
Move all files marked bad. Launch prime95 30.6b2, with worktodo entry "Pplus1=N/A,1,2,103598543,-1,1000000,30000000,1" first in line.
Stop and exit. Restart.
Worker window contents from the restart:[CODE][Apr 22 08:56] Worker starting
[Apr 22 08:56] Setting affinity to run worker on CPU core #1
[Apr 22 08:56]
[Apr 22 08:56] P+1 on M103598543 with B1=1000000, B2=30000000
[Apr 22 08:56] Setting affinity to run helper thread 1 on CPU core #2
[Apr 22 08:56] Setting affinity to run helper thread 2 on CPU core #3
[Apr 22 08:56] Setting affinity to run helper thread 3 on CPU core #4
[Apr 22 08:56] Using AVX-512 FFT length 5760K, Pass1=3K, Pass2=1920, clm=1, 4 threads
[Apr 22 08:56] Error reading intermediate file: n103598543
[Apr 22 08:56] Renaming n103598543 to n103598543.bad1
[Apr 22 08:56] All intermediate files bad. Temporarily abandoning work unit.
[Apr 22 08:56]
[Apr 22 08:56] P+1 on M103598543 with B1=1000000, B2=30000000
[Apr 22 08:56] Setting affinity to run helper thread 1 on CPU core #2
[Apr 22 08:56] Setting affinity to run helper thread 2 on CPU core #3
[Apr 22 08:56] Setting affinity to run helper thread 3 on CPU core #4
[Apr 22 08:56] Using AVX-512 FFT length 5760K, Pass1=3K, Pass2=1920, clm=1, 4 threads
[Apr 22 08:56] Trying backup intermediate file: n103598543.bad1
[Apr 22 08:56] M103598543 stage 1 is 1.09% complete.
[/CODE]

[QUOTE=kriesel;576485]If it's not too much trouble, could it also log the other worktodo entry parameters present after B2 in the worker window? It's not logging the required nth_run parameter.
FYI, the server displays a [URL="https://www.mersenne.org/report_exponent/?exp_lo=103598543&exp_hi=&full=1"]stage1-only result[/URL] for my attempts.[/QUOTE]

Are you using build 2 because it is logging B2 for me. The nth_run is also logged like this: nth_run=1 means Start=2/7 and nth_run=2 means: Start=6/5, so the initial seed is logged not the actually nth_run value.

[QUOTE=ATH;576490]Are you using build 2 because it is logging B2 for me. The nth_run is also logged like this: nth_run=1 means Start=2/7 and nth_run=2 means: Start=6/5, so the initial seed is logged not the actually nth_run value.[/QUOTE]I did not claim it hides B2. As a fresh install of v30.6b1 in a new folder, I forgot to reset the small default allowed memory at first, so it skipped [U]running[/U] stage 2 until that small memory limit was dealt with.
As stated previously, I have run prime95 v30.6b1 and v30.6b2 repeatedly. Neither indicated [B]nth_run[/B] [U]in the worker window[/U]. Ever. The one results.json.txt entry for the one stage1 completion so far indicates the corresponding start value. But the worker windows have never indicated the [B]nth_run[/B] parameter following the B2 value in the worktodo file's active line (or the corresponding start value in a worker window). So we must either deduce from the worker history or results file, or open the worktodo file, to see which worktodo line is currently in effect, of nth_run = 1, 2, or 3 for the same exponent/bounds set:
[CODE][Worker #1]
Pplus1=N/A,1,2,exponent,-1,B1,B2,[B]1[/B]
Pplus1=N/A,1,2,exponent,-1,B1,B2,[B]2[/B]
Pplus1=N/A,1,2,exponent,-1,B1,B2,[B]3[/B]
[/CODE]

Since it is not possible to reserve work for P+1, I'd like to unofficially reserve
[LIST][*]all already factored exponents from 95k-100k[*]all already factored exponents from 295k-300k[/LIST]I'll run a first (and if that looks promising, also a second) P+1 curve on them.

[QUOTE=kriesel;576485]

[/CODE]Worker window contents from after the comment out of "Pplus1=N/A,1,2,103598543,-1,1000000,30000000,2" and restart, from entry "Pplus1=N/A,1,2,103598543,-1,1000000,30000000,3":
[CODE][Apr 22 00:05] Worker starting
[Apr 22 00:05] Setting affinity to run worker on CPU core #1
[Apr 22 00:05]
[Apr 22 00:05] P+1 on M103598543 with B1=1000000, B2=30000000

[Apr 22 00:05] All intermediate files bad. Temporarily abandoning work unit.
[Apr 22 00:05] Optimal P-1 factoring of M103598543 using up to 8192MB of memory.
[Apr 22 00:05] Assuming no factors below 2^76 and 2 primality tests saved if a factor is found.
[Apr 22 00:05] Optimal bounds are B1=796000, B2=34294000
[Apr 22 00:05] Chance of finding a factor is an estimated 4.25%
[Apr 22 04:55] M103598543 stage 1 is 74.88% complete. Time: 813.312 sec.
[Apr 22 05:05] Worker stopped while running needed benchmarks.
[Apr 22 05:13] Benchmarks complete, restarting worker.
[Apr 22 05:13]
[Apr 22 05:13] P+1 on M103598543 with B1=1000000, B2=30000000
[Apr 22 05:28] M103598543 stage 1 is 2.21% complete. Time: 948.760 sec.

[/CODE]Will abandon the build 1 run and try again with build 2 shortly.[/QUOTE]

Am I reading this wrong because it appears that:

After the "All ... bad" it switched from P+1 to P-1
Then after Benchmarks it switched back to P+1

[QUOTE=kriesel;576487]worktodo entry "Pplus1=N/A,1,2,103598543,[b][color=red]-1[/color][/b],1000000,30000000,1"[/QUOTE]Apparently Prime95 doesn't have sufficient worktodo sanity checks and you're confusing it.
You're specifying [c]Pplus1[/c] as the worktype but setting [c]c[/c] to [c]-1[/c] instead of [c]+1[/c].

[CODE]
[Work thread Apr 22 17:45]
[Work thread Apr 22 17:45] P-1 on M9994027 with B1=2000000, B2=TBD
[Work thread Apr 22 17:45] Setting affinity to run helper thread 1 on CPU core #2
[Work thread Apr 22 17:45] Using FMA3 FFT length 512K, Pass1=256, Pass2=2K, clm=4, 4 threads
[Work thread Apr 22 17:45] Setting affinity to run helper thread 2 on CPU core #3
[Work thread Apr 22 17:45] Setting affinity to run helper thread 3 on CPU core #4
[Comm thread Apr 22 17:45] PrimeNet success code with additional info:
[Comm thread Apr 22 17:45] CPU credit is 4.2951 GHz-days.
[Comm thread Apr 22 17:45] Done communicating with server.
[Work thread Apr 22 17:52] M9994027 stage 1 is 34.65% complete. Time: 449.871 sec.
[Work thread Apr 22 18:00] M9994027 stage 1 is 69.30% complete. Time: 449.951 sec.
[Work thread Apr 22 18:06] M9994027 stage 1 complete. 5771292 transforms. Time: 1298.014 sec.
[Work thread Apr 22 18:06] With trial factoring done to 2^69, optimal B2 is 81*B1 = 162000000.
[Work thread Apr 22 18:06] If no prior P-1, chance of a new factor is 8.48%
[Work thread Apr 22 18:06] D: 1050, relative primes: 2716, stage 2 primes: 8931296, pair%=94.85
[Work thread Apr 22 18:06] Using 11079MB of memory.
[Work thread Apr 22 18:07] Stage 2 init complete. 26786 transforms. Time: 14.315 sec.
[Work thread Apr 22 18:16] M9994027 stage 2 is 20.08% complete. Time: 583.811 sec.
[Work thread Apr 22 18:26] M9994027 stage 2 is 40.59% complete. Time: 591.544 sec.
[Work thread Apr 22 18:38] M9994027 stage 2 is 60.94% complete. Time: 695.522 sec.
[Work thread Apr 22 18:48] M9994027 stage 2 is 80.68% complete. Time: 607.794 sec.
[Work thread Apr 22 18:59] M9994027 stage 2 complete. 9952730 transforms. Time: 3140.027 sec.
[Work thread Apr 22 18:59] Stage 2 GCD complete. Time: 1.496 sec.
[Work thread Apr 22 18:59] P-1 found a factor in stage #2, B1=2000000, B2=162000000.
[Work thread Apr 22 18:59] M9994027 has a factor: 17810607008131132507712387230764284167013708502268550663 (P-1, B1=2000000, B2=162000000)
[Comm thread Apr 22 18:59] Sending result to server: UID: Tha/Z-170, M9994027 has a factor: 17810607008131132507712387230764284167013708502268550663 (P-1, B1=2000000, B2=162000000)
[Comm thread Apr 22 18:59]
[Work thread Apr 22 18:59]
[Work thread Apr 22 18:59] P-1 on M9095773 with B1=2000000, B2=TBD
[Work thread Apr 22 18:59] Setting affinity to run helper thread 1 on CPU core #2
[Work thread Apr 22 18:59] Using FMA3 FFT length 480K, Pass1=384, Pass2=1280, clm=4, 4 threads
[Work thread Apr 22 18:59] Setting affinity to run helper thread 2 on CPU core #3
[Work thread Apr 22 18:59] Setting affinity to run helper thread 3 on CPU core #4
[Comm thread Apr 22 18:59] PrimeNet success code with additional info:
[Comm thread Apr 22 18:59] Composite factor 17810607008131132507712387230764284167013708502268550663 = 72324517147464481 * 142671321621631468162223 * 1726062406753801
[Comm thread Apr 22 18:59] Already have factor 72324517147464481 for M9994027
[Comm thread Apr 22 18:59] Already
[Comm thread Apr 22 18:59] Done communicating with server.

[/CODE]

So, mprime 30.5 build 1 found a new factor for an exponent of which three factors were already found before. In the composite factor found two of those three factors were included, the new one of course as well. In the output one previous factor is mentioned correctly, the line that should mention the second previous factor is cut short somehow.

Not sure if it is stupid what I'm doing (it most probably is), but I'm getting stuck for an unreasonable amount of time in the "initializing step" for stage 2 and the CPU is only used a few percent there. This only happens for very small Mersenne numbers.


[CODE]
Work thread Apr 22 18:28] P+1 on M10069 with B1=10000000, B2=1000000000
[Work thread Apr 22 18:28] Using FMA3 FFT length 512
[Work thread Apr 22 18:34] M10069 stage 1 complete. 43734619 transforms. Time: 353.174 sec.
[Work thread Apr 22 18:34] Stage 1 GCD complete. Time: 0.000 sec.
[Work thread Apr 22 18:40] D: 6930, relative primes: 37104, stage 2 primes: 20838028, pair%=97.80
[Work thread Apr 22 18:40] Using 391MB of memory.
[Work thread Apr 22 18:40] Stage 2 init complete. 119099 transforms. Time: 313.681 sec.
[Work thread Apr 22 18:47] D: 6930, relative primes: 37104, stage 2 primes: 20064499, pair%=96.45
[Work thread Apr 22 18:53] D: 6930, relative primes: 37104, stage 2 primes: 9280428, pair%=95.76
[Work thread Apr 22 18:55] M10069 stage 2 complete. 52013496 transforms. Time: 923.786 sec.
[/CODE]
Why did it take 6 minutes to initiliaze after calculating stage 1 GCD? Something strange must be going on here. might be a bug...

[QUOTE=James Heinrich;576504]Apparently Prime95 doesn't have sufficient worktodo sanity checks and you're confusing it.
You're specifying [c]Pplus1[/c] as the worktype but setting [c]c[/c] to [c]-1[/c] instead of [c]+1[/c].[/QUOTE]

Well, [B]someone[/B]'s confused :wink:

c=-1 defines the number being factored (i.e. Mersenne) and not related to the method of factorization.

[QUOTE=James Heinrich;576504]Apparently Prime95 doesn't have sufficient worktodo sanity checks and you're confusing it.
You're specifying [c]Pplus1[/c] as the worktype but setting [c]c[/c] to [c]-1[/c] instead of [c]+1[/c].[/QUOTE]ACK! Thanks for spotting and pointing it out. Fixed and restarted.
I've handwritten countless P[B]-[/B]1 worktodo lines over the years. Old habits die hard.

edit: Oh, wait, thanks axn, kbnc notation (k b^n + c) for Mp= 2^p - 1 is 1,2,p,-1. Back to as it was.
From whatsnew.txt:
[CODE]1) P+1 factoring. A worktodo.txt entry looks like this:
Pplus1=k,b,n,c,B1,B2,nth_run[,how_far_factored][,"known_factors"][/CODE](I may be setting a new personal record for attempts per completed factoring try here. Are we having fun yet?!)

[QUOTE=axn;576512]Well, [B]someone[/B]'s confused :wink:[/QUOTE]Hmm, I think I am confused. Sorry. :redface:

[QUOTE=kriesel;576497]So we must either deduce from the worker history or results file, or open the worktodo file, to see which worktodo line is currently in effect, of nth_run = 1, 2, or 3 for the same exponent/bounds set:
[CODE][Worker #1]
Pplus1=N/A,1,2,exponent,-1,B1,B2,[B]1[/B]
Pplus1=N/A,1,2,exponent,-1,B1,B2,[B]2[/B]
Pplus1=N/A,1,2,exponent,-1,B1,B2,[B]3[/B]
[/CODE][/QUOTE]

George mentions it making sense to run 2 or maybe 3 runs, but he only mentions nth_run=1 and nth_run=2 for the 2 special starting seeds 2/7 and 6/5, not sure nth_run=3 exists.

[QUOTE]Unlike P-1, P+1 has only a 50% chance of finding a factor if factor+1 is B1/B2 smooth.
Thus, it makes sense to do 1 or 2 (maybe 3) runs. That is what the nth_run argument is for.
There are two special starting values for P+1 that have a slightly higher chance of
finding a factor. These special starting values correspond to nth_run=1 and nth_run=2.[/QUOTE]

Regarding the special P+1 seeds, from GMP-ECM Readme:

[QUOTE]However not all seeds will succeed: only half of the seeds 'x0' work for P+1
(namely those where the Jacobi symbol of x0^2-4 and P is -1.) Unfortunately,
since P is usually not known in advance, there is no way to ensure that this
holds. However, if the seed is chosen randomly, there is a probability of
about 1/2 that it will give a Jacobi symbol of -1 (i.e., the factor P will
be found if P+1 is smooth enough). A rule of thumb is to run 3 times P+1
with different random seeds. The seeds 2/7 and 6/5 have a slightly higher
chance of success than average as they lead to a group order divisible by
6 or 4, respectively. When factoring Fibonacci numbers F_n or Lucas
numbers L_n, using the seed 23/11 ensures that the group order is
divisible by 2n, making other P+1 (and probably P-1) work unnecessary.[/QUOTE]

[QUOTE=ATH;576521]not sure nth_run=3 exists.[/QUOTE]It does:[QUOTE=Prime95;576313]Yes, nth_run=3 selects a random starting value.[/QUOTE]

The latest version is running fine on my old Xeon with Windows 7 Pro. :smile:

[QUOTE=tha;576508][CODE]
[Comm thread Apr 22 18:59] PrimeNet success code with additional info:
[Comm thread Apr 22 18:59] Composite factor 17810607008131132507712387230764284167013708502268550663 = 72324517147464481 * 142671321621631468162223 * 1726062406753801
[Comm thread Apr 22 18:59] Already have factor 72324517147464481 for M9994027
[Comm thread Apr 22 18:59] Already
[Comm thread Apr 22 18:59] Done communicating with server.
[/CODE]

So, mprime 30.5 build 1 found a new factor for an exponent of which three factors were already found before. In the composite factor found two of those three factors were included, the new one of course as well. In the output one previous factor is mentioned correctly, the line that should mention the second previous factor is cut short somehow.[/QUOTE]

Fixed in next build. Thanks.

[QUOTE=kriesel;576487]Build 2 calls all the build 1 P+1 save files bad. Perhaps resulting from a mismatch of nth_run parameter.
[/QUOTE]

Yes, the save file contains the nth_run info and it must match the worktodo.txt nth_run parameter.

I've added a message when a save file is rejected due to mismatched nth_run.

I've also added the starting fraction: 2/7, 6/5, whatever to the P+1 start message.

2nd P+1 factor found by "Dylan Delgado": [M]1600967[/M] 20960634373165261374400215271 B1=2000000 B2=146000000
29 digits ~94.1 bits

It was the 496th reported curve.


Could it be a bug that a P-1 run was registered as a P+1 ?
The factors of P-1 fits within B1 and B2, but not P+1 factors:

P+1 = 2^3 x 11 x 13 x 16047334103 x 1141761785856421

P-1 = 2 x 3^4 x 5 x 219889 x 864733 x 1600967 x 85006373

Hmm is this a feature of the new P+1 that it is running P-1 at the same time?

I did a P+1 test on a known factor that was found with P-1: [M]173683[/M]

P+1 found a factor in stage #2, B1=200000, B2=200000000.
M173683 has a factor: 973878325823253786426041 (P+1, B1=200000, B2=200000000)

Again it is the P-1 factors that fits B1 and B2.

P+1 = 2 x 3 x 3356964889 x 48351132547063

P-1 = 2^3 x 5 x 11 x 59 x 409 x 3989 x 173683 x 132390053

[QUOTE=ATH;576579]Hmm is this a feature of the new P+1 that it is running P-1 at the same time?[/QUOTE]

Yes, kind of. Remember that P+1 only find 50% of factors where factor+1 is B1/B2 smooth? That's because half the time it gets a hit if factor-1 is B1/B2 smooth.

It does show that relatively deep P-1 should be run (because it is faster and gets log2(2*p) free bits of smoothness) before doing a P+1 run.

[QUOTE=gLauss;576509]
Why did it take 6 minutes to initiliaze after calculating stage 1 GCD? Something strange must be going on here. might be a bug...[/QUOTE]

I've reproduced the problem, I'll figure it out and find a fix.

[QUOTE=Prime95;576581]Yes, kind of. Remember that P+1 only find 50% of factors where factor+1 is B1/B2 smooth? That's because half the time it gets a hit if factor-1 is B1/B2 smooth.

It does show that relatively deep P-1 should be run (because it is faster and gets log2(2*p) free bits of smoothness) before doing a P+1 run.[/QUOTE]

Very nice, so do we call this the 2nd P+1 factor or a missed late found P-1 factor: [M]1600967[/M]


Does it save time doing both or is the cost the combined cost of P+1 and the faster P-1 ?`

Another two factors found with P+1. One is P-1 smooth:

[URL="https://www.mersenne.org/report_exponent/?exp_lo=1601783&full=1"]M1601783[/URL]: 5920048152491971978196689064497 - 1 = 2^4 x 3 x 191 x 6637 x 10103 x 53017 x 1601783 x 113399107

and one is P+1 smooth:

[URL="https://www.mersenne.org/report_exponent/?exp_lo=296663&full=1"]M296663[/URL]: 33472736879943425145991507583 + 1 = 2^7 x 3 x 3 x 7 x 79 x 3361 x 41897 x 9979727 x 37388971

I ran some P+1 and when submitting a result I see PrimeNet error 13: [C]Server database full or broken.[/C]

P+1 found a composite factor for [M]123031[/M] 120815644174984431693267614423021994991

5th factor out of 957 curves: [M]1602143[/M] 43496906104874570142712609

P-1 smooth again, so it is really only 2 P+1 factors and 3 P-1 factors found by "P+1" test.


P+1 = 2 x 5 x 7 x 11 x 56489488447889052133393

P-1 = 2^5 x 3^3 x 15241 x 17977 x 1602143 x 114686597

[QUOTE=Uncwilly;576604]I ran some P+1 and when submitting a result I see PrimeNet error 13: [C]Server database full or broken.[/C]

P+1 found a composite factor for [M]123031[/M] 120815644174984431693267614423021994991[/QUOTE]

That's a product of the previously known factors 2214559 and 54555170656995109045759275062449.

[QUOTE=Uncwilly;576604]I ran some P+1 and when submitting a result I see PrimeNet error 13: [C]Server database full or broken.[/C]

P+1 found a composite factor for [M]123031[/M] 120815644174984431693267614423021994991[/QUOTE]
This might be because I did some very small (B1=100000) PP1 test for this exponent already yesterday. Started at exponents above 123000 and moved on a few exponents. Does anyone know which B1 is optimal to choose? I would assume something like B1 is 10 times larger than the largest ECM curve run on it? I'm doing it on my gut feeling right now, but if somebody can give some guidance, that would be better...

One remark: I would suggest that prime95 always includes "p" as factor, like in P-1 testing? Otherwise, if a PP1 test happens to turn out to be actually a slow P-1 test (50% chance), than it will never find any factors if B1 < p holds, even if a P-1 test would have found it with the same bounds. Obviously, this is more important for large p...

[QUOTE=ixfd64;576607]That's a product of the previously known factors 2214559 and 54555170656995109045759275062449.[/QUOTE]
Thus my use of the word composite in my original post.:blahblahblah:

[QUOTE=gLauss;576609]This might be because I did some very small (B1=100000) PP1 test for this exponent already yesterday. Started at exponents above 123000 and moved on a few exponents.[/QUOTE]I went through the 1230xx numbers (the ones you ran) doing P+1 with higher bounds. Prime95 found a number of factors. For several it did not even attempt to report them. The last one of the batch it did successfully report a NF-PP1. :chappy:

[QUOTE=Uncwilly;576604]I ran some P+1 and when submitting a result I see PrimeNet error 13: [C]Server database full or broken.[/C]

P+1 found a composite factor for [M]123031[/M] 120815644174984431693267614423021994991[/QUOTE]

Please email the results.json.txt. Thanks.

This is probably way down the road, but will we get a [URL="https://www.mersenne.org/report_factoring_effort/?exp_lo=14070000&exp_hi=14079999"]status page like this[/URL] for the P+1 effort at some point?

Is there a convenient way to see what has been done over a range of exponents and generate a csv or xml file? No rush, just curious.

[QUOTE=masser;576621]This is probably way down the road, but will we get a [URL="https://www.mersenne.org/report_factoring_effort/?exp_lo=14070000&exp_hi=14079999"]status page like this[/URL] for the P+1 effort at some point?

Is there a convenient way to see what has been done over a range of exponents and generate a csv or xml file? No rush, just curious.[/QUOTE]
Or P+1 relevant columns, added to that page, that already has TF and P-1 combined concisely?
What would that look like;
separate B1 and B2 columns for each of 2/7, 6/5, and random, 6 columns added? A seventh column as count of random runs?

[QUOTE=kriesel;576626]Or P+1 relevant columns, added to that page, that already has TF and P-1 combined concisely?
What would that look like;
separate B1 and B2 columns for each of 2/7, 6/5, and random, 6 columns added? A seventh column as count of random runs?[/QUOTE]

It may be more useful to add an ECM "stage estimator" that indicates what level of ECM has been performed. At some point, it might be good to lump the P+1 runs in with the ECM runs; we could view P+1 as just a few special ECM cases that happen to run a lot faster.

[QUOTE=masser;576621]This is probably way down the road, but will we get a [URL="https://www.mersenne.org/report_factoring_effort/?exp_lo=14070000&exp_hi=14079999"]status page like this[/URL] for the P+1 effort at some point?[/QUOTE]The placeholder report is already in place at [url]https://www.mersenne.org/report_pplus1/[/url]
It still needs to be refined.