LLR version 3.8.24 released.

[diep]

Originally Posted by VBCurtis

You really shouldn't be trying to defeat the LLR decision to use the bigger FFT. A silent rounding error, while unlikely, is possible. I'd rather do one test at 25k seconds than a set of double-checks at 18k sec each because the results aren't as trustworthy.

The rounding error seems to sometimes happen when the FFT length is not far from taking the next increase. As i'm not so long inside the next increase i feel pretty safe there.

So for example the first problem i got here was at

proces 1 : 32767*2^4150241-1 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^4157121-1 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^4158993-1 at iteration 1424769 [34.25%]
32767*2^4158993-1 is not prime. LLR Res64: 7A567993821E36DA Time : 17787.690 sec.

Also close to 4.16M

proces 3:
32767*2^4163073-1 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^4163841-1 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^4159313-1 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^4161489-1 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^4161489-1 at iteration 98335 [2.36%]
32767*2^4161489-1 is not prime. LLR Res64: F365133D3BB48CDF Time : 21613.205 sec.

Also close to 4.16M.

[Happy5214]

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?

[MisterBitcoin]

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 hick-up?

[Happy5214]

The number 52955*2^198566-1 repeatedly fails the Gerbicz check with AVX (15K FFT length) on Windows 8.1 (64-bit OS, 32-bit LLR), causing an infinite loop and an eventual crash. The number tests normally on Linux using both type-1 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?

[ATH]

It works on Windows with -oNextFFTifNearLimit=1.

- For those wo do not like to force error checking, I implemented a new
option : -oNextFFTifNearLimit=1 (default is zero). If activated, and if the
default FFT length at setting is too near the limit, then, FFT_Increment is
incremented by one, a message is displayed and the test is immediatly
restarted ; indeed, in this case, echk can no more be forced...

cllr.exe -d -q"52955*2^198566-1" -oNextFFTifNearLimit=1
Current FFT beeing too near the limit, next FFT length is forced...
Starting Fermat PRP test of 52955*2^198566-1
Using AVX FFT length 16K, Pass1=256, Pass2=64, clm=2, a = 3
52955*2^198566-1 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.

cllr.exe -d -q"52955*2^198566-1" -oErrorCheck=1
Resuming Fermat PRP test of 52955*2^198566-1 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^198566-1 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^198566-1 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^198566-1 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^198566-1 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^198566-1"
Starting Fermat PRP test of 52955*2^198566-1
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^198566-1 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^198566-1 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^198566-1 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^198566-1 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^198566-1 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.

[Happy5214]

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.)

[Prime95]

Prime95 tests 52955*2^198566-1 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":"PRP-3", "res64":"F3DFDEE863FF14C1", "residue-type":1, "fft-length":15360, "error-code":"00000000", "security-code":"44C96115", "program":{"name":"Prime95", "version":"30.4", "build":9, "port":4}, "timestamp":"2021-02-28 18:48:12", "errors":{"gerbicz":0}, "proof":{"version":2, "power":5, "hashsize":64, "md5":"7135b3cf6e5b3aa2519302b4faa66f39"}, "user":"gw_2", "computer":"x64-debug"}

Edit: My bad. That was with 64-bit prime95, testing 32-bit prime95 now.

Edit2: 32-bit prime95 also reports roundoff of 0.344