Prime95 30.8 (beta, big P-1 changes, see post #551)

[kruoli]

I would assume that Prime95 is showing this message because of the greyed-out field (certification work) which is set to 0. You might have to enable CERT work, change this value to e.g. 1, then disable CERT work again. Then you should be able to change the setting you want.

[Prime95]

Originally Posted by storm5510

The two images below are from v30.8 B12. If I click the "OK" button on the Advanced Settings, then the warning dialog appears. The second images shows what is covered by the warning. It is requesting a value of 1 to 100 which already appears to be satisfied. It must not be aware of the current values.

Fixed next release/build.

[ATH]

Is the formula for GHz-Days based on the version number in the json result file?

I finished some P-1 back in January that I did not turn in, because the rewards was off the charts broken, I turned in this now but it still gave too much:

processing: P-1 no-factor for M7508981 (B1=1,000,000,000, B2=10,045,573,648,110)
CPU credit is 219721.2393 GHz-days.

[James Heinrich]

Originally Posted by ATH

Is the formula for GHz-Days based on the version number in the json result file?

I doubt it, but it is influenced by the FFT length. My calculator shows about 27% lower credit for those bounds, but PrimeNet would know more details about the FFT length actually used which could easily differ from the default values I have (George mentioned this a few posts back).

[kriesel]

For probing what is the minimum allowed exponent, I tried running v30.8b14 P-1 on some very low exponents.
It allows running very low exponents.
It missed some known small factors.
See for example M41, M67, M71.
For M73 and M79, factors are found in stage 1.

[Denial140]

Originally Posted by kriesel

For probing what is the minimum allowed exponent, I tried running v30.8b14 P-1 on some very low exponents.
It allows running very low exponents.
It missed some known small factors.
See for example M41, M67, M71.
For M73 and M79, factors are found in stage 1.

I think this may be an issue with the P-1 algorithm itself rather than v30.8b14 - I haven't checked the rest, but for M41, all factors have k that is 50000-powersmooth, but the largest factor of M73 does not. So the gcd will give M41 itself at the end of stage 1, whereas there are still non-trivial factors found for M73.

[kriesel]

Prime95 assumes (and so presumably also mprime would) that p<exponent> files are whatever primality test worktodo type (among PRP, PRPDC, LL, LLDC) is next in line. Then when a PRP partial run's save files are tried by an LL/DC worktodo entry or vice versa, they're declared to be bad. Admittedly such a case should not normally occur; shouldn't be running LL first test, or giant LLDC either, but the same overloading of file name issue can occur down to the DC wavefront or below.

[Apr 19 15:36:50] Worker starting
[Apr 19 15:36:50] Setting affinity to run worker on CPU core #1
[Apr 19 15:36:52] Setting affinity to run helper thread 1 on CPU core #2
[Apr 19 15:36:52] Setting affinity to run helper thread 2 on CPU core #3
[Apr 19 15:36:52] Setting affinity to run helper thread 3 on CPU core #4
[Apr 19 15:36:52] Starting Gerbicz error-checking PRP test of M1168999969 using AVX-512 FFT length 64M, Pass1=2K, Pass2=32K, clm=1, 4 threads
[Apr 19 15:36:52] Preallocating disk space for the proof interim residues file p1168999969.residues
[Apr 19 15:37:19] PRP proof using power=7x2 and 64-bit hash size.
[Apr 19 15:37:19] Proof requires 18.7GB of temporary disk space and uploading a 2338MB proof file.
[Apr 19 15:39:22] Stopping PRP test of M1168999969 at iteration 686 [0.00%]
[Apr 19 15:39:22] Worker stopped.

(switched worktodo entry order at this point, so LL of exponent is before prp of same exponent in worktodo.)

[Apr 19 15:40:49] Worker starting
[Apr 19 15:40:49] Setting affinity to run worker on CPU core #1
[Apr 19 15:40:51] Setting affinity to run helper thread 1 on CPU core #2
[Apr 19 15:40:51] Setting affinity to run helper thread 2 on CPU core #3
[Apr 19 15:40:51] Setting affinity to run helper thread 3 on CPU core #4
[Apr 19 15:40:51] Error reading intermediate file: p1168999969
[Apr 19 15:40:51] Renaming p1168999969 to p1168999969.bad1
[Apr 19 15:40:51] Trying backup intermediate file: p1168999969.bu
[Apr 19 15:40:51] Error reading intermediate file: p1168999969.bu
[Apr 19 15:40:51] Renaming p1168999969.bu to p1168999969.bad2
[Apr 19 15:40:51] All intermediate files bad.  Temporarily abandoning work unit.
[Apr 19 15:40:51] 

[Apr 19 15:41:41] Worker starting
[Apr 19 15:41:41] Setting affinity to run worker on CPU core #1
[Apr 19 15:41:42] Setting affinity to run helper thread 1 on CPU core #2
[Apr 19 15:41:42] Setting affinity to run helper thread 2 on CPU core #3
[Apr 19 15:41:42] Setting affinity to run helper thread 3 on CPU core #4
[Apr 19 15:41:43] Trying backup intermediate file: p1168999969.bad2
[Apr 19 15:41:43] Error reading intermediate file: p1168999969.bad2
[Apr 19 15:41:43] Trying backup intermediate file: p1168999969.bad1
[Apr 19 15:41:43] Error reading intermediate file: p1168999969.bad1
[Apr 19 15:41:43] Starting primality test of M1168999969 using AVX-512 FFT length 64M, Pass1=2K, Pass2=32K, clm=1, 4 threads
[Apr 19 15:43:56] Iteration: 1000 / 1168999969 [0.00%], ms/iter: 133.028, ETA: 1799d 21:16
[Apr 19 15:46:01] Iteration: 2000 / 1168999969 [0.00%], ms/iter: 125.050, ETA: 1691d 22:24
[Apr 19 15:48:02] Iteration: 3000 / 1168999969 [0.00%], ms/iter: 121.164, ETA: 1639d 08:30
[Apr 19 15:50:04] Iteration: 4000 / 1168999969 [0.00%], ms/iter: 121.630, ETA: 1645d 15:40
[Apr 19 15:52:05] Iteration: 5000 / 1168999969 [0.00%], ms/iter: 121.421, ETA: 1642d 19:53
[Apr 19 15:54:07] Iteration: 6000 / 1168999969 [0.00%], ms/iter: 121.493, ETA: 1643d 19:19
[Apr 19 15:55:49] Stopping primality test of M1168999969 at iteration 6805 [0.00%]
[Apr 19 15:55:49] Worker stopped.

[Prime95]

Originally Posted by ATH

Is the formula for GHz-Days based on the version number in the json result file?

No. P-1 can give outlandish CPU credit.

Much like TF on a GPU, the credit given is more than the wall clock time invested. TF has been that way for years. P-1 on small exponents with large B2 is even worse than GPU TF in terms of over-sized credits.

One could argue for new credit formulas. And/or argue for eliminating the combining work types in the top-500 page.

Originally Posted by kriesel

For probing what is the minimum allowed exponent, I tried running v30.8b14 P-1 on some very low exponents.
It allows running very low exponents.
It missed some known small factors.
See for example M41, M67, M71.

Originally Posted by kriesel

Prime95 assumes (and so presumably also mprime would) that p<exponent> files are whatever primality test worktodo type (among PRP, PRPDC, LL, LLDC) is next in line. Then when a PRP partial run's save files are tried by an LL/DC worktodo entry or vice versa, they're declared to be bad.

Don't do that. While it is a bug, not worth worrying about.

[ATH]

Originally Posted by Prime95

No. P-1 can give outlandish CPU credit.

Much like TF on a GPU, the credit given is more than the wall clock time invested. TF has been that way for years. P-1 on small exponents with large B2 is even worse than GPU TF in terms of over-sized credits.

One could argue for new credit formulas. And/or argue for eliminating the combining work types in the top-500 page.

Yeah I know, but I thought I read that the formula was improved a bit in the most recent builds of 30.8 ?

[Zhangrc]

Originally Posted by kriesel

For probing what is the minimum allowed exponent, I tried running v30.8b14 P-1 on some very low exponents.
It allows running very low exponents.
It missed some known small factors.
See for example M41, M67, M71.
For M73 and M79, factors are found in stage 1.

It's not a bug, instead, that's what P-1 is expected to yield.
take M67 for example:

2^67-1=
193707721 (k=2^2*3^3*5*2677)
*761838257287 (k=3^2*29*2551*8539)

So, you know, P-1 will find both factors, taking B1=50000.
However, the GCD step, yields M67 itself (which is a trivial factor), thus not providing any information about an nontrivial factor.
This circumstance inplies that you have used too LARGE bounds. Taking B1=30, B2=3000 and you can find 193707721 as a factor.
However that's impossible for Prime95.

As the case of M73:
The cofactor is 9361973132609 (k=2^5*19*105465631) which couldn't be found in stage 1, while the first two factors could.
So P-1 yields the product of fiist 2 factors, which is 1008839999.

[kriesel]

Originally Posted by Prime95

Don't do that. While it is a bug, not worth worrying about.

It's something I sometimes stumble into when doing limits testing or real-run benchmarking, and could also arise if files remain from an old LL completed run, that later gets a PRP with proof as DC by the same user. Giving the interim files file types, if that does not gore some supported OS compatibility, would both address some of that going forward, and make it clearer & easier for an end user when manually cleaning up file clutter after running for months or years in the same folder.
But as always, your code, your time, your call.