Prime95 version 29.4

[James Heinrich]

Originally Posted by GP2

It might be useful to post SHA256 sums.

The mersenne.ca download mirror now includes options to display MD5 / SHA1 / SHA256 hashes (previously it only displayed MD5)
e.g. http://download.mersenne.ca/gimps

Of course, this is a mirror so it's not impossible that something could have gotten corrupted between the original and my mirror (but hopefully not). If you download from mersenne.org and compare the hash to the one on mersenne.ca it should give you some assurance.

[Dubslow]

Originally Posted by Prime95

Note to all: 29.4 sends interim residues to the server for the 500,000th iteration and every multiple of 5,000,000. This was Madpoo's idea to give us the ability to do a quick(ish) partial check should be want to.

Is this not several MB per instance?

If so, doing this without notification to the user would be a pretty big violation of trust IMO. It should be an easily-configurable option with the default set to "off".

[Prime95]

Originally Posted by Dubslow

Is this not several MB per instance?.

A residue is 16 bytes.

[Dubslow]

Originally Posted by Prime95

A residue is 16 bytes.

Ah, my bad. "interim residues" and "partial check" had me going there. I thought you meant stuff like "redo the last 10,000" or so like is done for a prime report, and such a manner of check does require the full interim reside. Oops

[ATH]

29.4b3 adds this line to prime.txt including all the spaces:

PRPGerbiczCompareIntervalAdj=          1

It should be 1000000 by default.

[Prime95]

Originally Posted by ATH

29.4b3 adds this line to prime.txt including all the spaces:

PRPGerbiczCompareIntervalAdj=          1

It should be 1000000 by default.

This is OK. This setting adjusts the interval downward if you do run into an error. It then slowly drifts back upward as you complete Gerbicz intervals without error. The theory is why rollback a million iterations on a flaky machine, lets increase the overhead a little bit and rollback 100,000 iterations on each error.

[Mark Rose]

I think I found another bug:

Main Menu

1. Test/Primenet
2. Test/Worker threads
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/Preferences
15. Options/Torture Test
16. Options/Benchmark
17. Help/About
18. Help/About PrimeNet Server
Your choice: 16

Benchmark type (0 = Throughput, 1 = FFT timings, 2 = Trial factoring) (0):

FFTs to benchmark
Minimum FFT size (in K) (2048):
Maximum FFT size (in K) (8192):
Benchmark with round-off checking enabled (N):
Benchmark all-complex FFTs (for LLR,PFGW,PRP users) (N):
Limit FFT sizes (mimic older benchmarking code) (N):

CPU cores to benchmark
Number of CPU cores (comma separated list of ranges) (36):
Benchmark hyperthreading (Y):

Throughput benchmark options
Number of workers (comma separated list of ranges) (1,2,10,36):
Benchmark all FFT implementations to find best one for your machine (N):
Time to run each benchmark (in seconds) (15):

Accept the answers above? (Y):
Main Menu

