ECM users - version 30.9-30.13 (see post#316)

[Prime95]

Originally Posted by James Heinrich

Admittedly this is from v30.8 but I noticed this syntax only half-works:
CoresPerTest=6 during 7:30-23:30 else 8
It works in that tests start with the appropriate number of cores for the time period.
It doesn't work in that, unlikely memory limits, it doesn't restart the workers with the new number of threads when the next time interval starts.

I don't think CoresPerTest is one of the options that supports the during clause.

[James Heinrich]

Originally Posted by Prime95

I don't think CoresPerTest is one of the options that supports the during clause.

But as I said above, it kindof-does. The number of cores is set correctly in the specified time period. It just doesn't attempt to restart workers when a new period starts. Would that be something easy to fix?

[Prime95]

Originally Posted by James Heinrich

But as I said above, it kindof-does. The number of cores is set correctly in the specified time period. It just doesn't attempt to restart workers when a new period starts. Would that be something easy to fix?

The "half works" part will be true of most any INI setting.

I'll throw in some code for you to try out in 30.12.

[Prime95]

30.12 build 1

PRE-BETA software!

Since last build:
-- rare gwnum radix conversion bug fixed for LLR/PFGW
-- bug in waking up thread to upload proofs fixed
-- changed default settings for a faster stage 2 (at least on my 2 machines)
-- James' timed CoresPerTest setting might work

Caveats? Same as previous builds:
Worker groups not yet implemented
Stage 2 time estimates and optimal B2 bounds could be off
Accurate estimates of stage 2 memory consumed may be off
Further stage 2 multithreading improvements are needed.
Stage 2 is pretty verbose, there's lots of code cleanup in my future.

Back up prime.txt and local.txt before running this new version!

Windows 64-bit: https://mersenne.org/download/softwa...12b1.win64.zip
Linux 64-bit: https://mersenne.org/download/softwa...linux64.tar.gz
Source: https://mersenne.org/download/softwa...2b1.source.zip

[DrobinsonPE]

In this thread https://www.mersenneforum.org/showthread.php?t=27477 I am working on finding factors in the 7.3M range. I have a computer running P-1 on all of the un-factored exponents in the 7.37M range with B1=33200000 and mprime30.8b17 choosing B2=127558225410. I am trying to speed up the process so I put gpuowl-v7.2-129 to work on a RX-6600 running a batch of the 7.37M range with B1=33200000 so that I can feed the results into mprime to do the B2.

Testing on a different computer resulted in the following:
mprime30.8b17 - https://www.mersenne.org/report_expo...7379929&full=1. Starting at the end of B1, mprime picked a B1 and a corresponding B2 that was much lower than expected. It then figured out that B1 was already run to 33200000 but still ran the B2 it had already selected. Then it reported to Primenet the B1 and B2 values that it had originally picked. Having read this thread https://www.mersenneforum.org/showthread.php?t=27366 I already knew that was going to happen but wanted to know what B2 it would pick.

I then downloaded mprime 30.11 from this thread.

[Main thread Apr 3 18:44] Mersenne number primality test program version 30.11
[Main thread Apr 3 18:44] Optimizing for CPU architecture: AMD Zen, L2 cache size: 4x512 KB, L3 cache size: 4 MB
[Worker Apr 3 18:44] Optimal P-1 factoring of M7379929 using up to 28262MB of memory.
[Worker Apr 3 18:44] Optimal bounds are B1=542000, B2=1015736000
[Worker Apr 3 18:55] M7379929 completed P-1, B1=33200000, B2=1019486160, Wi8: 81B0AA24

Improvement is that it properly recognized and reported the correct B1 in the results file. Unfortunately, it still ran B2 with the original B2 it selected that is about 100 times lower than I would like to run B2.

I just downloaded mprime 30.12 and ran the same number and it acted identical to 30.11.

the worktodo file that came out of gpuowl and was run with mprime for all three runs above is:
Pfactor=N/A,1,2,7379929,-1,67,9 (I added the N/A)
Obviously I also included the data file for that exponent from gpuowl into the mprime directory as well.

My questions are:
Am I messing up the process in some way that is causing the problem?
Can I modify Pfactor=N/A,1,2,7379929,-1,67,9 in any way to tell mprime to run B2=127B?
Is there a way mprime can choose the B2 value taking the already run B1 value into consideration?

[Prime95]

Originally Posted by DrobinsonPE

Am I messing up the process in some way that is causing the problem?
Can I modify Pfactor=N/A,1,2,7379929,-1,67,9 in any way to tell mprime to run B2=127B?
Is there a way mprime can choose the B2 value taking the already run B1 value into consideration?

You are not messing up the process. This is the workflow that Preda envisioned for P-1 on wavefront exponents.

You can try this for your workflow:
Pminus1=N/A,1,2,7379929,-1,1000000,127000000000,67
Pminus1=N/A,1,2,7379929,-1,1000000,100000000,67
Pminus1=N/A,1,2,7379929,-1,33200000,3320000000,67
Pminus1=N/A,1,2,7379929,-1,33200000,127000000000,67

One of the above ought to do what you want.

[James Heinrich]

Originally Posted by Prime95

30.12 build 1
-- James' timed CoresPerTest setting might work

Seems to work as expected, thanks George!

[Apr 7 23:30] Worker stopped.
[Apr 7 23:30] Worker starting
...
[Apr 7 23:31] Resuming primality test of M89522959 using AVX-512 FFT length 4800K, Pass1=768, Pass2=6400, clm=1, 8 threads
...
[Main thread Apr 8 07:30] Restarting all worker windows with new timed INI settings.
[Main thread Apr 8 07:30] Restarting all workers using new timed prime.txt settings.
[Apr 8 07:30] Stopping primality test of M89522959 at iteration 64435423 [71.976422%]
[Apr 8 07:30] Worker stopped.
[Apr 8 07:30] Worker starting
...
[Apr 8 07:31] Resuming primality test of M89522959 using AVX-512 FFT length 4800K, Pass1=768, Pass2=6400, clm=1, 5 threads

[DrobinsonPE]

Originally Posted by Prime95

You can try this for your workflow:
Pminus1=N/A,1,2,7379929,-1,1000000,127000000000,67
Pminus1=N/A,1,2,7379929,-1,1000000,100000000,67
Pminus1=N/A,1,2,7379929,-1,33200000,3320000000,67
Pminus1=N/A,1,2,7379929,-1,33200000,127000000000,67

One of the above ought to do what you want.

Thank you so much! Not only did I get it to work, I also now understand better how prime95 works. I should have been able to figure this out. The "data file" gpuowl created is just the same as the save file prime95 creates. Pfactor and Pminus1 both do the same thing so the save files are interchangable.

I started mprime 30.12 on one computer with Pminus1=N/A,1,2,7379929,-1,1000000,127000000000,67

[Main thread Apr 8 14:11] Mersenne number primality test program version 30.12
[Worker Apr 8 14:11] P-1 on M7379929 with B1=1000000, B2=TBD
[Worker Apr 8 14:11] Ignoring suggested B1 value, using B1=33200000 from the save file
[Worker Apr 8 14:11] Ignoring suggested B2 value, using B2=170088510900 from the save file
[Worker Apr 8 14:11] Resuming P-1 in stage 2 with B2=170088510900

It worked! A little strange that it ignored the B2 in the worktodo but apparently the save file suggested B2=170088510900. That could work but now to experiment.

At this point I realized that I could just feed mprime with the Pminus1 worktodo entries that i created in the first place to run all of the 7.37M exponents so I started mprime 30.12 on another computer with Pminus1=N/A,1,2,7375729,-1,33200000,0,72

[Main thread Apr 8 09:23] Mersenne number primality test program version 30.12
[Worker Apr 8 09:23] P-1 on M7375729 with B1=33200000, B2=TBD
[Worker Apr 8 09:23] Ignoring suggested B2 value, using B2=170165043510 from the save file
[Worker Apr 8 09:23] Resuming P-1 in stage 2 with B2=170165043510

Great! I do not even have to edit any worktodo entries, the ones I already have will work. however, there is still the issue of the the save file suggested B2=170088510900. Time to experiment some more.

Next I tried this worktodo entry Pminus1=N/A,1,2,7375729,-1,33200000,127000000000,72

[Main thread Apr 9 07:40] Mersenne number primality test program version 30.12
[Worker Apr 9 07:40] P-1 on M7375729 with B1=33200000, B2=TBD
[Worker Apr 9 07:40] With trial factoring done to 2^72, optimal B2 is 2959*B1 = 98238800000.

Interesting development, this time it ignored both the B2 in the save file and the B2 in the worktodo and it chose a B2 value based on the trial factoring done to 2^72. What happens if I get rid of the trial factoring?

Worktodo entry Pminus1=N/A,1,2,7375729,-1,33200000,127000000000

[Main thread Apr 9 07:49] Mersenne number primality test program version 30.12
[Worker Apr 9 07:49] P-1 on M7375729 with B1=33200000, B2=127000000000

Success!

One last question. Is mprime 30.12 stable enough to use or should I wait for a not pre-beta version of mprime?

[Prime95]

Originally Posted by DrobinsonPE

One last question. Is mprime 30.12 stable enough to use or should I wait for a not pre-beta version of mprime?

You should be OK using 30.12. I've been using 30.12 for 2 weeks (PRP and ECM) without any issues.

[cmpute]

I wonder what's the criteria of running a PRP-CF after a found factor? I recently done several PFactor tasks at around 15M, the PRP-CF was not triggered. Is it because of the PFactor task type or the exponent size?

[ryanp]

Originally Posted by Prime95

30.12 build 1
-- rare gwnum radix conversion bug fixed for LLR/PFGW

I'm curious to learn more about this. Under what circumstances would this bug manifest? Is it worth doing new builds of LLR + PFGW?