LLR Version 3.8.16 released - Page 3

Jean Penné · 2015-08-14, 04:16

Quote:

Originally Posted by pepi37

Linux binaries on your page is newest?

All binaries are now newest!
Jean

LaurV · 2015-08-15, 06:49

May I please request a feature?

Periodical (30 minutes? setable?) backup of the llr.ini file. (If the feature exists, please tell me how to manage it).
Or "safely" modifying it, when a new "k=..." line is added, i.e. a new tmp file is created and modified it (the information is in memory anyhow, it does not need file copy) and then the new tmp is renamed ini, overwriting the older one).

[The reason is that after an unexpected restart of the system, the file can be lost (rubbish is written inside, if the restart happens during the file is open - it happened to me 20 times!), and it is a big pain in the butt to restore the list of k's (in fact, not restore them, but eliminate them from the input files, with srfile, as the primes files still exists, but this is difficult especially when huge files are involved). The file can be lost accidentally even during "normal" work, if it is big and frequently accessed. For example, I am testing R66, all k's, n<10k, and I split the k range (max k~=100M) in few folders, if the .ini file is lost (with all the list of k's) in one folder then the process of filtering the primes and rearranging all the files in all the folders takes more time than the cllr work itself...]

rebirther · 2015-10-18, 11:50

I have a problem with the stop function. I used it before exit the program. After trying to restart the color is green (means active, used a full cpu core) but nothing happened. I think the checkpoint file is ok but the ini file is getting corrupt somehow. I did a trick and checked the last entry in results file, compared with the sievefile and removed all the entries which are already processed. The ini file was deleted and a new was created. I have copied only the primes found from the last ini file and used the stoponprime option. The llr program is working again as it should but there must be a bug somewhere.

I have tried the GUI and the normal llr program with the old ini file but nothing is working.

Jean Penné · 2015-10-19, 06:31

Quote:

Originally Posted by rebirther

I have a problem with the stop function. I used it before exit the program. After trying to restart the color is green (means active, used a full cpu core) but nothing happened. I think the checkpoint file is ok but the ini file is getting corrupt somehow. I did a trick and checked the last entry in results file, compared with the sievefile and removed all the entries which are already processed. The ini file was deleted and a new was created. I have copied only the primes found from the last ini file and used the stoponprime option. The llr program is working again as it should but there must be a bug somewhere.

I have tried the GUI and the normal llr program with the old ini file but nothing is working.

Please, would you send me the problematic sample? I need to reproduce this problem in order to have a chance to fix it!
Thank you by advance, an best Regards,
Jean

rebirther · 2015-10-19, 15:59

Quote:

Originally Posted by Jean Penné

Please, would you send me the problematic sample? I need to reproduce this problem in order to have a chance to fix it!
Thank you by advance, an best Regards,
Jean

I have sent you the folder. Note, its 64bit win but you could change the program to 32bit.

JimB · 2015-11-05, 23:24

At PrimeGrid, we have a Seventeen or Bust candidate that's now failed 33 times. This happened on all three of Windows, Mac and Linux operating systems and with many different processor types. I've been trying to run this candidate manually. Apparently the FFT size is two increments too small. I can make this run with an initial error using -oFFT_Increment=1 or with no errors at all using -oFFT_Increment=2. How do we run this candidate at PrimeGrid without making every other test take longer by incrementing FFT size unnecessarily?

For the console version of LLR 3.8.16 on 64-bit Windows(final version):

C:\test\7>dir cllr64.exe
08/13/2015 05:51 PM 35,793,920 cllr64.exe

C:\test\7>cllr64 -V
LLR Program - Version 3.8.16, using Gwnum Library Version 28.7

C:\test\7>cllr64 -d -q"10223*2^29588045+1"
Starting Proth prime test of 10223*2^29588045+1
Using all-complex AVX FFT length 2400K, Pass1=384, Pass2=6400, a = 3
Iter: 21/29588058, ERROR: ROUND OFF (0.498046875) > 0.4
Continuing from last save file.
Resuming Proth prime test of 10223*2^29588045+1 at bit 2 [0.00%]
Using all-complex AVX FFT length 2400K, Pass1=384, Pass2=6400, a = 3
Iter: 21/29588058, ERROR: ROUND OFF (0.498046875) > 0.4
Unrecoverable error, Restarting with next larger FFT length...
Continuing from last save file.
Resuming Proth prime test of 10223*2^29588045+1 at bit 21 [0.00%]
Using all-complex AVX FFT length 2560K, Pass1=512, Pass2=5K, a = 3
Iter: 23/29588058, ERROR: ROUND OFF (0.494140625) > 0.4
Fatal Error, Check Number = 6, test of 10223*2^29588045+1 aborted

Using 3.8.15:
C:\test\1>cllr64 -d -q"10223*2^29588045+1"
Starting Proth prime test of 10223*2^29588045+1
Using all-complex AVX FFT length 2400K, Pass1=384, Pass2=6400, a = 3
Iter: 21/29588058, ERROR: ROUND OFF (0.498046875) > 0.4
Continuing from last save file.
Unrecoverable error, Restarting with next larger FFT length...
Starting Proth prime test of 10223*2^29588045+1
Using all-complex AVX FFT length 2560K, Pass1=512, Pass2=5K, a = 3
Iter: 23/29588058, ERROR: ROUND OFF (0.494140625) > 0.4
Continuing from last save file.
Unrecoverable error, Restarting with next larger FFT length...
Starting Proth prime test of 10223*2^29588045+1
Using all-complex AVX FFT length 2880K, Pass1=640, Pass2=4608, a = 3
(appears to run normally from this point)

Using a recent version of PFGW
>pfgw64 -tm -V -q"10223*2^29588045+1"
PFGW Version 3.7.10.64BIT.20150809.Win_Dev [GWNUM 28.6]

Primality testing 10223*2^29588045+1 [N-1, Brillhart-Lehmer-Selfridge]
Running N-1 test using base 3
Special modular reduction using all-complex AVX FFT length 2400K, Pass1=384, Pass2=6400 on 10223*2^29588045+1

Detected in MAXERR>0.45 (round off check) in Exponentiator::Iterate
Iteration: 20/29588060 ERROR: ROUND OFF 0.49805>0.45
(Test aborted, try again using the -a1 switch)
Running N-1 test using base 5
Special modular reduction using all-complex AVX FFT length 2560K, Pass1=512, Pass2=5K on 10223*2^29588045+1

Detected in MAXERR>0.45 (round off check) in Exponentiator::Iterate
Iteration: 21/29588060 ERROR: ROUND OFF 0.49219>0.45
(Test aborted, try again using the -a2 (or possibly -a0) switch)
Running N-1 test using base 7
Special modular reduction using all-complex AVX FFT length 2880K, Pass1=640, Pass2=4608 on 10223*2^29588045+1

N-1: 10223*2^29588045+1 1/29588060 mro=0.4921875
(appears to run normally from this point)

JimB · 2015-11-06, 00:08

I see that cllr64 -d -oNextFFTifNearLimit=1 -q"10223*2^29588045+1"
does work properly. LLR increments the FFT size immediately, then does so again about ten seconds later.

rebirther · 2015-11-06, 06:08

Quote:

Originally Posted by JimB

I see that cllr64 -d -oNextFFTifNearLimit=1 -q"10223*2^29588045+1"
does work properly. LLR increments the FFT size immediately, then does so again about ten seconds later.

Jean gave me this -oMaxrestarts=xxx option some times ago, I had a same issue with one number so you can increase the limit to 40 or higher.

IBethune · 2015-11-06, 11:19

Quote:

Originally Posted by rebirther

Jean gave me this -oMaxrestarts=xxx option some times ago, I had a same issue with one number so you can increase the limit to 40 or higher.

That only affects choice of a for a N+/-1 test, not the number of times the FFT length may be incremented.

Jean Penné · 2015-11-06, 11:20

Quote:

Originally Posted by rebirther

Jean gave me this -oMaxrestarts=xxx option some times ago, I had a same issue with one number so you can increase the limit to 40 or higher.

This option is only useful when testing k*b^n+-1 numbers with b ~= 2... (neither Proth nor Riesel candidates).
Regards,
Jean

IBethune · 2015-11-06, 11:36

Hi Jean,

Ideally we don't want to use -oNextFFTIfNearLimit since this will increase the FFT size for many candidates (and we have already seen several higher n completed OK). So the question is this - why does LLR 3.8.15 increment the FFT length from 2400K up to 2880K (and the test succeeds) but LLR 3.8.16 only goes from 2400K up to 2560K and aborts with round-off errors?

Since this is quite a rare case (it seems), it might be better just to increase the number of times the FFT may be incremented before LLR exits to 5 (or maybe even make it a commandline/ini-file option)?

- Iain

2015-08-15, 06:49	#24
LaurV Romulan Interpreter Jun 2011 Thailand 2³×19×61 Posts	May I please request a feature? Periodical (30 minutes? setable?) backup of the llr.ini file. (If the feature exists, please tell me how to manage it). Or "safely" modifying it, when a new "k=..." line is added, i.e. a new tmp file is created and modified it (the information is in memory anyhow, it does not need file copy) and then the new tmp is renamed ini, overwriting the older one). [The reason is that after an unexpected restart of the system, the file can be lost (rubbish is written inside, if the restart happens during the file is open - it happened to me 20 times!), and it is a big pain in the butt to restore the list of k's (in fact, not restore them, but eliminate them from the input files, with srfile, as the primes files still exists, but this is difficult especially when huge files are involved). The file can be lost accidentally even during "normal" work, if it is big and frequently accessed. For example, I am testing R66, all k's, n<10k, and I split the k range (max k~=100M) in few folders, if the .ini file is lost (with all the list of k's) in one folder then the process of filtering the primes and rearranging all the files in all the folders takes more time than the cllr work itself...] Last fiddled with by LaurV on 2015-08-15 at 06:54

2015-10-18, 11:50	#25
rebirther Sep 2011 Germany A9E₁₆ Posts	I have a problem with the stop function. I used it before exit the program. After trying to restart the color is green (means active, used a full cpu core) but nothing happened. I think the checkpoint file is ok but the ini file is getting corrupt somehow. I did a trick and checked the last entry in results file, compared with the sievefile and removed all the entries which are already processed. The ini file was deleted and a new was created. I have copied only the primes found from the last ini file and used the stoponprime option. The llr program is working again as it should but there must be a bug somewhere. I have tried the GUI and the normal llr program with the old ini file but nothing is working. Last fiddled with by rebirther on 2015-10-18 at 11:51

2015-11-05, 23:24	#28
JimB Sep 2012 New Jersey, USA 59 Posts	Problem with a candidate on LLR 3.8.16 At PrimeGrid, we have a Seventeen or Bust candidate that's now failed 33 times. This happened on all three of Windows, Mac and Linux operating systems and with many different processor types. I've been trying to run this candidate manually. Apparently the FFT size is two increments too small. I can make this run with an initial error using -oFFT_Increment=1 or with no errors at all using -oFFT_Increment=2. How do we run this candidate at PrimeGrid without making every other test take longer by incrementing FFT size unnecessarily? For the console version of LLR 3.8.16 on 64-bit Windows(final version): C:\test\7>dir cllr64.exe 08/13/2015 05:51 PM 35,793,920 cllr64.exe C:\test\7>cllr64 -V LLR Program - Version 3.8.16, using Gwnum Library Version 28.7 C:\test\7>cllr64 -d -q"102232^29588045+1" Starting Proth prime test of 102232^29588045+1 Using all-complex AVX FFT length 2400K, Pass1=384, Pass2=6400, a = 3 Iter: 21/29588058, ERROR: ROUND OFF (0.498046875) > 0.4 Continuing from last save file. Resuming Proth prime test of 102232^29588045+1 at bit 2 [0.00%] Using all-complex AVX FFT length 2400K, Pass1=384, Pass2=6400, a = 3 Iter: 21/29588058, ERROR: ROUND OFF (0.498046875) > 0.4 Unrecoverable error, Restarting with next larger FFT length... Continuing from last save file. Resuming Proth prime test of 102232^29588045+1 at bit 21 [0.00%] Using all-complex AVX FFT length 2560K, Pass1=512, Pass2=5K, a = 3 Iter: 23/29588058, ERROR: ROUND OFF (0.494140625) > 0.4 Fatal Error, Check Number = 6, test of 102232^29588045+1 aborted Using 3.8.15:* C:\test\1>cllr64 -d -q"102232^29588045+1" Starting Proth prime test of 102232^29588045+1 Using all-complex AVX FFT length 2400K, Pass1=384, Pass2=6400, a = 3 Iter: 21/29588058, ERROR: ROUND OFF (0.498046875) > 0.4 Continuing from last save file. Unrecoverable error, Restarting with next larger FFT length... Starting Proth prime test of 102232^29588045+1 Using all-complex AVX FFT length 2560K, Pass1=512, Pass2=5K, a = 3 Iter: 23/29588058, ERROR: ROUND OFF (0.494140625) > 0.4 Continuing from last save file. Unrecoverable error, Restarting with next larger FFT length... Starting Proth prime test of 102232^29588045+1 Using all-complex AVX FFT length 2880K, Pass1=640, Pass2=4608, a = 3 (appears to run normally from this point) Using a recent version of PFGW >pfgw64 -tm -V -q"102232^29588045+1" PFGW Version 3.7.10.64BIT.20150809.Win_Dev [GWNUM 28.6] Primality testing 102232^29588045+1 [N-1, Brillhart-Lehmer-Selfridge] Running N-1 test using base 3 Special modular reduction using all-complex AVX FFT length 2400K, Pass1=384, Pass2=6400 on 102232^29588045+1 Detected in MAXERR>0.45 (round off check) in Exponentiator::Iterate Iteration: 20/29588060 ERROR: ROUND OFF 0.49805>0.45 (Test aborted, try again using the -a1 switch) Running N-1 test using base 5 Special modular reduction using all-complex AVX FFT length 2560K, Pass1=512, Pass2=5K on 102232^29588045+1 Detected in MAXERR>0.45 (round off check) in Exponentiator::Iterate Iteration: 21/29588060 ERROR: ROUND OFF 0.49219>0.45 (Test aborted, try again using the -a2 (or possibly -a0) switch) Running N-1 test using base 7 Special modular reduction using all-complex AVX FFT length 2880K, Pass1=640, Pass2=4608 on 102232^29588045+1 N-1: 102232^29588045+1 1/29588060 mro=0.4921875 (appears to run normally from this point)

2015-11-06, 00:08	#29
JimB Sep 2012 New Jersey, USA 3B₁₆ Posts	I see that *cllr64 -d -oNextFFTifNearLimit=1 -q"102232^29588045+1"** does work properly. LLR increments the FFT size immediately, then does so again about ten seconds later. Last fiddled with by JimB on 2015-11-06 at 00:10

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
LLR Version 3.8.20 released	Jean Penné	Software	30	2018-08-13 20:00
LLR Version 3.8.19 released	Jean Penné	Software	11	2017-02-23 08:52
LLR Version 3.8.11 released	Jean Penné	Software	37	2014-01-29 16:32
LLR Version 3.8.9 released	Jean Penné	Software	37	2013-10-31 08:45
llr 3.8.2 released as dev-version	opyrt	Prime Sierpinski Project	11	2010-11-18 18:24

2015-11-06, 11:36	#33
IBethune Nov 2010 25₁₀ Posts	Hi Jean, Ideally we don't want to use -oNextFFTIfNearLimit since this will increase the FFT size for many candidates (and we have already seen several higher n completed OK). So the question is this - why does LLR 3.8.15 increment the FFT length from 2400K up to 2880K (and the test succeeds) but LLR 3.8.16 only goes from 2400K up to 2560K and aborts with round-off errors? Since this is quite a rare case (it seems), it might be better just to increase the number of times the FFT may be incremented before LLR exits to 5 (or maybe even make it a commandline/ini-file option)? - Iain