1. Test/Primenet
2. Test/Worker threads
3. Test/Status
4. Test/Stop
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/Preferences
15. Options/Torture Test
16. Options/Benchmark
[Main thread Nov 7 18:22] Starting worker.
17. Help/About
18. Help/About PrimeNet Server
Your choice: [Worker #1 Nov 7 18:22] Worker starting
[Worker #1 Nov 7 18:22] Your timings will be written to the results.txt file.
[Worker #1 Nov 7 18:22] Compare your results to other computers at http://www.mersenne.org/report_benchmarks

[Worker #1 Nov 7 18:22] Benchmarking multiple workers to measure the impact of memory bandwidth
[Worker #1 Nov 7 18:22] Timing 2048K FFT, 36 cores, 1 worker. Average times: 1.69 ms. Total throughput: 592.82 iter/sec.
[Worker #1 Nov 7 18:22] Timing 2048K FFT, 36 cores, 2 workers. [Nov 7 18:22] Error setting affinity to core #37. There are 36 cores.
[Worker #1 Nov 7 18:22] Error setting affinity to core #38. There are 36 cores.
[Worker #1 Nov 7 18:22] Error setting affinity to core #39. There are 36 cores.
[Worker #1 Nov 7 18:22] Error setting affinity to core #40. There are 36 cores.
[Worker #1 Nov 7 18:22] Error setting affinity to core #41. There are 36 cores.
[Worker #1 Nov 7 18:22] Error setting affinity to core #42. There are 36 cores.
[Worker #1 Nov 7 18:22] Error setting affinity to core #43. There are 36 cores.
[Worker #1 Nov 7 18:22] Error setting affinity to core #44. There are 36 cores.
[Worker #1 Nov 7 18:22] Error setting affinity to core #45. There are 36 cores.
[Worker #1 Nov 7 18:22] Error setting affinity to core #46. There are 36 cores.
[Worker #1 Nov 7 18:22] Error setting affinity to core #47. There are 36 cores.
[Worker #1 Nov 7 18:22] Error setting affinity to core #48. There are 36 cores.
[Worker #1 Nov 7 18:22] Error setting affinity to core #49. There are 36 cores.
[Worker #1 Nov 7 18:22] Error setting affinity to core #50. There are 36 cores.
[Worker #1 Nov 7 18:22] Error setting affinity to core #51. There are 36 cores.
[Worker #1 Nov 7 18:22] Error setting affinity to core #52. There are 36 cores.
[Worker #1 Nov 7 18:22] Error setting affinity to core #53. There are 36 cores.
[Worker #1 Nov 7 18:22] Error setting affinity to core #54. There are 36 cores.
[Worker #1] Average times: 1.27, 1.78 ms. Total throughput: 1349.93 iter/sec.

[Prime95]

Originally Posted by Mark Rose

I think I found another bug:

Indeed you did. The 2 worker case (and maybe the 3 and 4 worker cases - I'd have to see the hwloc output) will be wrong. The two worker case is running 18 cores on worker 1 and 36 cores on worker 2.

This bug will only affect Xeon systems (and maybe Threadripper). The bug is in the allocation of cores on systems that contain multiple L3 caches or NUMA-like memory.

[Prime95]

Build 4 now ready. Let me know what I screwed up - the release builds are not a "push button" process.

[rainchill]

When posting new builds perhaps the title of the thread can be edited to reflect the newest build # so it is easier to see a new builds are available without checking the thread?

[Mark Rose]

[Work thread Nov 9 09:16] Iteration: 33260000 / 75572820 [44.01%], ms/iter: 6.942, ETA: 3d 09:35
[Work thread Nov 9 09:16] Hardware errors have occurred during the test!
[Work thread Nov 9 09:16] 1 Gerbicz/double-check errors.
[Work thread Nov 9 09:16] Confidence in final result is excellent.
[Work thread Nov 9 09:17] ERROR: Comparing Gerbicz checksum values failed. Rolling back to iteration 32603177.
[Work thread Nov 9 09:17] Continuing from last save file.
[Work thread Nov 9 09:17] Setting affinity to run helper thread 1 on CPU core #2
[Work thread Nov 9 09:17] Setting affinity to run helper thread 2 on CPU core #3
[Work thread Nov 9 09:17] Setting affinity to run helper thread 3 on CPU core #4
[Work thread Nov 9 09:17] Trying backup intermediate file: p57P2821.bu
[Work thread Nov 9 09:17] Trying backup intermediate file: p57P2821.bu2
[Work thread Nov 9 09:17] Trying backup intermediate file: p57P2821.bu3
[Work thread Nov 9 09:17] Resuming Gerbicz error-checking PRP test of M75572821 using FMA3 FFT length 4032K, Pass1=448, Pass2=9K, clm=4, 4 threads
[Work thread Nov 9 09:17] Iteration: 32603178 / 75572820 [43.14%].
[Work thread Nov 9 09:17] Hardware errors have occurred during the test!
[Work thread Nov 9 09:17] 2 Gerbicz/double-check errors.
[Work thread Nov 9 09:17] Confidence in final result is excellent

Excellent