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

[Prime95]

Originally Posted by axn

Doesn't make sense. WIth PFactor, the bounds are determined by the number of tests saved. If it already has a factor, then why bother? Pminus1 has exactly what you need.

Originally Posted by James Heinrich

Sure it makes sense. It allows me to quickly and easily ask Prime95 to do a "good" or "great" or whatever kind of P-1 without me performing any kind of calculations.

axn is correct that optimizing bounds to maximize saving PRP/LL CPU time is different than optimizing bounds to find as many factors as possible in a unit of wall clock time.

James is correct that Pfactor provides a simple interface to pick some reasonable-ish bounds where "tests saved" can instead be viewed as "level of effort".

In truth, it is impossible to choose good P-1 bounds without considering how much P-1 has already been done. Even then, good bounds are still subjective -- choose to low and someone will have to redo it at a later date, choose too high and you'll not finish P-1 on all the exponents of interest.

That said, I am not philosophically against enhancing Pfactor with known factors.

[kriesel]

On prime95 v30.8b14, I recently had a proof file generation failure related to a repeating md5 error.
Is there a way to recover from this md5 error, & perhaps generate a lower power proof instead of none?
Stop and continue worker had no effect. The residues file is still there, and the app has moved on.
A search of the doc files for "md5" came up empty. Forum search (software subforum, prime95 poster, error keyword) didn't yield much either.

[May 18 17:11] Iteration: 109320000 / 109400569 [99.92%], ms/iter: 11.361, ETA: 00:15:15
[May 18 17:15] Iteration: 109340000 / 109400569 [99.94%], ms/iter: 11.572, ETA: 00:11:40
[May 18 17:18] Iteration: 109360000 / 109400569 [99.96%], ms/iter: 11.365, ETA: 00:07:41
[May 18 17:22] Iteration: 109380000 / 109400569 [99.98%], ms/iter: 11.348, ETA: 00:03:53
[May 18 17:26] Gerbicz error check passed at iteration 109399424.
[May 18 17:26] Iteration: 109400000 / 109400569 [99.99%], ms/iter: 11.389, ETA: 00:00:06
[May 18 17:26] Gerbicz error check passed at iteration 109400513.
[May 18 17:26] Gerbicz error check passed at iteration 109400562.
[May 18 17:27] Generating proof for M109400569.  Proof power = 9, Hash length = 64
[May 18 17:27] Root hash = C86D7AD04B90BDD8FCB4E48C9907D9156AAD51150977A27431DA6B542DED____
[May 18 17:27] MD5 error reading PRP proof interim residues file.
[May 18 17:27] Waiting 5 minutes to try proof generation again.
[May 18 17:27] Waiting five minutes before restarting.
[May 18 17:32] Root hash = C86D7AD04B90BDD8FCB4E48C9907D9156AAD51150977A27431DA6B542DED____
[May 18 17:32] MD5 error reading PRP proof interim residues file.
[May 18 17:32] Proof generation failed.
[May 18 17:32] M109400569 is not prime.  RES64: F8C22837950CF___. Wh4: 7EE818E2,37645848,00000000
[May 18 17:32] Setting affinity to run helper thread 1 on CPU core #2
[May 18 17:32] Setting affinity to run helper thread 3 on CPU core #4
[May 18 17:32] Setting affinity to run helper thread 2 on CPU core #3
[May 18 17:32] Starting Gerbicz error-checking PRP test of M109593851 using FMA3 FFT length 6M, Pass1=768, Pass2=8K, clm=2, 4 threads
[May 18 17:32] Preallocating disk space for the proof interim residues file \\ostrich\prp-proof-cache\p109593851.residues
[May 18 17:36] PRP proof using power=10 and 64-bit hash size.
[May 18 17:36] Proof requires 14.0GB of temporary disk space and uploading a 151MB proof file.
[May 18 17:40] Iteration: 20000 / 109593851 [0.01%], ms/iter: 11.292, ETA: 14d 07:42

[Prime95]

Originally Posted by kriesel

On prime95 v30.8b14, I recently had a proof file generation failure related to a repeating md5 error.
Is there a way to recover from this md5 error, & perhaps generate a lower power proof instead of none?

There is no way to recover.

If you have a save file from near the end of the run and the residues file, then send them to me and I can use that as a test case for automating new recovery code. There is a 50% chance dropping the proof power by 1 could generate a valid proof.

[kriesel]

Originally Posted by Prime95

If you have a save file from near the end of the run and the residues file, then send them to me and I can use that as a test case for automating new recovery code.

