user entered last entries in results.json.txt overwritten
 

In a non-primenet-connected V29.8b5 instance, in results.json.txt I enter [QUOTE]reported (some date)[/QUOTE]and CRLF on a line following what I manually report, save, and close.
The next result prime95 v29.8b5 enters overwrites such manual entries. This has happened multiple times.
GPU apps don't do that, they merely append to results.txt. My recollection is earlier versions of prime95 did not overwrite such user entries in results.txt, merely appending to whatever's there.

I dont know is reported but if is not: benchmark in 29.8b3(Linux) and 29.8b5 ( Win) is totally broken when you try benchmark on small FFT ( like 192 or 224)

[QUOTE=pepi37;523043]I dont know is reported but if is not: benchmark in 29.8b3(Linux) and 29.8b5 ( Win) is totally broken when you try benchmark on small FFT ( like 192 or 224)[/QUOTE]

Please elaborate. What dialog box inputs? What happens? What CPU?

[QUOTE=Prime95;523044]Please elaborate. What dialog box inputs? What happens? What CPU?[/QUOTE]


Results is attached: Linux version of mprime , latest one and 29.7 and 29.6
Only on 29.6 I got results
[QUOTE]Prime95 64-bit version 29.6, RdtscTiming=1
Timings for 224K FFT length (3 cores, 1 worker): 0.73 ms. Throughput: 1366.25 iter/sec.
Timings for 224K FFT length (3 cores, 2 workers): 1.44, 0.98 ms. Throughput: 1715.73 iter/sec.
Timings for 224K FFT length (3 cores, 3 workers): 1.38, 1.42, 1.47 ms. Throughput: 2109.09 iter/sec.

[/QUOTE]
If I run benchmark on 29.7 and 29.8 I got same result but after line



[QUOTE]Prime95 64-bit version 29.7(8, RdtscTiming=1[/QUOTE]
benchmark dont start , just put me back to menu


Same is on Windows

Very interesting. Please set AffinityVerbosityBench=3 in prime.txt and try the failing test again.

[QUOTE=Prime95;523074]Very interesting. Please set AffinityVerbosityBench=3 in prime.txt and try the failing test again.[/QUOTE]


This solve problem!


[QUOTE]Prime95 64-bit version 29.8, RdtscTiming=1
Timings for 448K FFT length (3 cores, 1 worker): 1.04 ms. Throughput: 958.49 iter/sec.
[Sun Aug 4 19:11:00 2019]
Timings for 448K FFT length (3 cores, 2 workers): 2.22, 1.36 ms. Throughput: 1184.68 iter/sec.
Timings for 448K FFT length (3 cores, 3 workers): 2.17, 2.22, 2.18 ms. Throughput: 1368.89 iter/sec.[/QUOTE]
Thanks!

[QUOTE=pepi37;523081]This solve problem![/QUOTE]

This wasn't supposed to solve the problem! It was only supposed to print out more information to help with debugging.

P.S. Your new output was for the 448K FFT, not the 192K and 224K on which you were reporting problems.

[QUOTE=Prime95;523104]This wasn't supposed to solve the problem! It was only supposed to print out more information to help with debugging.

P.S. Your new output was for the 448K FFT, not the 192K and 224K on which you were reporting problems.[/QUOTE]


But it works on those cases also: if you need I will provide to you.
Also this is benchmark test from my I7-2700K ( HT is off) , look first results, it is absurd ( ten or even more times slower, it should be faster)

[QUOTE=kriesel;522947]In a non-primenet-connected V29.8b5 instance, in results.json.txt I enter reported date and CRLF on a line following what I manually report, save, and close.
The next result prime95 v29.8b5 enters overwrites such manual entries. This has happened multiple times.
GPU apps don't do that, they merely append to results.txt. My recollection is earlier versions of prime95 did not overwrite such user entries in results.txt, merely appending to whatever's there.[/QUOTE]Never mind, false alarm, pilot error (specifically, navigation).

I'm doing some throughput benchmarking on one of my computers and I don't really understand how mprime decides how many times each FFT size gets tested. I have "Benchmark all FFT implementations to find best one for your machine" selected "Y", so is this a fixed, hardcoded number of implementations for each FFT size? If so is it possible that we could get a overall time estimate before the benchmark starts?

So something like:
[code]
You have selected to test 12800 combinations of parameters for 10s each, this is estimated to take about 35h33m
Accept the answers above? (Y):
[/code]

My problem is that its not clear how many different FFT sizes exists for a given range, *and* its not clear how many implementations exist for a given size. So I have no idea how long to expect any benchmark to take. Could be minutes, could be hours, or days.

Or maybe some indication during the benchmark of how progress is going, percent complete?

So for example I started my benchmark on 2560K.
And every time it goes through testing the core count,worker count combinations, it just write "Timing 2560K FFT" again with no indication of the difference from last round. Could it instead print "Timing 2560K FFT, Implementation [2/20]" or whatever the total is so I have some idea if/when it will get past this FFT size?


edit: A couple other benchmark settings related questions:
1) "Benchmark with round-off checking enabled" I don't really get what this option means, is it the error checking? Would it be more accurate timings(truer to real work usage) to enable this?
2) "Benchmark all-complex FFTs (for LLR,PFGW,PRP users)" Again, not sure. Does this mean I should select Y if I intend to do "PRP" worktypes directly through mprime/PrimeNet?

Also I just ran into configuration which seems to cause a repeatable crash on this computer

Dual socket Intel(R) Xeon(R) CPU E5-2697 v2 @ 2.70GHz
mprime 29.8b3
On Ubuntu Server 18.04

[code]
Your choice: 16 │
│
Benchmark type (0 = Throughput, 1 = FFT timings, 2 = Trial factoring) (0): │
│
FFTs to benchmark │
Minimum FFT size (in K) (2560): │
Maximum FFT size (in K) (2560): │
Benchmark with round-off checking enabled (N): │
Benchmark all-complex FFTs (for LLR,PFGW,PRP users) (N): │
│
CPU cores to benchmark │
Number of CPU cores (comma separated list of ranges) (24): 12 │
Benchmark hyperthreading (N): │
│
Throughput benchmark options │
Benchmark all FFT implementations to find best one for your machine (N): │
Number of workers (comma separated list of ranges) (1,2,12): 2 │
Time to run each benchmark (in seconds) (5): │
│
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 │
[Main thread Aug 12 10:54] Starting worker. │
14. Options/Preferences │
15. Options/Torture Test │
16. Options/Benchmark │
17. Help/About │
18. Help/About PrimeNet Server │
Your choice: [Worker #1 Aug 12 10:54] Worker starting │
[Worker #1 Aug 12 10:54] Your timings will be written to the results.txt file. │
[Worker #1 Aug 12 10:54] Compare your results to other computers at http://www.mersenne.org/report_benchmarks │
[Worker #1 Aug 12 10:54] Setting affinity to run worker on CPU core #1 │
[Worker #1 Aug 12 10:54] Affinity set to cpuset 0x01000001 │
[Worker #1 Aug 12 10:54] Benchmarking multiple workers to measure the impact of memory bandwidth │
[Worker #1 Aug 12 10:54] Timing 2560K FFT, 12 cores, 2 workers. [Aug 12 10:54] Setting affinity to run worker on CPU core #1 │
[Worker #1 Aug 12 10:54] Setting affinity to run worker on CPU core #13 │
[Worker #1 Aug 12 10:54] Affinity set to cpuset 0x01000001 │
[Worker #1 Aug 12 10:54] Affinity set to cpuset 0x00000010,0x00001000 │
Floating point exception (core dumped)
[/code]