Prime95 30.7
 

Prime95 version 30.7 build 9 is available.

P-1/P+1/ECM users should consider upgrading to help with testing. Intel Alder Lake users definitely need to upgrade to iron out any issues. Win11 users should also consider upgrading to test for affinity issues. First time PRP users can consider upgrading for the P-1 stage 2 speed boost.

WARNING: If you upgrade in the middle of P-1/P+1/ECM stage 2, then all your stage 2 work will be lost -- stage 2 starts from scratch.

From whatsnew.txt:

[CODE]1) Better prime pairing in stage 2 of ECM/P-1/P+1. This usually results in slightly better
stage 2 timings or less memory used. Save file formats changed - upgrading to 30.7 while
ECM/P-1/P+1 work is in stage 2 will result in stage 2 being restarted from scratch.
2) P-1 converted to use P+1 style stage 2. From the users perpective there is no difference.
Internally a modular inverse is required at stage 2 init, but there is one multiplication
saved for every D-block processed. For all common P-1 cases, this is a little faster.
3) ECM/P-1/P+1 no longer use a bit map for prime pairs. Instead a compressed pairing map is
created to save memory. For large B2 values this also results in fewer calls to generate
pairing maps. It also makes stage 2 save files smaller.
4) Some minor changes in AVX-512 FFT crossovers. ECM/P-1/P+1 all changed to rollback to the
last save file and switch to a larger FFT size should an excessive roundoff error be
encountered.
5) Support for asymmetric processor architectures such as Intel's Alder Lake.
6) Torture test dialog now asks for number of cores to test along with a "Use hyperthreading"
checkbox. Previously, the dialog box asked for total number of torture threads to execute.
7) Versions 30.4/30.5/30.6 were underestimating the cost of P-1 stage 2 relative to P-1 stage 1.
Expect this version to use lower stage 2 bounds in P-1.
[/CODE]

Download links:
Windows 64-bit: [URL]https://mersenne.org/ftp_root/gimps/p95v307b9.win64.zip[/URL]
Linux 64-bit: [URL]https://mersenne.org/ftp_root/gimps/p95v307b9.linux64.tar.gz[/URL]
FreeBSD 64-bit: [URL]https://mersenne.org/ftp_root/gimps/p95v307b9.FreeBSD11-64.tar.gz[/URL]
Windows 32-bit: [URL]https://mersenne.org/ftp_root/gimps/p95v307b9.win32.zip[/URL]
Linux 32-bit: [URL]https://mersenne.org/ftp_root/gimps/p95v307b9.linux32.tar.gz[/URL]
Windows 64-bit Service: [URL]https://mersenne.org/ftp_root/gimps/p95v307b9.win64.service.zip[/URL]
Windows 32-bit Service: [URL]https://mersenne.org/ftp_root/gimps/p95v307b9.win32.service.zip[/URL]
Source: [URL]https://mersenne.org/ftp_root/gimps/p95v307b9.source.zip[/URL]
Please report any bugs you may find by email or posting in this thread.

1) Benchmarking broken. Fixed in build 2.
2) Most non-Mersenne FFTs broken. Fixed in build 3.
3) Hyperthreaded torture tests not setting affinity properly for small FFTs. Fixed in build 4.
4) Hyperthreaded in-place torture tests crash for small FFTs. Fixed in build 4.
5) Semi-obscure ECM crash. If an ECM curve needed modular inverses in stage 2 and a subsequent curve needed none (more memory available), then a crash occurred. Fixed in build 4.
6) Assume CERTs will complete before all other work types in computing estimated completion dates. Fixed in build 5.
7) A low-memory situation during stage 2 init of ECM could lead to a crash writing a save file. Fixed in build 5.
8) During stage 2 init, checking for a restart due to a reduction in available memory was infrequent. Fixed in build 5 - might reduce chance of an out-of-memory event.
9) Options/Benchmark tries to run a hyperthreaded benchmark on non-hyperthreaded CPUs. Fixed in build 6.
10) Another possible crash bug in stage 2 init when memory settings change. Fixed in build 6.
11) ECM sometimes generated excessive roundoff error, usually at start up which then forced using a larger FFT size than necessary. Fixed in build 6.
12) On stage 2 restart due to more memory now available, stage 2 % complete was erroneously reported to be 100%. Fixed in build 8.
13) On stage 2 restart due to less memory being available, stage 2 might restart from scratch. Fixed in build 8.
14) Rare radix conversion excessive roundoff error affecting PRP of non-base-2 numbers. Fixed in build 8.
15) Trial factoring crashes. Fixed in build 9.

How you can help:

1) Help fine-tune the P-1 stage 1 vs stage 2 cost function. In preferences, set output iterations low -- like 10000. Report the typical P-1 stage 1 timings vs. typical stage 2 timings as well as minimal architectural info. Example for one of my machines:
[code]Skylake CPU. FMA FFT, 106M exponent: stage 1 = 83.9 sec, stage 2 = 129 sec.[/code]

The optimal P-1 bounds depends on the stage 2 to stage 1 timing ratio. I'm seeing stage 2 anywhere from 30-50% slower.

2) Alder Lake and Win11 -- verify CPU affinities make sense and are working as expected. Add to prime.txt:
[code]AffinityVerbosity=2
AffinityVerbosityTorture=2
AffinityVerbosityTime=2
AffinityVerbosityBench=2[/code]
Run regular work, torture test, benchmarks, and even advanced/time. Prime95 should prefer assigning work to the performance cores.

Make sure the cpu affinities output to each worker window make sense. Bring up task manager to verify that the work is being done on the cores prime95 assigned each worker.

Try running on a subset of cores. For example, 1 worker running on 2 hyperthreaded cores -- do the 4 threads in fact run on only 2 performance cores according to task manager?

I invite any adventurous Alder Lake owner to try it on both Win11 and [URL="https://www.howtogeek.com/744328/how-to-install-the-windows-subsystem-for-linux-on-windows-11/"]WSL[/URL] Ubuntu. And native Linux too if you've got dual-boot in place.

[QUOTE=kriesel;589238]And native Linux too if you've got dual-boot in place.[/QUOTE]

Are those who have Linux as primary boot welcome as well? :smile:

[QUOTE=chalsall;589239]Are those who have Linux as primary boot welcome as well? :smile:[/QUOTE]Sure. There's a little advantage to Win, WSL, and Lin on identical hardware for a 3-way comparison on performance and proper core handling, but I don't think there's a capacity limit at this party. IIRC Windows requires primary partition, Linux doesn't.

[QUOTE=kriesel;589242]Windows requires primary partition, Linux doesn't.[/QUOTE]

You support my argument, sir...

Micro$oft doesn't "play well with others". Some have learnt to stop playing the game with MicroCrap, and have gone "all in" with Linux as the primary OS.

Particularly, being tricked into thinking running virtual environments under WinBlows 10 (now being forced to WinCrows 11) simulating Linux through some kind of virtual shell is somehow doing the same thing as running a "full-up Linux stack" has been empirically shown to be little more than "Snake Oil".

Sincerely... No issues (between the two of us). :chalsall:

Excuse me, but where's the source code?

[QUOTE=chalsall;589243]You support my argument, sir...

Micro$oft doesn't "play well with others".

Particularly, being tricked into thinking running virtual environments...[/QUOTE]Hmm, you seem a bit zealous. This thread is about a new release of prime95 / mprime. It isn't the place for refighting the favorite-OS wars. Or whether single-boot, multi-boot, or VM is the one true way, or any other techno-religious-fervor conflict. They're all just tools. Don't blame the hammer for a lack of screwdriver-ness. Or do, but in the proper threads[QUOTE=chalsall;589222]I'm giving Ubuntu one more chance.[/QUOTE]Heck, run Fedora VMs of various versions on Fedora host OS if you like, and let us know how V30.7 behaves and performs on VM vs host. Or find issues with V30.7 on Fedora host OS.

WSL or VM are tools for having multiple environments available on the same hardware at the same time.

I noticed that for ECM on small exponents, stage 2 init now takes a lot longer than before

[code]
version 30.6b4

