Prime95 version 29.6/29.7/29.8

[Prime95]

Originally Posted by SethTro

@George, @Prime95

One difficulty I'm having in my new cluster is managing ECM, P-1 restore files.

Is there a tool that reads all the backup/restore files in a directory and prints their status (e.g. PM1 complete to B1=<X>, B2=<Y> ...)?

If I write a small patch to add a new command (or cli flag) for this would you being willing to consider pulling it in a future release?

Thanks.

There is no such tool. Yes, I'd be willing to add useful code.

[paulotex]

Originally Posted by Prime95

I have confirmed that prime95 will not run on Catalina -- thanks Apple! The error message is most uninformative.

Zip file build error. Try this: https://mersenne.org/ftp_root/gimps/...MacOSX.zip.zip

Yes, the issue is the executable is not marked as such. After unzipping, in the Terminal, go to the folder where Prime95 resides and do
chmod a+x ./Prime95.app/Contents/MacOS/Prime95

That should fix it.

Remember you have to right-click+Open once, since the app is not signed.

[WarthogARJ]

Hi,
I'm new, sorry if this question is answered elsewhere: I have serched.
Prime95 is failing to run on my HighSiera.
I've never had this error msg: "The application “Prime95.app” can’t be opened."

I can run the command line version, and I seem to be doing the GIMP calls.

But Prime95 on the GUI doesn't seem to run.

Is there an archive of earlier versions?

I have downloaded the source code, and will have a "bash" (soon, bad pun) at compiling it.
I suspect this is my own fault, but I'm not sure how to address it.

I want to use Prime95 to benchmark my system.
As well as work towards the GIMP goals, but I don't need the GUI for that.

Thanks for any help.
Alan

[Prime95]

Originally Posted by WarthogARJ

Prime95 is failing to run on my HighSiera.
I've never had this error msg: "The application “Prime95.app” can’t be opened."

I can run the command line version, and I seem to be doing the GIMP calls.

But Prime95 on the GUI doesn't seem to run.

Is there an archive of earlier versions?

Go to ftp://mersenne.org/gimps You should be able to find a previous version that works.

[kriesel]

Please fix all 9 identified issues.

System condor, dual Xeon X5650, Windows 7, prime95 v29.8b6 PrimeNet connected, set to do PRPDC on all four 3-core workers

