20201219, 01:44  #45  
Sep 2006
The Netherlands
2^{6}×11 Posts 
Quote:
So for example the first problem i got here was at proces 1 : 32767*2^41502411 is not prime. LLR Res64: 65B3BF50D94E6A58 Time : 17524.087 sec. Iter: 647351/4152080, ERROR: ROUND OFF (0.4375) > 0.4 Continuing from last save file. So at 4.15M which is close to the next increase at 4.16M proces 2: 32767*2^41571211 is not prime. LLR Res64: 1E3B0D7CC9B9EE93 Time : 15966.340 sec. Iter: 1614226/4158992, ERROR: ROUND OFF (0.4375) > 0.4 Continuing from last save file. Resuming LLR test of 32767*2^41589931 at iteration 1424769 [34.25%] 32767*2^41589931 is not prime. LLR Res64: 7A567993821E36DA Time : 17787.690 sec. Also close to 4.16M proces 3: 32767*2^41630731 is not prime. LLR Res64: AEF3BE86379E13DE Time : 17503.145 sec. Iter: 892365/4163840, ERROR: ROUND OFF (0.4375) > 0.4 Continuing from last save file. Resuming LLR test of 32767*2^41638411 at iteration 648321 [15.57%] Disregard last error. Result is reproducible and thus not a hardware problem. For added safety, redoing iteration using a slower, more reliable method. That's even closer to the jump at 4.168M and first error at proces 4: 32767*2^41593131 is not prime. LLR Res64: 17ECE1E45391CA65 Time : 17019.632 sec. Iter: 98335/4161488, ERROR: ROUND OFF (0.40625) > 0.4 Continuing from last save file. Resuming LLR test of 32767*2^41614891 at iteration 2 [0.00%] Disregard last error. Result is reproducible and thus not a hardware problem. For added safety, redoing iteration using a slower, more reliable method. Continuing from last save file. Resuming LLR test of 32767*2^41614891 at iteration 98335 [2.36%] 32767*2^41614891 is not prime. LLR Res64: F365133D3BB48CDF Time : 21613.205 sec. Also close to 4.16M. 

20201219, 02:15  #46 
"Alexander"
Nov 2008
The Alamo City
2^{2}×149 Posts 
Another thing I just noticed is that your log has LLR residues. This is the v3.8.24 thread, and this version now defaults to Fermat PRP testing (with Gerbicz check) for Riesel prime candidates. What gives?

20210113, 19:20  #47 
"Nuri, the dragon :P"
Jul 2016
Good old Germany
2×13×31 Posts 
Just a question, while testing an automatic k removal script i noticed (not for the first time) that cllr sometimes not copys the first line from the input file (e.g. like this 100000007:M:1:7:258) into the res file.
Is there a command for the ini to force cllr to write that line; or is that just a random hickup? 
20210130, 06:31  #48 
"Alexander"
Nov 2008
The Alamo City
254_{16} Posts 
The number 52955*2^1985661 repeatedly fails the Gerbicz check with AVX (15K FFT length) on Windows 8.1 (64bit OS, 32bit LLR), causing an infinite loop and an eventual crash. The number tests normally on Linux using both type1 SSE2 (16K) and FMA3 (15K) (both with residue F3DFDEE863FF14C1). Can LLR maybe try using a larger FFT length or something if it detects a repeated failure like this?