50% chance of power-1 success, so maybe 75% of power-2?
Unfortunately, the software (or user, but I don't recall doing that) appears to have already cleaned off everything but the residues file, perhaps SOP, before hitting the md5 error. Maybe defer PRP file cleanup until after the proof gen succeeds, deleting the px file and px.bu* with the residues file, in a future build.

C:\Users\User\Documents\prime95>dir p109400569*
 Volume in drive C has no label.
 Volume Serial Number is FCC5-4B7C

 Directory of C:\Users\User\Documents\prime95

05/18/2022  12:40 PM     7,001,669,632 p109400569.residues
                 1 File(s)  7,001,669,632 bytes

It appears to have been transitioned from 30.8b10 to 30.8b14 mid-run. (previous results.json.txt entry is build 10, this one build 14) Full results.json.txt entry with res2048; GEC error count 0, prime95 error counts 0.

Thanks for the quick clear response.

[Prime95]

Originally Posted by kriesel

50% chance of power-1 success, so maybe 75% of power-2.

Yes.

I think gpuowl automatically tries smaller proof powers. I've added that feature to my prime95 to-do list.

[kriesel]

Ok, backup/restore to the rescue perhaps:

 Directory of C:\Users\User\Documents\prime95

05/15/2022  06:46 PM        41,025,888 p109400569
05/15/2022  06:16 PM        41,025,888 p109400569.bu
05/15/2022  05:49 PM        27,350,812 p109400569.bu2
05/15/2022  02:36 PM        27,350,812 p109400569.bu3
05/15/2022  11:23 AM        27,350,812 p109400569.bu4
05/18/2022  12:40 PM     7,001,669,632 p109400569.residues
               6 File(s)  7,165,773,844 bytes

What would you like, and where? I'm guessing first and last files in the list above, p109400569, p109400569.residues. Obviously not by email, ~4x & ~1000x too big. It would take ~3 days to repeat to completion on the i7-4790 it ran on, & hopefully much less on an AVX512 CPU.

[Prime95]

Originally Posted by kriesel

What would you like, and where? I'm guessing first and last files in the list above, p109400569, p109400569.residues.

Yes, first and last files.

Do you have access to dropbox or equivalent that can handle a 7GB file?

[kriesel]

Originally Posted by Prime95

Do you have access to dropbox or equivalent that can handle a 7GB file?

Dropbox Basic, 2GB cap won't do. Google Drive free, 15GB is big enough. I'm rerunning it the 3 days after a local save to see if the MD5 error reoccurs or proof gen completes, and plan catching a save file closer to the end also. There's not much point in transferring & studying big test files that do not exhibit the issue repeatably. Check your email George for an access notification. Will update the restricted shared folder later. PM/email if you have any issues accessing it.

[Prime95]

Originally Posted by James Heinrich

Would it be hard to make Pfactor support known-factors list?

I can add this (probably will) but it is a semi-worthless feature.

Say you ask Pfactor to find profitable bounds where a factor saves 50 LL tests for exponents around 100K and 10M.
Well a 100K LL test is near instantaneous -- such bounds do not exist. At 10M such bounds do exist. Thus, "effort=50"'s meaning is dependent on the exponent being factored.

[James Heinrich]

Originally Posted by Prime95

I can add this (probably will) but it is a semi-worthless feature.

It wouldn't be worthless to me (but I never work on exponents <10M). And the whole figure-out-bounds-from-test-saved code is already there, it's just the "don't skip stage 2 when a known factor(s) is found in stage 1" part that I would like to see enabled for Pfactor.
Thanks George

[pepi37]

Prime95 v 30.8 build 15
Intel I5 9600K

Win 10

[May 21 13:38:17] Timing 640K all-complex FFT, 6 cores, 1 worker. [May 21 13:38:17] Error setting affinity to cpuset 0x00000020: No error
Average times: 0.58 ms. Total throughput: 1726.65 iter/sec.
[May 21 13:38:27] Timing 640K all-complex FFT, 6 cores, 2 workers. [May 21 13:38:28] Error setting affinity to cpuset 0x00000020: No error
Average times: 1.29, 1.33 ms. Total throughput: 1524.88 iter/sec.
[May 21 13:38:38] Timing 640K all-complex FFT, 6 cores, 3 workers. [May 21 13:38:38] Error setting affinity to cpuset 0x00000020: No error
Average times: 2.64, 2.54, 2.22 ms. Total throughput: 1223.11 iter/sec.


And with same settings benchmark on 400K dont even start