mersenneforum.org  

Go Back   mersenneforum.org > Great Internet Mersenne Prime Search > Software

Reply
 
Thread Tools
Old 2020-12-19, 01:44   #45
diep
 
diep's Avatar
 
Sep 2006
The Netherlands

26×11 Posts
Default

Quote:
Originally Posted by VBCurtis View Post
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.
diep is offline   Reply With Quote
Old 2020-12-19, 02:15   #46
Happy5214
 
Happy5214's Avatar
 
"Alexander"
Nov 2008
The Alamo City

23×71 Posts
Default

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?
Happy5214 is offline   Reply With Quote
Old 2021-01-13, 19:20   #47
MisterBitcoin
 
MisterBitcoin's Avatar
 
"Nuri, the dragon :P"
Jul 2016
Good old Germany

32516 Posts
Default

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?
MisterBitcoin is offline   Reply With Quote
Old 2021-01-30, 06:31   #48
Happy5214
 
Happy5214's Avatar
 
"Alexander"
Nov 2008
The Alamo City

23·71 Posts
Default

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?
Happy5214 is offline   Reply With Quote
Old 2021-01-30, 11:22   #49
ATH
Einyen
 
ATH's Avatar
 
Dec 2003
Denmark

37·83 Posts
Default

It works on Windows with -oNextFFTifNearLimit=1.

Quote:
- 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...
Code:
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.

Code:
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.

Last fiddled with by ATH on 2021-01-30 at 11:32
ATH is offline   Reply With Quote
Old 2021-02-28, 08:09   #50
Happy5214
 
Happy5214's Avatar
 
"Alexander"
Nov 2008
The Alamo City

23×71 Posts
Default

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.)
Happy5214 is offline   Reply With Quote
Old 2021-02-28, 18:53   #51
Prime95
P90 years forever!
 
Prime95's Avatar
 
Aug 2002
Yeehaw, FL

11·673 Posts
Default

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

Last fiddled with by Prime95 on 2021-02-28 at 19:00
Prime95 is offline   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
LLR Version 3.8.22 released Jean Penné Software 51 2019-04-10 06:04
LLR Version 3.8.19 released Jean Penné Software 11 2017-02-23 08:52
LLR Version 3.8.16 released Jean Penné Software 38 2015-12-10 07:31
LLR Version 3.8.15 released Jean Penné Software 28 2015-08-04 04:51
llr 3.8.2 released as dev-version opyrt Prime Sierpinski Project 11 2010-11-18 18:24

All times are UTC. The time now is 11:42.

Tue Apr 13 11:42:46 UTC 2021 up 5 days, 6:23, 1 user, load averages: 3.08, 2.45, 2.14

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.