20210130, 11:22  #49  
Einyen
Dec 2003
Denmark
2×7×223 Posts 
It works on Windows with oNextFFTifNearLimit=1.
Quote:
Code:
cllr.exe d q"52955*2^1985661" oNextFFTifNearLimit=1 Current FFT beeing too near the limit, next FFT length is forced... Starting Fermat PRP test of 52955*2^1985661 Using AVX FFT length 16K, Pass1=256, Pass2=64, clm=2, a = 3 52955*2^1985661 is not prime. RES64: F3DFDEE863FF14C1. Time : 21.031 sec. If you set error checking on without oNextFFTifNearLimit=1, it finds a ROUND OFF error and just keeps retrying in a loop. Instead it should probably raise FFT size by itself? Without both NextFFT and error checking it goes in a loop failing Gerbicz checksum, maybe it should also try to raise FFT size after a few failures? or add error checking by itself and then raise FFT after a few round off errors. Code:
cllr.exe d q"52955*2^1985661" oErrorCheck=1 Resuming Fermat PRP test of 52955*2^1985661 at bit 3823 [1.92%] Using AVX FFT length 15K, Pass1=320, Pass2=48, clm=1, a = 3 Bit: 4929/198581, ERROR: ROUND OFF (0.5) > 0.421875 Continuing from last save file. Resuming Fermat PRP test of 52955*2^1985661 at bit 3823 [1.92%] Using AVX FFT length 15K, Pass1=320, Pass2=48, clm=1, a = 3 Bit: 4929/198581, ERROR: ROUND OFF (0.5) > 0.421875 Continuing from last save file. Resuming Fermat PRP test of 52955*2^1985661 at bit 3823 [1.92%] Using AVX FFT length 15K, Pass1=320, Pass2=48, clm=1, a = 3 Bit: 4929/198581, ERROR: ROUND OFF (0.5) > 0.421875 Continuing from last save file. Resuming Fermat PRP test of 52955*2^1985661 at bit 3823 [1.92%] Using AVX FFT length 15K, Pass1=320, Pass2=48, clm=1, a = 3 Bit: 4929/198581, ERROR: ROUND OFF (0.5) > 0.421875 Continuing from last save file. Resuming Fermat PRP test of 52955*2^1985661 at bit 3823 [1.92%] Using AVX FFT length 15K, Pass1=320, Pass2=48, clm=1, a = 3 Bit: 4929/198581, ERROR: ROUND OFF (0.5) > 0.421875 Continuing from last save file. cllr.exe d q"52955*2^1985661" Starting Fermat PRP test of 52955*2^1985661 Using AVX FFT length 15K, Pass1=320, Pass2=48, clm=1, a = 3 ERROR: Comparing Gerbicz checksum values failed. Rolling back to iteration 15. Continuing from last save file. Resuming Fermat PRP test of 52955*2^1985661 at bit 16 [0.00%] Using AVX FFT length 15K, Pass1=320, Pass2=48, clm=1, a = 3 ERROR: Comparing Gerbicz checksum values failed. Rolling back to iteration 15. Continuing from last save file. Resuming Fermat PRP test of 52955*2^1985661 at bit 16 [0.00%] Using AVX FFT length 15K, Pass1=320, Pass2=48, clm=1, a = 3 ERROR: Comparing Gerbicz checksum values failed. Rolling back to iteration 15. Continuing from last save file. Resuming Fermat PRP test of 52955*2^1985661 at bit 16 [0.00%] Using AVX FFT length 15K, Pass1=320, Pass2=48, clm=1, a = 3 ERROR: Comparing Gerbicz checksum values failed. Rolling back to iteration 15. Continuing from last save file. Resuming Fermat PRP test of 52955*2^1985661 at bit 16 [0.00%] Using AVX FFT length 15K, Pass1=320, Pass2=48, clm=1, a = 3 ERROR: Comparing Gerbicz checksum values failed. Rolling back to iteration 3859. Continuing from last save file. Resuming Fermat PRP test of 52955*2^1985661 at bit 3860 [1.94%] Using AVX FFT length 15K, Pass1=320, Pass2=48, clm=1, a = 3 ERROR: Comparing Gerbicz checksum values failed. Rolling back to iteration 4820. Continuing from last save file. Last fiddled with by ATH on 20210130 at 11:32 

20210228, 08:09  #50 
"Alexander"
Nov 2008
The Alamo City
1124_{8} Posts 
I'm not sure where to post, but I wonder what the adoption rate of this new version is, and specifically the usage of Fermat PRP tests with the Gerbicz check for Riesel prime candidates. When will it be safe to use this version in collaborative settings (e.g. PRPNet servers) without the incompatible residues being an issue? (This really, really needed a different version number for that reason.)

20210228, 18:53  #51 
P90 years forever!
Aug 2002
Yeehaw, FL
7·1,069 Posts 
Prime95 tests 52955*2^1985661 with a maximum roundoff error of 0.344 using a 15K AVX FFT. That's high, but no where near dangerous. A bit strange that LLR is getting a much larger roundoff error.
{"status":"C", "k":52955, "b":2, "n":198566, "c":1, "worktype":"PRP3", "res64":"F3DFDEE863FF14C1", "residuetype":1, "fftlength":15360, "errorcode":"00000000", "securitycode":"44C96115", "program":{"name":"Prime95", "version":"30.4", "build":9, "port":4}, "timestamp":"20210228 18:48:12", "errors":{"gerbicz":0}, "proof":{"version":2, "power":5, "hashsize":64, "md5":"7135b3cf6e5b3aa2519302b4faa66f39"}, "user":"gw_2", "computer":"x64debug"} Edit: My bad. That was with 64bit prime95, testing 32bit prime95 now. Edit2: 32bit prime95 also reports roundoff of 0.344 Last fiddled with by Prime95 on 20210228 at 19:00 
20210421, 00:53  #52 
P90 years forever!
Aug 2002
Yeehaw, FL
7×1,069 Posts 
I don't know if Jean Penne is still the maintainer of LLR, but gwnum version 30.6 has some new features that might speed up LLR.

20210421, 04:05  #53 
Jun 2012
Boulder, CO
100011000_{2} Posts 
Curious to know more  for all inputs or numbers of a certain form? Should it be faster "out of the box" or does it require changes to the LLR code too?

20210421, 05:19  #54  
P90 years forever!
Aug 2002
Yeehaw, FL
7×1,069 Posts 
Quote:
The biggest change is "combo" functions, like (a+b)*c. This can be done with 3 reads and 1 write. Compare that to separate calls: a+b (2 reads, 1 write), sum * c (2 reads, 1 write). On modern CPUs that are memory bandwidth limited, saving one read and write is significant. The second opportunity for improving performance is new functions that better track when a normalized add is required vs. an unnormalized add. Again, careful programming is required. 

20210423, 06:08  #55 
"Alexander"
Nov 2008
The Alamo City
2^{2}×149 Posts 

Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
LLR Version 3.8.22 released  Jean Penné  Software  51  20190410 06:04 
LLR Version 3.8.19 released  Jean Penné  Software  11  20170223 08:52 
LLR Version 3.8.16 released  Jean Penné  Software  38  20151210 07:31 
LLR Version 3.8.15 released  Jean Penné  Software  28  20150804 04:51 
llr 3.8.2 released as devversion  opyrt  Prime Sierpinski Project  11  20101118 18:24 