Prime95 version 29.6/29.7/29.8

[kriesel]

Originally Posted by pepi37

I have similar error in next condition: if you have two workers and both work on candidate with same exponent, then you will get similar error. I suggest that intermediate file got different name scheme so this error will not happen again

Interesting. This is not the case I have, since the 4 workers have quite different exponents in progress.

05/04/2020  11:25 AM       118,384,064 p315690521
05/04/2020  11:25 AM       143,342,228 p382245613
11/22/2018  05:38 PM        30,647,312 p81725849
05/04/2020  11:25 AM        11,399,964 p91199161
05/04/2020  11:25 AM        35,665,976 p95108957

[kotenok2000]

When i try to scroll worker window if number of lines is big it scrolls too much.
My mouse settings are set to scroll 3 lines per click

[HLB]

Originally Posted by Prime95

No changes in prime95 to explain that.

We know about the firepower of Prime95 to test the processors and I admire that, since once I have been through it for a few hours I have stability in everything I do, but in order to better test and lower the temperature, there is some less demanding test for the 9900k that keeps it stable in the same way? Maybe some cache settings that I can use correctly for the 9900k? Thank you.

[patnashev]

Sometimes when setting FFT_Increment=1 Gwnum chooses zero-padded FFT which fails immediately.

./sllr64.3.8.23 -d -q"50873*2^1912945+1" -oFFT_Increment=1
Starting Proth prime test of 50873*2^1912945+1
Using zero-padded AVX FFT length 168K, Pass1=896, Pass2=192, clm=2, a = 3
Iter: 1/1912960, ERROR: ROUND OFF (0.5) > 0.4
Continuing from last save file.
Starting Proth prime test of 50873*2^1912945+1
Using zero-padded AVX FFT length 168K, Pass1=896, Pass2=192, clm=2, a = 3
Iter: 1/1912960, ERROR: ROUND OFF (0.5) > 0.4
Unrecoverable error, Restarting with next larger FFT length...
Continuing from last save file.
Starting Proth prime test of 50873*2^1912945+1
Using all-complex AVX FFT length 192K, Pass1=256, Pass2=768, clm=2, a = 3

[kruoli]

When running a throughput benchmark with a 32M FFT on a Ryzen 3600, it simply states "throughput benchmark complete" with nothing done. The results.bench.txt will contain the hwloc output and Prime95 64-bit version 29.8, RdtscTiming=1, nothing else. When timing an exponent that needs 32M FFTs, everything runs fine.

[Cruelty]

As mentioned in March 2019 something has changed in P95 affinity handling between win64 version 29.4 and 29.6 and is carried up till latest build of 29.8.
I have two AVX-512 machines: i9-7900X and i7-7820X.
On i9 I've gave up using single P95 with two workers and setting affinity in local.txt (2x3 threads setting), instead I am setting only CoresPerTest=3 and launching two separate P95 instances using batch file

start "name" /affinity x prime95.exe

, effectively limiting each instance to chosen CPU cores. On this i9 CPU affinity was not working properly even with one worker (P95 was choosing different cores than indicated in affinity setting, and changing this during work).
On i7 affinity setting works and P95 sticks to preconfigured CPU cores - which makes me think: can it be related to the number of CPU cores present?

[kruoli]

Something else I observed is that when I am running multiple workers needing high memory (as in ECM or P-1), it will randomly (i. e. without observable circumstances) interrupt a worker in its second stage stating multiple times "Available memory is x MB \\ Using y MB of memory" and then reinitializing it again from the last known point of work. This does occur with some time in between. For small exponents that extra work seems to be negligible, but when doing small exponent ECM and additionally "normal" P-1 simoultaneously, it will can and will slow down the latter noticably.

This is not limited to some specific CPU. It is not limited to a specific CPU vendor, neither. I tested some i5's and i7's from 2nd to 9th Gen, also AMD Ryzen 1st Gen.

[James Heinrich]

Originally Posted by kruoli

multiple workers needing high memory ... interrupt a worker in its second stage stating multiple times

It will do this when one worker finishes its high-memory-usage workload, freeing that memory for the other workers. Everything else being equal, more memory available makes P-1 stage 2 faster, but if it frequently restarts it can easily wipe out all the benefits. I know on my main system which has 45GB available to P-1 but only DDR3-1333, it can take up to 10 minutes to fully start stage 2, so restarting it with a different RAM setting is catastrophic to throughput. For that reason I prefer to just run a single 6-threaded worker rather than multiple workers. Less RAM allocated and/or faster RAM would reduce the throughput hit when restarting stage2 workers.

[kruoli]

Originally Posted by James Heinrich

It will do this when one worker finishes its high-memory-usage workload, freeing that memory for the other workers.

The machine I am writing this on is running two workers (one ECM, one P-1). The interrupt is coming when the other worker's stage 2 is already running for a long time (in my case e. g. ten minutes in). Regarding your explanation, I totally get why the program would do that (and I also observed that previously), but in my case, there seems to be another trigger.

[smonkie]

Originally Posted by franz

Hi,

It's been suggested to me that I share here my experience running Prime95 (v29.8 build 6) on an AMD Threadripper 3970X.

The post is quite long so instead of copy/pasting it here, let me give a link to Level1Techs forum where you will find all the details:

https://forum.level1techs.com/t/amd-...tive-by-design

The conversation is also happening over at Hacker News, with some informative posts:

https://news.ycombinator.com/item?id=22382946

Hopefully you don't mind linking...

Thanks for the great work on Prime95: Over the past weeks I've been peeking at the code (being a C/C++ developer myself, but in the field of rendering) and I'm quite in awe at the level of optimization of this program.

Hi Franz! And the others too. :)

I've read carefully your issue. I've been dealing with the same exact trouble with a 3950X. I first tried it in an Aorus Master X570, and for the love of god I couldn't manage to get it Prime95's small ffts stable at stock settings. I tried many BIOS version, I tried different fan configurations, I tried different RAM modules. I couldn't.

Yesterday I decided to try a new board (X570 Taichi) and even when Prime95 seems to cope a little bit better with UEFI defaults, one worker crashes within the first minutes.

So this is clearly something related with not just a particular brand, rather a general power delivery issue extended to Ryzen boards. It's really a boomer because I love to get all my systems Prime95 stable, it just feels right to have that kind of stability. But can't see how we are going to get over this...

[pepi37]

I become proud owner of AMD 3900X.
So I try to benchmark it with mprime and found one interesting bug.
My CPU has 12 cores ( SMT is turned off)
So I can have 1*12 2*6 3*4 *4*3 6*2 and 12*1 worker
When I start that to benchmark got next error


[Worker #1 Jun 11 01:41:36] Timing 240K all-complex FFT, 12 cores, 3 workers. [Jun 11 01:41:36] Error setting affinity to core #13. There are 12 cores.


Regardless this it looks like benchmark is done. On windows benchmark is not started just finished.