worktodo.txt:
[Worker #1]
PRPDC=(aid redacted),1,2,81912167,-1,75,0,3,1
(worktodo entry is correct)

prime95 status output:
[Worker thread #1]
M81912167,PRP,Sat Feb 08 15:20 2020
(prime95 status output is incorrect, 1)

prime.log on the client:
[Mon Jan 06 23:30:08 2020 - ver 29.8]
Getting assignment from server
PrimeNet success code with additional info:
Server assigned PRP work.
Got assignment (aid): PRP M81912167
(prime95 logging is incorrect twice, 2 & 3)

Prime95 worker window title says PRP not PRP DC
(prime95 window title is inaccurate, 4)

https://www.mersenne.org/report_expo...1912167&full=1
claims it was assigned to me as a first test PRP, not "PRPDC", although there is already a first test PRP result reported by another user on 2018-11-05
(PrimeNet exponent status lookup is incorrect and inconsistent, 5)

https://www.mersenne.org/workload/ claims 819121677 is a first test PRP, Cat 0, expiring in 23 days, with 25 days left to go.
It's actually a PRP DC, Cat 4, which should have up to 360 days allowed for ETA before expiration.
(workload listing is incorrect 3 ways, 6, 7, 8)

Double checking such a large exponent should be, and should be indicated as, a cat 4 exponent allowed up to 360 days to complete: https://www.mersenne.org/thresholds/
(likely outcome of mistreating a cat 4 PRPDC as a cat 0 PRP is incorrect too-early expiration of the assignment, 9)

As a workaround to avoid early expiration, I've reconfigured this instance from 4 workers to 2 workers to reduce latency, and manually edited the worktodo to queue up the falsely-claimed cat0 PRPs on this system (81912167 PRPDC and 81889037 PRPDC) as first assignment in each remaining worker. See also https://www.mersenne.org/report_expo...1889037&full=1, which was earlier reported as showing this problem also. See https://www.mersenneforum.org/showthread.php?t=25066 and an additional report linked there made months earlier.

Please fix the client software and server software to correctly handle PRPDC in the general case. Soon would be good. This system's prime95 will be doing nothing other than PRPDC for a while. To produce meaningful PRP error rate statistics, such as patrik graphs annually, GIMPS needs many many more than the ~1584 PRPDC results it has so far at p>75M. https://www.mersenneforum.org/showthread.php?t=10377&page=10

(end)

[kriesel]

What is the point of automatically doing apparently identical benchmark runs more than daily? Here are just the last two iterations, of a series of 9 so far, that began early Jan 2, of apparently identical sets of benchmarks at precisely 21 hour intervals of an otherwise uninterrupted prime95 run:

[Wed Jan 08 14:27:54 2020]
 FFTlen=4480K, Type=3, Arch=3, Pass1=896, Pass2=5120, clm=4 (12 cores, 4 workers): 33.22, 37.66, 32.66, 38.88 ms.  Throughput: 112.99 iter/sec.
FFTlen=4480K, Type=3, Arch=2, Pass1=896, Pass2=5120, clm=4 (12 cores, 4 workers): 33.79, 33.60, 32.80, 32.71 ms.  Throughput: 120.42 iter/sec.
FFTlen=4480K, Type=2, Arch=3, Pass1=896, Pass2=5120, clm=4 (12 cores, 4 workers): 35.83, 35.65, 34.26, 34.29 ms.  Throughput: 114.31 iter/sec.
FFTlen=4480K, Type=2, Arch=2, Pass1=896, Pass2=5120, clm=4 (12 cores, 4 workers): 34.12, 33.42, 32.94, 32.93 ms.  Throughput: 119.96 iter/sec.
FFTlen=4608K, Type=3, Arch=3, Pass1=512, Pass2=9216, clm=4 (12 cores, 4 workers): 43.83, 43.42, 43.93, 43.28 ms.  Throughput: 91.72 iter/sec.
FFTlen=4608K, Type=3, Arch=3, Pass1=1024, Pass2=4608, clm=4 (12 cores, 4 workers): 36.05, 35.96, 34.52, 35.02 ms.  Throughput: 113.07 iter/sec.
FFTlen=4608K, Type=3, Arch=2, Pass1=1024, Pass2=4608, clm=4 (12 cores, 4 workers): 38.58, 34.46, 33.22, 33.52 ms.  Throughput: 114.87 iter/sec.
FFTlen=4608K, Type=2, Arch=3, Pass1=512, Pass2=9216, clm=4 (12 cores, 4 workers): 45.09, 44.84, 44.87, 44.28 ms.  Throughput: 89.35 iter/sec.
FFTlen=4608K, Type=2, Arch=3, Pass1=1024, Pass2=4608, clm=4 (12 cores, 4 workers): 37.74, 37.16, 36.28, 36.29 ms.  Throughput: 108.53 iter/sec.
FFTlen=4608K, Type=2, Arch=2, Pass1=1024, Pass2=4608, clm=4 (12 cores, 4 workers): 36.37, 36.40, 35.16, 34.62 ms.  Throughput: 112.30 iter/sec.

[Thu Jan 09 11:27:53 2020]
FFTlen=4480K, Type=3, Arch=3, Pass1=896, Pass2=5120, clm=4 (12 cores, 4 workers): 33.05, 32.13, 32.17, 31.75 ms.  Throughput: 123.96 iter/sec.
FFTlen=4480K, Type=3, Arch=2, Pass1=896, Pass2=5120, clm=4 (12 cores, 4 workers): 32.18, 33.16, 33.08, 31.60 ms.  Throughput: 123.11 iter/sec.
FFTlen=4480K, Type=2, Arch=3, Pass1=896, Pass2=5120, clm=4 (12 cores, 4 workers): 35.99, 35.23, 33.44, 33.77 ms.  Throughput: 115.68 iter/sec.
FFTlen=4480K, Type=2, Arch=2, Pass1=896, Pass2=5120, clm=4 (12 cores, 4 workers): 33.51, 34.05, 33.47, 31.96 ms.  Throughput: 120.38 iter/sec.
FFTlen=4608K, Type=3, Arch=3, Pass1=512, Pass2=9216, clm=4 (12 cores, 4 workers): 44.14, 43.69, 43.60, 43.43 ms.  Throughput: 91.50 iter/sec.
FFTlen=4608K, Type=3, Arch=3, Pass1=1024, Pass2=4608, clm=4 (12 cores, 4 workers): 35.81, 35.69, 35.26, 34.72 ms.  Throughput: 113.11 iter/sec.
FFTlen=4608K, Type=3, Arch=2, Pass1=1024, Pass2=4608, clm=4 (12 cores, 4 workers): 37.18, 36.03, 33.16, 33.34 ms.  Throughput: 114.80 iter/sec.
FFTlen=4608K, Type=2, Arch=3, Pass1=512, Pass2=9216, clm=4 (12 cores, 4 workers): 44.47, 43.93, 44.37, 44.08 ms.  Throughput: 90.47 iter/sec.
FFTlen=4608K, Type=2, Arch=3, Pass1=1024, Pass2=4608, clm=4 (12 cores, 4 workers): 40.35, 40.15, 41.60, 39.78 ms.  Throughput: 98.87 iter/sec.
FFTlen=4608K, Type=2, Arch=2, Pass1=1024, Pass2=4608, clm=4 (12 cores, 4 workers): 34.76, 34.09, 34.79, 34.51 ms.  Throughput: 115.82 iter/sec.

[Prime95]

Prime95 looks ahead in your worktodo.txt file to see what FFT sizes you will soon be running. It then does 10 automatic benchmarks 21 hours apart. Ten benchmarks are done so that the worst timings can be thrown out in case other programs happen to be running during the benchmark.

There are two INI settings you can tweak:

autobench_days_of_work = (double) IniGetInt (INI_FILE, "AutoBenchDaysOfWork", 7);
autobench_num_benchmarks = IniGetInt (INI_FILE, "AutoBenchNumBenchmarks", 10);

[kriesel]

Originally Posted by Prime95

Prime95 looks ahead in your worktodo.txt file to see what FFT sizes you will soon be running. It then does 10 automatic benchmarks 21 hours apart. Ten benchmarks are done so that the worst timings can be thrown out in case other programs happen to be running during the benchmark.

There are two INI settings you can tweak:

autobench_days_of_work = (double) IniGetInt (INI_FILE, "AutoBenchDaysOfWork", 7);
autobench_num_benchmarks = IniGetInt (INI_FILE, "AutoBenchNumBenchmarks", 10);

Thanks for the reply on benchmarking frequency.
Hmm, looks like candidates for not_even_undoc.txt. (Not in readme, whatsnew, or undoc)

Would that be something like this in prime.txt?

AutoBenchDaysOfWork=3
AutoBenchNumBenchmarks=5

[Prime95]

Originally Posted by kriesel

T
Would that be something like this in prime.txt?

AutoBenchDaysOfWork=3
AutoBenchNumBenchmarks=5

Yes. That peeks ahead 3 days in worktodo and runs 5 benchmarks of each FFT size.

[kriesel]

Originally Posted by Prime95

Yes. That peeks ahead 3 days in worktodo and runs 5 benchmarks of each FFT size.

Thanks for the confirmation.
What are the prospects for addressing the concerns listed in https://www.mersenneforum.org/showpo...postcount=445?

[James Heinrich]

I just noticed that if some assignments are added via worktodo.add they're pulled into worktodo.txt (after a short time) but it does not trigger the code that checks for, and fetches if necessary, assignment IDs for the new work. If I quit Prime95 and restart it then it correctly notices the new work does not have AID (nor N/A) and gets assignments from PrimeNet. Should it not do this immediately upon sucking in new work via worktodo.add ?