[Worker #4 Oct 3 11:59] ECM on [B]M20393[/B]: curve #264 with s=652720576976964, B1=3000000, B2=TBD
[Worker #4 Oct 3 12:02] Stage 1 complete. 77076114 transforms, 1 modular inverses. Time: 191.655 sec.
[Worker #4 Oct 3 12:02] Available memory is 11000MB.
[Worker #4 Oct 3 12:02] Optimal [B]B2 is 176*B1 = 528000000[/B].
[Worker #4 Oct 3 12:03] D: 6930, relative primes: 21344, stage 2 primes: 27534330, pair%=96.81
[Worker #4 Oct 3 12:03] Stage 2 uses [B]929MB of memory[/B], 2 FFTs per prime pair, 3-mult modinv pooling, pool size 35165.
[Worker #4 Oct 3 12:03] Stage 2 init complete. 560562 transforms, 1 modular inverses. Time: [B]8.126 sec[/B].
[Worker #4 Oct 3 12:04] Stage 2 complete. 29840810 transforms, 2 modular inverses. Time: [B]99.321 sec[/B].
[Worker #4 Oct 3 12:04] Stage 2 GCD complete. Time: 0.001 sec.

version 30.7b1
[Worker #4 Oct 3 15:17] ECM on M20393: curve #301 with s=7945291737592001, B1=3000000, B2=TBD
[Worker #4 Oct 3 15:20] Stage 1 complete. 77076114 transforms, 1 modular inverses. Total time: 179.730 sec.
[Worker #4 Oct 3 15:20] Available memory is 11000MB.
[Worker #4 Oct 3 15:20] Optimal [B]B2 is 100*B1 = 300000000[/B].
[Worker #4 Oct 3 15:21] D: 2772, relative primes: 2664, stage 2 primes: 16035509, pair%=86.48
[Worker #4 Oct 3 15:21] Stage 2 uses [B]75MB of memory[/B], 2 FFTs per prime pair, 3-mult modinv pooling, pool size 2706.
[Worker #4 Oct 3 15:21] Stage 2 init complete. 109141 transforms, 2 modular inverses. Time: [B]31.491 sec[/B].
[Worker #4 Oct 3 15:22] Stage 2 complete. 19634829 transforms, 31 modular inverses. Total time: [B]52.660 sec.[/B]
[Worker #4 Oct 3 15:22] Stage 2 GCD complete. Time: 0.001 sec.
[/code][code]
version 30.6b4
[Worker #3 Oct 3 11:57] ECM on [B]M307409[/B]: curve #139 with s=96291502140021, B1=250000, B2=TBD
[Worker #3 Oct 3 12:02] Stage 1 complete. 6387044 transforms, 1 modular inverses. Time: 316.008 sec.
[Worker #3 Oct 3 12:02] Available memory is 11000MB.
[Worker #3 Oct 3 12:02] Optimal [B]B2 is 154*B1 = 38500000[/B].
[Worker #3 Oct 3 12:02] D: 4620, relative primes: 6955, stage 2 primes: 2325683, pair%=92.69
[Worker #3 Oct 3 12:02] Stage 2 uses [B]2651MB of memory[/B], 2 FFTs per prime pair, 3-mult modinv pooling, pool size 7693.
[Worker #3 Oct 3 12:02] Stage 2 init complete. 182767 transforms, 1 modular inverses. Time: [B]10.380 sec[/B].
[Worker #3 Oct 3 12:05] Stage 2 complete. 2656544 transforms, 1 modular inverses. Time: [B]137.281 sec[/B].
[Worker #3 Oct 3 12:05] Stage 2 GCD complete. Time: 0.030 sec.


version 30.7b1
[Worker #3 Oct 3 15:14] ECM on M307409: curve #161 with s=8109473831276158, B1=250000, B2=TBD
[Worker #3 Oct 3 15:20] Stage 1 complete. 6387044 transforms, 1 modular inverses. Total time: 326.664 sec.
[Worker #3 Oct 3 15:20] Available memory is 11000MB.
[Worker #3 Oct 3 15:20] Optimal [B]B2 is 147*B1 = 36750000[/B].
[Worker #3 Oct 3 15:20] D: 2772, relative primes: 3600, stage 2 primes: 2225256, pair%=97.96
[Worker #3 Oct 3 15:20] Stage 2 uses [B]1056MB of memory[/B], 2 FFTs per prime pair, 3-mult modinv pooling, pool size 2652.
[Worker #3 Oct 3 15:20] Stage 2 init complete. 125837 transforms, 2 modular inverses. [B]Time: 15.606 sec[/B].
[Worker #3 Oct 3 15:22] Stage 2 complete. 2412103 transforms, 3 modular inverses. [B]Total time: 132.420 sec[/B].
[Worker #3 Oct 3 15:22] Stage 2 GCD complete. Time: 0.032 sec.


[/code]The reduced memory usage is really impressive, though! It saves >90% on M20,393 and 60% on M307,409.

This is a Zen 2 Ryzen 3950X with one worker per CPU thread at 2.8GHz with Linux.

Observation: Stage 2 progress % splits start out bigger (relative to 30.6) and progressively becomes smaller towards the end. Makes ETA calculations tricky.

[CODE][Work thread Oct 3 05:34] Conversion of stage 1 result complete. 5 transforms, 1 modular inverse. Time: 1.704 sec.
[Work thread Oct 3 05:34] D: 1848, relative primes: 4800, stage 2 primes: 20796549, pair%=99.71
[Work thread Oct 3 05:34] Using 10995MB of memory.
[Work thread Oct 3 05:35] Stage 2 init complete. 9481 transforms. Time: 55.307 sec.
[Work thread Oct 3 05:48] M5266619 stage 2 is 5.43% complete. Time: 838.973 sec.
[Work thread Oct 3 06:03] M5266619 stage 2 is 10.95% complete. Time: 840.818 sec.
[Work thread Oct 3 06:17] M5266619 stage 2 is 16.51% complete. Time: 845.246 sec.
[Work thread Oct 3 06:31] M5266619 stage 2 is 22.10% complete. Time: 841.122 sec.
[Work thread Oct 3 06:45] M5266619 stage 2 is 26.96% complete. Time: 841.132 sec.
[Work thread Oct 3 06:59] M5266619 stage 2 is 31.68% complete. Time: 841.467 sec.
[Work thread Oct 3 07:13] M5266619 stage 2 is 36.42% complete. Time: 842.283 sec.
[Work thread Oct 3 07:27] M5266619 stage 2 is 41.18% complete. Time: 842.197 sec.
[Work thread Oct 3 07:41] M5266619 stage 2 is 45.96% complete. Time: 842.407 sec.
[Work thread Oct 3 07:55] M5266619 stage 2 is 50.75% complete. Time: 841.396 sec.
[Work thread Oct 3 08:09] M5266619 stage 2 is 55.56% complete. Time: 843.942 sec.
[Work thread Oct 3 08:23] M5266619 stage 2 is 60.38% complete. Time: 843.597 sec.
[Work thread Oct 3 08:37] M5266619 stage 2 is 65.21% complete. Time: 842.223 sec.
[Work thread Oct 3 08:51] M5266619 stage 2 is 70.06% complete. Time: 842.269 sec.
[Work thread Oct 3 09:05] M5266619 stage 2 is 74.67% complete. Time: 841.707 sec.
[Work thread Oct 3 09:19] M5266619 stage 2 is 79.22% complete. Time: 842.902 sec.
[Work thread Oct 3 09:33] M5266619 stage 2 is 83.56% complete. Time: 842.358 sec.
[Work thread Oct 3 09:47] M5266619 stage 2 is 87.78% complete. Time: 842.067 sec.
[Work thread Oct 3 10:01] M5266619 stage 2 is 91.74% complete. Time: 842.497 sec.
[Work thread Oct 3 10:15] M5266619 stage 2 is 95.51% complete. Time: 843.865 sec.
[Work thread Oct 3 10:29] M5266619 stage 2 is 99.25% complete. Time: 844.053 sec.
[Work thread Oct 3 10:32] M5266619 stage 2 complete. 21204894 transforms. Total time: 17866.727 sec.[/CODE]

It got stuck running benchmark this morning at 5am. "Pausing worker to run the needed benchmarks". It was doing P+1 on 31M (1600K FMA3) with 1 worker 8 cores. Prime95 30.7b1 on Windows 10.

Now 11 hours later when I checked the computer, Prime95 was still using 1 core for something in Task Manager but never ran any benchmarks and no P+1 since 5am. It could not be shut down, had to kill the process in Task Manager.

The file "results.bench.txt" was not updated, I'll see if it happens again tomorrow.

Could it be because it is an old long "results.bench.txt" file at 383 KB going back to April 2019 ?

[QUOTE=ATH;589289]It got stuck running benchmark this morning at 5am.[/QUOTE]

A line of code mysteriously disappeared. I'll upload fixed executables today.

I have this in my screen output for every result:
[CODE]
[Work thread Oct 3 14:23] M9141287 stage 2 complete. 9147452 transforms. Total time: 2390.486 sec.
[Work thread Oct 3 14:23] Stage 2 GCD complete. Time: 1.301 sec.
[Work thread Oct 3 14:23] M9141287 completed P-1, B1=2000000, B2=162000000, Wi8: E5571098
[Comm thread Oct 3 14:23] Sending result to server: UID: Tha/Z170-m30.7, M9141287 completed P-1, B1=2000000, B2=162000000, Wi8: E5571098
[Comm thread Oct 3 14:23]
[Comm thread Oct 3 14:23] URL: http://v5.mersenne.org/v5server/?v=0.95&px=GIMPS&t=ar&g=df88abe73833aa676d31a0bf32b0d492&k=0&m={"status":"NF",+"exponent":9141287,+"worktype":"P-1",+"b1":2000000,+"b2":162000000,+"fft-length":491520,+"security-code":"E5571098",+"program":{"name":"Prime95",+"version":"30.7",+"build":1,+"port":8},+"timestamp":"2021-10-03+12:23:14",+"user":"Tha",+"computer":"Z170-m30.7"}%0A&r=5&d=1&A=1&b=2&n=9141287&c=-1&B1=2000000&B2=162000000&fftlen=491520&ss=59330&sh=AE771A6DD8A50DE4365D285900BB3A12
[Work thread Oct 3 14:23]
[Work thread Oct 3 14:23] P-1 on M9141317 with B1=2000000, B2=TBD

[/CODE]

[QUOTE=Prime95;589305]A line of code mysteriously disappeared.[/QUOTE]

Actually, not a mystery. My text editor begins most commands with ^X (e.g. save file is ^X^S). MS Visual Studio treats ^X as delete the current line. If you then build an executable, Visual Studio saves the file.

I usually catch these fat fingered moments, but this one slipped through undetected. I've taken this moment to change Visual Studio to not map ^X to any commands.

[QUOTE=tha;589313]I have this in my screen output for every result:[/QUOTE]


This behavior did not change to my knowledge. Either don't merge the comm and worker window output or go to Test/Primenet/Connection and turn off "Output debug info to prime.log" (a.k.a. Debug=0 in the [PrimeNet] section of prime.txt).

No CERTS
 

I haven't received any CERTS since updating. I have the box "Get occasional proof certification work" checked. Maybe just a coincidence but I usually get several CERTs a day.

Build 2 with the benchmark fix now ready.

[QUOTE=Prime95;589236]In preferences, set output iterations low -- like 10000.[/QUOTE]

Before running the test, I forgot to change that value (it was 250000). I hope that's okay either way?

CPU: AMD 3800X (Zen 2)
1 Worker, 8 Threads
106M exponent, 5760K FFT
Stage 1: 1100-1120 seconds per output
Stage 2: 1965-1985 seconds per output

I probably should mention that I have Brent-Suyama activated in prime.txt (largely because of personal preference) and that I have doubled tests_saved, is it still helpful or should I run one exponent with default settings?

[QUOTE=Chuck;589332]I haven't received any CERTS since updating. I have the box "Get occasional proof certification work" checked. Maybe just a coincidence but I usually get several CERTs a day.[/QUOTE]

After updating to build 2 I am receiving CERTS again.

[QUOTE=kruoli;589405]Before running the test, I forgot to change that value (it was 250000). I hope that's okay either way?

I probably should mention that I have Brent-Suyama activated in prime.txt (largely because of personal preference) and that I have doubled tests_saved, is it still helpful or should I run one exponent with default settings?[/QUOTE]

That's OK, thanks for the data.

Brent-Suyama is no longer supported. An artifact of the P+1-style stage 2.

[QUOTE=Chuck;589424]After updating to build 2 I am receiving CERTS again.[/QUOTE]

Coincidence.

Win 10
I5-9600K stock frequency



With Prime95 30.7 b2 I have this problem
[QUOTE]

[Oct 4 23:00:26] Waiting 15 seconds to stagger worker starts.
[Oct 4 23:00:42] Worker starting
[Oct 4 23:00:42] Setting affinity to run worker on CPU core #5
[Oct 4 23:00:42] Starting Gerbicz error-checking PRP test of 49923*2^1700000+1 using all-complex FMA3 FFT length 144K, Pass1=768, Pass2=192, clm=2
[Oct 4 23:00:44] ERROR: Comparing Gerbicz checksum values failed. Rolling back to iteration 15.
[Oct 4 23:00:44] Continuing from last save file.
[Oct 4 23:00:44] Resuming Gerbicz error-checking PRP test of 49923*2^1700000+1 using all-complex FMA3 FFT length 144K, Pass1=768, Pass2=192, clm=2
[Oct 4 23:00:44] Iteration: 16 / 1700015 [0.00%].
[Oct 4 23:00:44] Hardware errors have occurred during the test!
[Oct 4 23:00:44] 1 Gerbicz/double-check error.
[Oct 4 23:00:44] Confidence in final result is excellent.
[Oct 4 23:00:45] ERROR: Comparing Gerbicz checksum values failed. Rolling back to iteration 15.
[Oct 4 23:00:45] Continuing from last save file.
[Oct 4 23:00:45] Resuming Gerbicz error-checking PRP test of 49923*2^1700000+1 using all-complex FMA3 FFT length 144K, Pass1=768, Pass2=192, clm=2
[Oct 4 23:00:45] Iteration: 16 / 1700015 [0.00%].
[Oct 4 23:00:45] [I][B][COLOR=Blue]Hardware errors have occurred during the test![/COLOR][/B][/I]
[Oct 4 23:00:45] 2 Gerbicz/double-check errors.
[Oct 4 23:00:45][COLOR=Red][B] Confidence in final result is excellent.[/B][/COLOR]
[/QUOTE]On the other side, with Prime95 30.6 build 4 on same configuration


[QUOTE][Oct 4 23:03:56] Waiting 15 seconds to stagger worker starts.
[Oct 4 23:04:11] Worker starting
[Oct 4 23:04:11] Setting affinity to run worker on CPU core #5
[Oct 4 23:04:11] Starting Gerbicz error-checking PRP test of 49923*2^1700000+1 using all-complex FMA3 FFT length 144K, Pass1=768, Pass2=192, clm=2
[Oct 4 23:04:12] Gerbicz error check passed at iteration 976.
[Oct 4 23:04:12] Gerbicz error check passed at iteration 2000.
[Oct 4 23:04:13] Gerbicz error check passed at iteration 3089.
[Oct 4 23:04:14] Gerbicz error check passed at iteration 4178.
[Oct 4 23:04:15] Gerbicz error check passed at iteration 5334.
[Oct 4 23:04:15] Gerbicz error check passed at iteration 6559.

[/QUOTE]

8600K Coffee Lake CPU, 1 worker, 6 threads. FMA3 FFT (6400K), 117M exponent: stage 1 = 72.8 sec, stage 2 = 116.6 sec

Don't know yet if this is reproducable, I will try later. But mprime hangs on timing FFT's. I pressed ^C at 08:37 as shown in the output. I closed the terminal application at 08:40 which made the CPU usage drop from 13% to 2%.


[CODE]
[Work thread Oct 5 05:12] Stage 2 GCD complete. Time: 1.310 sec.
[Work thread Oct 5 05:12] M9201337 completed P-1, B1=2000000, B2=162000000, Wi8: E7C912E0
[Comm thread Oct 5 05:12] Sending result to server: UID: Tha/Z170-m30.7, M9201337 completed P-1, B1=2000000, B2=162000000, Wi8: E7C912E0
[Comm thread Oct 5 05:12]
[Work thread Oct 5 05:12]
[Work thread Oct 5 05:12] P-1 on M9203287 with B1=2000000, B2=TBD
[Work thread Oct 5 05:12] Setting affinity to run helper thread 1 on CPU core #2
[Work thread Oct 5 05:12] Using FMA3 FFT length 480K, Pass1=384, Pass2=1280, clm=4, 4 threads
[Work thread Oct 5 05:12] Setting affinity to run helper thread 2 on CPU core #3
[Work thread Oct 5 05:12] Setting affinity to run helper thread 3 on CPU core #4
[Comm thread Oct 5 05:12] PrimeNet success code with additional info:
[Comm thread Oct 5 05:12] CPU credit is 4.2951 GHz-days.
[Comm thread Oct 5 05:12] Done communicating with server.
[Work thread Oct 5 05:15] M9203287 stage 1 is 13.86% complete. Time: 176.025 sec.
[Work thread Oct 5 05:18] M9203287 stage 1 is 27.72% complete. Time: 175.997 sec.
[Work thread Oct 5 05:21] M9203287 stage 1 is 41.58% complete. Time: 175.971 sec.
[Work thread Oct 5 05:24] M9203287 stage 1 is 55.44% complete. Time: 175.988 sec.
[Work thread Oct 5 05:27] M9203287 stage 1 is 69.30% complete. Time: 176.017 sec.
[Work thread Oct 5 05:30] M9203287 stage 1 is 83.17% complete. Time: 175.973 sec.
[Main thread Oct 5 05:32] Benchmarking multiple workers to tune FFT selection.
[Work thread Oct 5 05:32] Worker stopped while running needed benchmarks.
[Main thread Oct 5 05:32] Timing 480K FFT, 4 cores, 1 worker. ^C[Oct 5 08:37] Stopping all worker windows.


Invalid choice

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: 5

Waiting for worker threads to stop.
Waiting for worker threads to stop.
Waiting for worker threads to stop.
Waiting for worker threads to stop.
Waiting for worker threads to stop.
Waiting for worker threads to stop.
Waiting for worker threads to stop.
Waiting for worker threads to stop.
Waiting for worker threads to stop.
Waiting for worker threads to stop.
Waiting for worker threads to stop.
Waiting for worker threads to stop.
Waiting for worker threads to stop.
Waiting for worker threads to stop.
Waiting for worker threads to stop.
Waiting for worker threads to stop.

[/CODE]

Interesting picture on an Intel Atom C2538 doing ECM:

0.7M exponent, type-1 FFT length 40K, 4 threads.
Stage 1: 82 seconds per output
Stage 2: 80 seconds per output

Also, stage 2 is way faster (960 seconds) than stage 1 (3042 seconds), despite B2 being chosen as 146*B1.

This isn't 30.7 specific, but after upgrading to Windows 11 today, I get a significant performance drop in Prime95 unless it is run in Administrator mode. Nearly a 70% drop. Happens in both 30.7b2 and 30.5b2

[QUOTE=ZacHFX;589541]This isn't 30.7 specific, but after upgrading to Windows 11 today, I get a significant performance drop in Prime95 unless it is run in Administrator mode. Nearly a 70% drop. Happens in both 30.7b2 and 30.5b2[/QUOTE]

Can you report on how well prime95 is assigning workers to CPU cores? Is Win11 adhering to prime95's affinity settings? This is similar to what my Alder Lake tester reported. Does Win11 have any new power saving settings where it puts CPU hogs like prime95 on slower running cores?

[QUOTE=tha;589504]Don't know yet if this is reproducable, I will try later. But mprime hangs on timing FFT's. I pressed ^C at 08:37 as shown in the output. I closed the terminal application at 08:40 which made the CPU usage drop from 13% to 2%.
[/QUOTE]


Build 1 or 2? This looks like the bug fixed in build 2.

[QUOTE=pepi37;589457]
With Prime95 30.7 b2 I have this problem
On the other side, with Prime95 30.6 build 4 on same configuration[/QUOTE]

It looks like non-Mersenne FFTs are broken. The bug was introduced when I switched to the C runtime libraries implementation of log2 rather than my own (part of a modernization to the C++11 standard). Still figuring out the exact issue. Will fix as soon as possible.

I am pleased to report that PM1 has found a factor and that the prp went without an itch with 30.7 b2

[QUOTE=Prime95;589555]Build 1 or 2? This looks like the bug fixed in build 2.
[/QUOTE]

Build 1 indeed.

[QUOTE=Prime95;589554][...] Win11 [...][/QUOTE]

Windows 11 seems to be always running with Virtualization-Based Security enabled and this will also cost some performance.

[QUOTE=Prime95;589554]Can you report on how well prime95 is assigning workers to CPU cores? Is Win11 adhering to prime95's affinity settings? This is similar to what my Alder Lake tester reported. Does Win11 have any new power saving settings where it puts CPU hogs like prime95 on slower running cores?[/QUOTE]

Affinity is the same. One exponent running on core 1, helper threads 2 through 8, the other running on core 9, helpers 10 through 16. All cores are in use, so it's not a question of using only the slower cores.

I'm seeing the same performance decrease even while in administrator mode now. But my CPU isn't generating nearly the same amount of heat as it was under win10 either. Restarting the computer and running only prime95 in administrator mode will get nearly the same performance as I had in win10. But it slowly loses performance over the course of an hour.

[QUOTE=ZacHFX;589568]
I'm seeing the same performance decrease even while in administrator mode now. But my CPU isn't generating nearly the same amount of heat as it was under win10 either. Restarting the computer and running only prime95 in administrator mode will get nearly the same performance as I had in win10. But it slowly loses performance over the course of an hour.[/QUOTE]

Do any of these suggestions help:
[url]https://gadgetstouse.com/blog/2021/07/05/make-windows-11-faster-and-improve-performance/[/url]

I'm wondering if Win11 has a new default performance plan that does not run programs like prime95 at full clock speed

Build 3 available. Fixes pepi's problem with PRP of non-Mersenne numbers.

[QUOTE=Prime95;589597]Build 3 available. Fixes pepi's problem with PRP of non-Mersenne numbers.[/QUOTE]


Build3 working perfect
Thanks!

Build 3 solved partially my windows11pro performance issues.

But it is still slower when I stop and restart Prime95.

If I do a fresh boot up of my machine it gives around 2,850ms/iter.
But if I stop the task and restart it the performance goes down to 3,250ms/iter.

But at least it's better then the old 5,900ms/iter that I was getting on restart.

It is also known that win11 has some performance problems with Ryzen.
They're fixing it. Hope they can fix it.

I never had performance issues in windows10 with Prime95.

[UPDATE]: Performance bad again on a restart, around 5,750ms/iter

[QUOTE=JCoveiro;589753]But at least it's better then the old 5,900ms/iter that I was getting on restart.

It is also known that win11 has some performance problems with Ryzen.
They're fixing it. Hope they can fix it.[/QUOTE]
Does this issue only occur with the Ryzen CPUs, or there are similar delays for the Intel CPUs too.

Has Prime95 30.7 been tested on AMD Threadripper CPUs yet? Does Prime95 30.7 recognize the differences between the E and P cores of Intel 12900k?

It maybe a good idea to wait until the beginning of next year for me to buy a new PC, less troubleshooting and performance issues.

[QUOTE=Ben Delo;580497]Your wish is my command...

[CODE]
[Worker #1 Jun 10 01:33] Iteration: 410000 / 168308323 [0.24%], ms/iter: 2.386, ETA: 4d 15:15
[Worker #1 Jun 10 01:34] Iteration: 250000 / 168485323 [0.14%], ms/iter: 2.403, ETA: 4d 16:18
[Worker #1 Jun 10 01:34] Iteration: 160000 / 168548323 [0.09%], ms/iter: 2.409, ETA: 4d 16:39[/CODE][/QUOTE]
Ben Delo's AWS instance seems still somewhat faster than the top speed of Jcoveiro's PC.

Ben Delo's engine: 2.40 ms/iter
Jcoveiro's engine: 2.85 ms/iter

[QUOTE=tuckerkao;589791][...] Ryzen CPUs [...][/QUOTE]

There is an additional problem with Ryzen CPUs in Windows 11. The new scheduler has problems with the CPUs such that the L3 cache is used incorrectly (the calculations are correct, but data transfer is slower).

[QUOTE=tuckerkao;589791]Has Prime95 30.7 been tested on AMD Threadripper CPUs yet?[/QUOTE]

Yes, I am running ECM on one. Unfortunately, it is crashing and I am currently trying to reproduce it more reliably. It always generates an entry into the event log like:
[CODE]Error code: 0xc0000005
Error offset: 0x00000000020813bf[/CODE]
These numbers stay the same.

Edit: This is Zen 1 on Windows 10. Sorry for letting this out.

[QUOTE=kruoli;589796]
Yes, I am running ECM on one. Unfortunately, it is crashing and I am currently trying to reproduce it more reliably.[/QUOTE]

I doubt it has anything to do with Zen. Please tell me the worktodo.txt entry as well as the amount of memory ECM is allowed in stage 2. I'll start a run under the debugger and see what happens.

[B]Note to all:[/B] Until build 4 comes out, hyperthreaded torture tests must use the custom setting and select FFT sizes larger than 256K.

PM sent, thanks! :smile:

Would really like to have the option to specify get DC assigned via PrimeNet yet automatically run them as PRP DC/GEC/proof-gen on the prime95 v30.7bx client. Or to be able to specify getting PRP DC candidates & run them as PRP DC/GEC/proof-generation. Pig-in-a-poke generic DC as the only DC preference choice means LL DC may land on (newish) AVX512 hardware that's recently started throwing multiple Jacobi symbol check errors / DC exponent. I don't think forcing less-reliable hardware to either run first tests, or periodically produce sketchy LL DC, is the way we want to go.

[QUOTE=kriesel;589926]Would really like to have the option to specify get DC assigned via PrimeNet yet automatically run them as PRP DC/GEC/proof-gen on the prime95 v30.7bx client. Or to be able to specify getting PRP DC candidates & run them as PRP DC/GEC/proof-generation. Pig-in-a-poke generic DC as the only DC preference choice means LL DC may land on (newish) AVX512 hardware that's recently started throwing multiple Jacobi symbol check errors / DC exponent. I don't think forcing less-reliable hardware to either run first tests, or periodically produce sketchy LL DC, is the way we want to go.[/QUOTE]

Try work preference of 155. It's been there all along, probably never been tested.

[QUOTE=nordi;589277]I noticed that for ECM on small exponents, stage 2 init now takes a lot longer than before.[/QUOTE]

Computing better pairing is expensive. For large exponents this is well worth the cost as each multiplication saved is expensive. For small exponents such as yours saving a squaring is not worth terribly much. Consequently, for small exponents don't expect to see much, if any, improvement from the better prime pairing.

Prime95 does factor all this into account but only for the "common" cases. Common is defined as B1 between 10K and 100M, B2/B1 between 20 and 200.

Have you considered using GMP-ECM for stage 2? It should be superior for exponents up to 50K or so.

Build 4 now available. See post #2 for bugs fixed.

1. That old bug of changing "CPU cores to use (multithreading)" haven't fixed yet. Sometimes I could not change the number of cores (for example, reducing from 4 to 3, then to 2, then to 1). The input area isn't disabled, however if I click somewhere else (including the "ok" button) it would return to the original value. The same bug exists in older versions such as 30.3b6 and 30.6b4, as I have mentioned before in [URL]https://www.mersenneforum.org/showthread.php?p=583580[/URL].

2. Prime95 still cannot stop completely during proof generation. The worker in proof generation won't stop until it finishes(or killed by the task manager). However, I can neither stop the proof generation or resume other workers after clicking the "stop" in the popup menu. The same problem also exists in older versions.

[QUOTE=Prime95;589589]Do any of these suggestions help:
[url]https://gadgetstouse.com/blog/2021/07/05/make-windows-11-faster-and-improve-performance/[/url]

I'm wondering if Win11 has a new default performance plan that does not run programs like prime95 at full clock speed[/QUOTE]

No luck with anything there. I'm assuming it's mostly caused by the L3 cache issues reported everywhere. Will see what happens when they fix that sometime in the next few weeks.

[QUOTE=Zhangrc;590096]1. That old bug of changing "CPU cores to use (multithreading)" haven't fixed yet. Sometimes I could not change the number of cores (for example, reducing from 4 to 3, then to 2, then to 1). The input area isn't disabled, however if I click somewhere else (including the "ok" button) it would return to the original value. The same bug exists in older versions such as 30.3b6 and 30.6b4, as I have mentioned before in [URL]https://www.mersenneforum.org/showthread.php?p=583580[/URL].[/QUOTE]

Please tell me your current worker/#cores configuration.
Then tell me which number(s) you try to change to reproduce the problem.

[QUOTE=Prime95;590042]Try work preference of 155. It's been there all along, probably never been tested.[/QUOTE]WorkPreference=155 in prime.txt. Stop, exit, and restart to make it take effect. Check Test, Worker Windows, after the restart, it's called "other". Not something we can set from the prime95 GUI, IIUC.
I have a prime95 session on this laptop, and mprime on 2 Colab notebooks, set to use that now, as a parallel test. It will take days or weeks to know whether it's working.

[QUOTE=Prime95;589236]Report the typical P-1 stage 1 timings vs. typical stage 2 timings[/QUOTE]Sandy Bridge-E i7-3930K, DDR3-1333[quote]
v30.6b4: 23M exponent, 32GB, B1=523k, B2=35.5M, 8.46%, pair=95.55%: S1 = 149s [18m47s], S2 = 233s [45m25s]
v30.7b4: 23M exponent, 32GB, B1=[COLOR="OrangeRed"]506k[/COLOR], B2=[COLOR="red"]30.0M[/COLOR], [COLOR="Red"]8.23%[/COLOR], pair=[COLOR="SeaGreen"]99.16%[/COLOR]: S1 = 149s [[COLOR="DarkGreen"]18m14s[/COLOR]], S2 = 232s [[COLOR="SeaGreen"]36m32s[/COLOR]]
[/quote]Timings are the same between .6 and .7 but the bounds have dropped 5%/15%, pairing has gone up. Stage2 runtime is much shorter.

[QUOTE=Prime95;590120]Please tell me your current worker/#cores configuration.[/QUOTE]
Originally 2 workers, 4 cores each worker. and I face problems when changing the number of cores for each worker. I could change it from 4 to 3, but couldn't change it from 3 to 2.

[QUOTE=Zhangrc;590140]Originally 2 workers, 4 cores each worker. and I face problems when changing the number of cores for each worker. I could change it from 4 to 3, but couldn't change it from 3 to 2.[/QUOTE]

Windows or Linux? I cannot reproduce under Windows.

[QUOTE=Prime95;590148]Windows or Linux[/QUOTE]
I have both Windows Prime95 and Linux mprime, running in the same directory. In mprime, it just prints the number of cores for each worker, but I have no chance to change it.
(although I can edit prime.txt to change it)

[QUOTE=Prime95;590139]It can be done. Read undoc.txt regarding Stage1GCD setting.[/QUOTE]
Thanks! I did not know about the new option.

[QUOTE=Prime95;590139]If you can reproduce a problem, I'll investigate a fix.[/QUOTE]
30.7b4, I put [C]Pminus1=1,2,22801871,-1,800000,40000000,74[/C] in worktodo.txt. There is a file mM801871 which has be done to B1=800000, B2=38400000. It states "P-1 on M22801871 with B1=800000, B2=TBD" as expected. The save file gets used, it nearly immediately goes to "Conversion of stage 1 result complete". No "optimal B2..." message appears. In fact, there is no mention at all what B2 is going to be used. Only the result uncovers: B2=100*B1 gets used, which is neither optimal nor the B2 stated in the worktodo.txt.

if you remove the 74 of your line, it will use the bound you specified.

[QUOTE=Prime95;590042]Try work preference of 155. It's been there all along, probably never been tested.[/QUOTE]Tried it in mprime, which accepts the preference without question, but then when it contacts the server for new work:[quote][COLOR="blue"][Work thread Oct 11 21:26] Running Jacobi error check.[/COLOR] [Oct 11 21:26] Getting assignment from server
[Comm thread Oct 11 21:26] PrimeNet success code with additional info:
[Comm thread Oct 11 21:26]
[Comm thread Oct 11 21:26] Got assignment 17FE[SPOILER]--yes-I-masked-the-aid--[/SPOILER]F9CE: [COLOR="Red"]Unknown work type M58874623[/COLOR]
[Comm thread Oct 11 21:26] Received unknown work type: 151.
[Comm thread Oct 11 21:26] Visit [url]http://mersenneforum.org[/url] for help.
[Comm thread Oct 11 21:26] Will try contacting server again in 70 minutes.
[COLOR="Blue"][Work thread] Passed. Time: 23.059 sec.[/COLOR][/quote]Worktype 151 = [c]Double-check prime tests[/c] so I'm not sure why it's calling it unknown.
But it's also claiming to receive a worktype of [c]M58874623[/c] which clearly is not right.
Note that these exponents have been [url=https://www.mersenne.org/report_exponent/?exp_lo=58874623&full=1]assigned to me[/url] as a PRP double-check on the server, but did not get added to worktodo.txt because mprime believes the assignment line to be invalid.

Also minor complaint -- the above is not a copy-paste error, the primenet server communication really does happen in the middle of the Jacobi error check leading to confused mixed messages from [COLOR="blue"]work-thread[/COLOR] and comm-thread on same lines.

All the above behavior is the same in both v30.6b4 and v30.7b4

[QUOTE=James Heinrich;590192]Tried it in mprime, which accepts the preference without question, but then when it contacts the server for new work:Worktype 151 = [c]Double-check prime tests[/c] so I'm not sure why it's calling it unknown.
But it's also claiming to receive a worktype of [c]M58874623[/c] which clearly is not right.[/QUOTE]

Try it again. I tweaked the server-side PHP code.

[QUOTE=Prime95;590196]Try it again. I tweaked the server-side PHP code.[/QUOTE]It auto-retried, seems happier now:[quote][Comm thread Oct 11 23:08] Getting assignment from server
[Comm thread Oct 11 23:08] PrimeNet success code with additional info:
[Comm thread Oct 11 23:08] Server assigned PRPDC work.
[Comm thread Oct 11 23:08] Got assignment E422[SPOILER]000000000000000000000000[/SPOILER]19AD: PRPDC M58876087
[Comm thread Oct 11 23:08] Sending expected completion date for M58876087: Oct 18 2021
[Comm thread Oct 11 23:08] Done communicating with server.[/quote]

[QUOTE=kruoli;590157]The save file gets used, it nearly immediately goes to "Conversion of stage 1 result complete". No "optimal B2..." message appears. In fact, there is no mention at all what B2 is going to be used. Only the result uncovers: B2=100*B1 gets used, which is neither optimal nor the B2 stated in the worktodo.txt.[/QUOTE]

Optimal B2 does not work when continuing from an existing save file. For one, the previous B2 may be beyond the optimal B2. I believe optimal B2 will work if you extend B1 past the previous B2.

Anyway, I've corrected (in 30.7 build 5) the problem where the B2 supplied in worktodo.txt is replaced by 100 * B1.

[QUOTE=Prime95;590120]Please tell me your current worker/#cores configuration.
Then tell me which number(s) you try to change to reproduce the problem.[/QUOTE]
See the attachment below for details (the video inside the 7z file). The bug is really strange because I couldn't find any variable in prime.txt and local.txt which equals to 3.

Hmm, previous stable version of mprime observed this entry in prime.txt:

[CODE]
^C[Main thread Oct 13 14:57] Stopping all worker windows.
[Work thread Oct 13 14:57] Worker stopped.
[Main thread Oct 13 14:57] Execution halted.
[Main thread Oct 13 14:57] Choose Test/Continue to restart.
5

tha@Z170:~/Mersenne30$ cat prime.txt
V24OptionsConverted=1
V30OptionsConverted=1
WGUID_version=2
StressTester=0
UsePrimenet=1
DialUp=0
V5UserID=Tha
OutputIterations=400000
ResultsFileIterations=999999999
DiskWriteTime=30
NetworkRetryTime=2
NetworkRetryTime2=70
DaysOfWork=3
DaysBetweenCheckins=1
NumBackupFiles=1
SilentVictory=0
Priority=1
RunOnBattery=1
WorkPreference=4

[B]Stage1GCD=0[/B]

[PrimeNet]
Debug=0
ProxyHost=
UploadRateLimit=128
UploadStartTime=00:00
UploadEndTime=24:00
DownloadDailyLimit=1024

[Worker #1]
tha@Z170:~/Mersenne30$ ./mprime -m
[Main thread Oct 13 14:58] Mersenne number primality test program version 30.7
[Main thread Oct 13 14:58] 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 Oct 13 14:58] Starting worker.
[Work thread Oct 13 14:58] Worker starting
[Work thread Oct 13 14:58] Setting affinity to run worker on CPU core #1
[Work thread Oct 13 14:58]
[Work thread Oct 13 14:58] P-1 on M9240013 with B1=2000000, B2=TBD
[Work thread Oct 13 14:58] Setting affinity to run helper thread 1 on CPU core #2
[Work thread Oct 13 14:58] Setting affinity to run helper thread 3 on CPU core #4
[Work thread Oct 13 14:58] Setting affinity to run helper thread 2 on CPU core #3
[Work thread Oct 13 14:58] Using FMA3 FFT length 480K, Pass1=384, Pass2=1280, clm=4, 4 threads
[Work thread Oct 13 15:01] M9240013 stage 1 is 13.86% complete. Time: 174.373 sec.
[Work thread Oct 13 15:04] M9240013 stage 1 is 27.72% complete. Time: 186.784 sec.
[Work thread Oct 13 15:07] M9240013 stage 1 is 41.58% complete. Time: 177.911 sec.
[Work thread Oct 13 15:10] M9240013 stage 1 is 55.44% complete. Time: 176.519 sec.
[Work thread Oct 13 15:13] M9240013 stage 1 is 69.30% complete. Time: 176.450 sec.
[Work thread Oct 13 15:16] M9240013 stage 1 is 83.17% complete. Time: 186.553 sec.
[Work thread Oct 13 15:19] M9240013 stage 1 is 97.03% complete. Time: 183.830 sec.
[Work thread Oct 13 15:20] M9240013 stage 1 complete. 5771292 transforms. Total time: 1302.166 sec.
[Work thread Oct 13 15:20] [B]P-1 found a factor in stage #1, B1=2000000.[/B]
[Work thread Oct 13 15:20] M9240013 has a factor: 411692187356691061619881660439392355722667064629522661791 (P-1, B1=2000000)
[Comm thread Oct 13 15:20] Sending result to server: UID: Tha/Z170-m30.7, M9240013 has a factor: 411692187356691061619881660439392355722667064629522661791 (P-1, B1=2000000)
[Comm thread Oct 13 15:20]
[Work thread Oct 13 15:20]
[Work thread Oct 13 15:20] [B]P-1 on M9265469 [/B]with B1=2000000, B2=TBD
[Work thread Oct 13 15:20] Setting affinity to run helper thread 1 on CPU core #2
[/CODE]

George - The Gerbicz error checking needs to be 1% or 1,000,000 whichever is [U]greater[/U] by default. This needs to be editable in the GUI (not just by editing a file) similar to 'iterations between screen outputs:' is in the options > preferences menu.

It would also be nice if both these settings could be configured either by number of iterations [U]or[/U] percentage.

[QUOTE=tha;590405]Hmm, previous stable version of mprime observed this entry in prime.txt:[/QUOTE]

Yes, this was changed. Now, you need to set it to [C]Stage1GCD=-1[/C].

[QUOTE=ZacHFX;590117]No luck with anything there. I'm assuming it's mostly caused by the L3 cache issues reported everywhere. Will see what happens when they fix that sometime in the next few weeks.[/QUOTE]

I'm happy to report that after an update today, whatever problems Win11 was having with Prime95 on my Ryzen seem to have been fixed. I'm back to my old iterations/s.

[QUOTE=rainchill;590408]George - The Gerbicz error checking needs to be 1% or 1,000,000 whichever is [U]greater[/U] by default.[/quote]

Why?

[quote]This needs to be editable in the GUI (not just by editing a file) similar to 'iterations between screen outputs:' is in the options > preferences menu.

It would also be nice if both these settings could be configured either by number of iterations [U]or[/U] percentage.[/QUOTE]

Why?

Why not time based? Like Gerbicz roughly once an hour so that I don't lose too much work.

Actually, you are the first person to ask for this. If so few people care, it seems like a good option to leave to manually editing the prime.txt file.

[QUOTE=Zhangrc;590369]See the attachment below for details (the video inside the 7z file). The bug is really strange because I couldn't find any variable in prime.txt and local.txt which equals to 3.[/QUOTE]

I see it, but still cannot reproduce it.

Do you have any workers set to 100M digit testing? There is some strange code in prime95 that forces this work to be multi-threaded to reduce the amount of abandoned 100Mdigit tests.

Try sending me prime.txt, local.txt and I'll try to reproduce again. Weird.

Build 5 is ready -- mainly for Ken and kruoli.

[QUOTE=Zhangrc;590369]The bug […][/QUOTE]

This problem is really hard to reproduce – I tried multiple times over multiple versions. Sometimes it is there, sometimes not. I remember some posts in the past mentioning this problem, it even occurred to me that I myself reported it some time ago – but I could not find it then.

The problem happens when the text box looses focus. In the video, you can see that it changes back briefly to 3 when the window gets closed, but only if you enter a [I]smaller[/I] value.

But lets have a look at the code… The problem is (assumption here, but I'm relatively sure) the function [C]min_cores_for_work_pref[/C] which gets called from the event handler when leaving the text box. These lines are important (from 30.6b4 source):
[CODE]cores = cores * 24 / CPU_HOURS;
if (cores > (int) NUM_CPUS) cores = NUM_CPUS;[/CODE]

You have [C]NUM_CPUS = 8[/C] in your example. Assuming you set 8 h per day, [C]cores = cores * 24 / 8[/C]. Since [C]cores[/C] is set to 1 before that snippet, because you are [I]not[/I] running 100M digit tests (then it would be 4), [C]cores[/C] will be 3 afterward. [U]This value gets returned (in this case 3) and set back into the text box[/U] (lines 328-332 and 335, 336 and 339-340 in WorkerDlg.c). This should happen for CPU_HOURS from 8 to 11, inclusively.

@George: You might have to set your CPU hours per day to e.g. 1, have multiple workers and then should be able to reproduce this.

[QUOTE][Oct 14 23:38:49] Timing 384K FFT, 6 cores, 1 worker. Average times: 0.27 ms. Total throughput: 3727.40 iter/sec.
[Oct 14 23:39:04] Timing 384K FFT, 6 cores, 2 workers. Average times: 0.50, 0.50 ms. Total throughput: 4004.31 iter/sec.
[I][B][COLOR=Red][Oct 14 23:39:19] Timing 384K FFT, 6 cores hyperthreaded, 1 worker. Average times: 0.27 ms. Total throughput: 3743.41 iter/sec.
[Oct 14 23:39:34] Timing 384K FFT, 6 cores hyperthreaded, 2 workers. Average times: 0.50, 0.50 ms. Total throughput: 3990.78 iter/sec.[/COLOR][/B][/I]
[Oct 14 23:39:49]
[Oct 14 23:39:49] Throughput benchmark complete.
[Oct 14 23:39:49] Throughput benchmark complete.
[Oct 14 23:39:49] Worker stopped.
[/QUOTE]


But CPU i5-9600K doesnot have HT cores.

[QUOTE=pepi37;590592]But CPU i5-9600K doesnot have HT cores.[/QUOTE]

Windows or Linux? Did the dialog box allow you to select the "Use hyperthreading" checkbox?

[B]Nevermind. Fix coming in build 6.[/B]

[QUOTE=kruoli;590526]
@George: You might have to set your CPU hours per day to e.g. 1, have multiple workers and then should be able to reproduce this.[/QUOTE]

[QUOTE=Zhangrc;590369]The bug is really strange ...[/QUOTE]

Thanks kruoli. I'll add text to worker windows dialog box to explain that there is a minimum number of cores.

An explanation might not be sufficient (or would need to include a workaround like setting CPU hours to 24 while editing the worker window or manually editing the setting text files). Consider this (in my opinion realistic) example:
Someone wants to do work with small FFTs (ECM, PRP-CF, etc.). He has 8 cores. He has 8 CPU hours per day set. He found out that four workers with two threads each give the best throughput (which is realistic for the work I described).

If he then tries to enter that in the worker window, he is forced to give [U]3[/U] threads to each of the 4 worker windows, which is clearly nonsensical. Naturally, Prime95 will complain that this is over-allocation.
Possible solution: The minimum number of threads cannot exceed floor((CPU cores)/(worker count)).

But there is another problem: If PrimeNet is disabled, these requirements are still enforced (just tested that). Why should we enforce such requirements if somebody is doing something out of PrimeNet space?
Possible solution: If PrimeNet is disabled, the minimum number of threads is always 1.

[QUOTE=Prime95;590515]
Try sending me prime.txt, local.txt and I'll try to reproduce again. Weird.[/QUOTE]

Here you are :bounce:

[QUOTE=Zhangrc;590640]Here you are :bounce:[/QUOTE]

As kruoli successfully diagnosed, your solution is to change the hours per day setting in Options/CPU.

Still getting a considerable CERT ETA mismatch (weeks), with 843M and v30.7b5.

[QUOTE=kruoli;590639]If PrimeNet is disabled, the minimum number of threads is always 1.[/QUOTE]
Even if PrimeNet is enabled, the number of threads should be allowed to set to whatever number people want. Modern CPU cores are really fast, and the big cores in Alder Lake are even faster. (Never seen any consumer CPUs running at > 5GHZ before)

Also, The "For help, press F1" at the bottom left corner has practically no use. If I press F1, a message box appears, which says "Failed to launch help."
I thought it was due to a file shortage. There was a CHM file in the past, but somehow get removed. (No need to reinstate it, since the CHM file reader is old enough. However it can cause some inconsistencies)

Something strange is going on here, suddenly it keeps saying 100% done. Version was Linux64,Prime95,v30.7,build 5. I might have accidentially changed the B1 sizes in worktodo.txt after a save file has been created, maybe this was the root cause?

[C]
...
[Worker #2 Oct 18 17:00] M6025297 stage 2 is 66.43% complete. Time: 17.019 sec.
[Worker #1 Oct 18 17:01] M6058333 stage 1 is 99.72% complete. Time: 42.995 sec.
[Worker #2 Oct 18 17:01] M6025297 stage 2 is 66.63% complete. Time: 18.497 sec.
[Worker #2 Oct 18 17:01] M6025297 stage 2 is 66.82% complete. Time: 17.966 sec.
[Worker #1 Oct 18 17:01] M6058333 stage 1 complete. 1975688 transforms. Total time: 3637.744 sec.
[Worker #1 Oct 18 17:01] Conversion of stage 1 result complete. 5 transforms, 1 modular inverse. Time: 2.732 sec.
[Worker #1 Oct 18 17:01] Available memory is 3072MB.
[Worker #2 Oct 18 17:01] M6025297 stage 2 is 67.01% complete. Time: 17.050 sec.
[Worker #2 Oct 18 17:02] M6025297 stage 2 is 67.20% complete. Time: 16.904 sec.
[Worker #1 Oct 18 17:02] D: 840, relative primes: 1188, stage 2 primes: 10930004, pair%=98.65
[Worker #2 Oct 18 17:02] Restarting worker with new memory settings.
[Worker #2 Oct 18 17:02]
[Worker #2 Oct 18 17:02] P-1 on M6025297 with B1=2000000, B2=200000000
[Worker #2 Oct 18 17:02] Using FMA3 FFT length 320K, Pass1=320, Pass2=1K, clm=4
[Worker #2 Oct 18 17:02] Available memory is 3074MB.
[Worker #2 Oct 18 17:02] D: 840, relative primes: 1191, stage 2 primes: 10930004, pair%=98.67
[Worker #2 Oct 18 17:02] Using 3078MB of memory.
[Worker #1 Oct 18 17:02] Using 3070MB of memory.
[Worker #2 Oct 18 17:02] Stage 2 init complete. 2499 transforms. Time: 19.738 sec.
[Worker #2 Oct 18 17:02] M6025297 stage 2 is 100.00% complete.
[Worker #1 Oct 18 17:02] Stage 2 init complete. 2496 transforms. Time: 73.500 sec.
[Worker #2 Oct 18 17:02] M6025297 stage 2 is 100.00% complete. Time: 16.709 sec.
[Worker #2 Oct 18 17:03] M6025297 stage 2 is 100.00% complete. Time: 17.558 sec.
[Worker #1 Oct 18 17:03] M6058333 stage 2 is 0.15% complete. Time: 28.509 sec.
[Worker #2 Oct 18 17:03] M6025297 stage 2 is 100.00% complete. Time: 18.477 sec.
[Worker #2 Oct 18 17:03] M6025297 stage 2 is 100.00% complete. Time: 17.475 sec.
[Worker #1 Oct 18 17:03] M6058333 stage 2 is 0.32% complete. Time: 36.625 sec.
[Worker #2 Oct 18 17:04] M6025297 stage 2 is 100.00% complete. Time: 17.986 sec.
...
[/C]

[QUOTE=Zhangrc;590957]Even if PrimeNet is enabled, the number of threads should be allowed to set to whatever number people want. Modern CPU cores are really fast, and the big cores in Alder Lake are even faster. (Never seen any consumer CPUs running at > 5GHZ before)...[/QUOTE]
The 8086k (a binned 8700k) was the first single core turbo to hit 5.0GHz out of the box, since then each gen the top 14nm parts have improved the speed and number of cores that can do >=5GHz. If Alder Lake can really hit >=5GHz that's impressive because up until now I don't think a non-14nm part has come close. intel may finally be back in shape with the golden cove design, I wonder how much fab capacity is ready for the newer process.

[QUOTE=ZacHFX;590503]I'm happy to report that after an update today, whatever problems Win11 was having with Prime95 on my Ryzen seem to have been fixed. I'm back to my old iterations/s.[/QUOTE]


Had the same experience. Upgraded my Ryzen 4600H laptop to Windows 11 today and tanked my PRP-CF s/iter from 0.60 to 1.15 (without any decrease in power consumption :huh:). Installed a "2021-10 Cumulative Update for Windows 11" (Microsoft KB5006746) from Windows Update and I'm posting 0.60 s/iter again.


I wonder why, if you're upgrading from 10 to 11, Microsoft doesn't push the newest version to start with...

[QUOTE=kriesel;590133]WorkPreference=155 in prime.txt. Stop, exit, and restart to make it take effect. Check Test, Worker Windows, after the restart, it's called "other". Not something we can set from the prime95 GUI, IIUC.
I have a prime95 session on this laptop, and mprime on 2 Colab notebooks, set to use that now, as a parallel test. It will take days or weeks to know whether it's working.[/QUOTE]


I've had this preference set on v30.6b4 for some time now. At first it would not recognize the work type and I would have to manually add them to worktodo.txt. However I've just noticed the last time it fetched assignments that it now recognizes the assigment type and writes them to worktodo.txt on its own.

[QUOTE=sparticus42;591320]I've had this preference set on v30.6b4 for some time now. At first it would not recognize the work type and I would have to manually add them to worktodo.txt. However I've just noticed the last time it fetched assignments that it now recognizes the assignment type and writes them to worktodo.txt on its own.[/QUOTE]
See [URL]https://mersenneforum.org/showpost.php?p=590196&postcount=57[/URL]
And it looks like [URL="https://mersenneforum.org/showpost.php?p=590133&postcount=49"]mine[/URL] worked recently too.

[quote=readme.txt]Upload bandwidth limit
----------------------
For most home users, download speed is faster than upload speed. If upload speed is not limited,
it can seriously impact download speeds. I recommend not using more than 10% of your upload bandwidth.
[b]The default setting is 0.25Mbps[/b]. This uploads a 100MB proof file in about an hour. If the upload
is interrupted, it will automatically resume from where it left off at a later time.[/quote]I'm not sure where this setting is adjusted? I don't notice any relevant settings in local.txt or even undoc.txt, although the latter does mention [c]DownloadRateLimit[/c]. Are uploads really limited to 0.25Mbps?

[QUOTE=James Heinrich;591360]I'm not sure where this setting is adjusted? I don't notice any relevant settings in local.txt or even undoc.txt, although the latter does mention [c]DownloadRateLimit[/c]. Are uploads really limited to 0.25Mbps?[/QUOTE]

You should be able to adjust it in the Prime95, I think it's named Resource limits. It should be the same place where the disk space settings are.

[QUOTE=Viliam Furik;591361]You should be able to adjust it in the Prime95, I think it's named Resource limits. It should be the same place where the disk space settings are.[/QUOTE]Well that's embarassing. :redface:
I looked at that dialog multiple times and somehow failed to see what was there.
The appropriate settings are also available in mprime.
And it gets written to [c]prime.txt[/c] under[code][PrimeNet]
UploadRateLimit=<value>[/code]where [c]<value>[/c] is the upload limit in Mbps.

Latest Prime95 Updating?
 

[QUOTE=Prime95;590599]Windows or Linux? Did the dialog box allow you to select the "Use hyperthreading" checkbox?

[B]Nevermind. Fix coming in build 6.[/B][/QUOTE]

Has Build 6 been uploaded yet? My latest PRP test should end tomorrow and I want to change versions before starting my next one.

[QUOTE=Glenn;591426]Has Build 6 been uploaded yet?[/QUOTE][URL="https://mersenneforum.org/showpost.php?p=589234&postcount=1"]Not yet.[/URL]

Okay then I’ll use build 5

v30.7 b2 (same as post 23)
8600K Coffee Lake CPU, 1 worker, 6 threads. FMA3 FFT (6M), 114.5M exponent: stage 1 = 68.1 sec, stage 2 = 105.2 sec

I'm getting really inconsistent performance on my Threadripper PRO 3955WX (16 cores) running Windows 10 for Workstations. I've only ever used 30.7 builds on this machine, so I don't have any earlier points of comparison (but will certainly test earlier versions if it would matter).

I'm using one worker with 8 threads. Recently, when doing some double checks, it would bounce between either ~2.1ms/iter or ~2.8ms/iter (with no other processes heavily using CPU). Once it was in a particular range, it wouldn't change during a run, but might change modalities after an auto-benchmark or manually stopping/starting. (Though I haven't seen the faster mode since the most recent boot which included a BIOS update and a Windows update.) If other programs were using the CPU, those would slow incrementally (2.1 to maybe as low as 2.5 and 2.8 to maybe 3.2), but there were two clear patterns. Manually assigning affinities in local.txt did help to some extent as well.

Now, having moved on to a larger PRP test in the 110M range, a throughput test on the same settings suggested ~6.6ms/iter, but the test itself was getting ~8.7ms/iter. After restarting the test after removing my Affinity= line, the test now decreased to ~8.0ms/iter, but either I'm misunderstanding the benchmark or there's still something strange going on.

Anyway, if anyone has any ideas or can explain what I'm missing, I'd be all ears. Don't seem to have any similar issues on my 3700X or Threadripper 3960X, but both of those machines are running Linux.

Build 7 is available. Build 6 does not exist (except for Kruoli).

There is still at least one bug remaining. Running multiple ECM workers can crash with either an out-of-memory event or a restarting with new memory settings event. I've been running for a week under the debugger without any luck. Kruoli has seen one crash in that time.

all latest prime95 will fail to run with core cycler .....

[QUOTE=gLauss;591006]
[C]
[Worker #2 Oct 18 17:03] M6025297 stage 2 is 100.00% complete. Time: 17.558 sec.
[Worker #1 Oct 18 17:03] M6058333 stage 2 is 0.15% complete. Time: 28.509 sec.
[Worker #2 Oct 18 17:03] M6025297 stage 2 is 100.00% complete. Time: 18.477 sec.
[Worker #2 Oct 18 17:03] M6025297 stage 2 is 100.00% complete. Time: 17.475 sec.
[/C][/QUOTE]
can anybody help why this has happened? could not reproduce it so far, see original post for more details...

[QUOTE=gLauss;591848]can anybody help why this has happened? could not reproduce it so far, see original post for more details...[/QUOTE]

The stage two 100% complete error should be harmless. I'm looking into why it occurs.

Wavefront P-1, In build 5, when day and night memory settings are different, stage 2 cannot be resumed from the larger memory part:
[CODE][Work thread Oct 29 06:19] M107021149 stage 2 is 45.45% complete. Time: 1957.403 sec.
[Work thread Oct 29 06:52] M107021149 stage 2 is 53.92% complete. Time: 1969.442 sec.
[Work thread Oct 29 07:00] Restarting worker with new memory settings.
[Work thread Oct 29 07:00] Optimal P-1 factoring of M107021149 using up to 24576MB of memory.
[Work thread Oct 29 07:00] Assuming no factors below 2^76 and 4 primality tests saved if a factor is found.
[Work thread Oct 29 07:00] Optimal bounds are B1=1729000, B2=94551000
[Work thread Oct 29 07:00] Chance of finding a factor is an estimated 5.53%
[Work thread Oct 29 07:00]
[Work thread Oct 29 07:00] Using FMA3 FFT length 5760K, Pass1=1536, Pass2=3840, clm=1, 8 threads
[Work thread Oct 29 07:00] D: 330, relative primes: 354, stage 2 primes: 5335022, pair%=92.41
[Work thread Oct 29 07:00] Using 16371MB of memory.
[Work thread Oct 29 07:00] Stage 2 init complete. 848 transforms. Time: 9.439 sec.
[Work thread Oct 29 07:00] M107021149 stage 2 is 0.00% complete.
[Work thread Oct 29 07:32] M107021149 stage 2 is 8.20% complete. Time: 1901.034 sec.
[Work thread Oct 29 08:03] M107021149 stage 2 is 16.51% complete. Time: 1903.386 sec.
[Work thread Oct 29 08:35] M107021149 stage 2 is 24.89% complete. Time: 1901.938 sec.
[Work thread Oct 29 09:07] M107021149 stage 2 is 33.34% complete. Time: 1902.549 sec.[/CODE]Is this the opposite error to the one mentioned by [B][COLOR=Navy]gLauss[/COLOR][/B]?

[QUOTE=kruoli;591953]Wavefront P-1, In build 5, when day and night memory settings are different, stage 2 cannot be resumed from the larger memory part

Is this the opposite error to the one mentioned by [B][COLOR=Navy]gLauss[/COLOR][/B]?[/QUOTE]

I'm afraid stage 2 really did restart from scratch. Working on a fix.

[QUOTE=Aexoden;591788]I'm getting really inconsistent performance on my Threadripper PRO 3955WX (16 cores) running Windows 10 for Workstations. I've only ever used 30.7 builds on this machine, so I don't have any earlier points of comparison (but will certainly test earlier versions if it would matter).[/QUOTE]

Just to update on this, it seems the major problem was having memory installed in the incorrect slots (I'm only using four of the eight channels, and at the time I built the machine, the motherboard manual gave inconsistent advice and apparently I guessed wrong.)

That said, when using only 8 of the available 16 cores, the affinities chosen by Prime95 seem to be suboptimal (which might be expected, given that I think I read somewhere that it's optimized assuming all cores are used). (The default selection on a 5760K CERT run gave about 4.7ms/iter, whereas a manual Affinity setting of 0,4,8,12,16,20,24,28 gave me 3.9ms/iter). I have no idea why that pattern would be better, that was just the fastest one I found.

Probably a stupid question:

When one is using the cert range controls provided in undoc.txt (Cert[Min|Max]Exponent), do you need to add both lines for the functionality to work, or are you fine to add only one or the other?