20150814, 04:16  #23 
May 2004
FRANCE
571 Posts 

20150815, 06:49  #24 
Romulan Interpreter
Jun 2011
Thailand
2^{3}×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 20150815 at 06:54 
20151018, 11:50  #25 
Sep 2011
Germany
A9E_{16} 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 20151018 at 11:51 
20151019, 06:31  #26  
May 2004
FRANCE
571 Posts 
Stop issue?
Quote:
Thank you by advance, an best Regards, Jean 

20151019, 15:59  #27 
Sep 2011
Germany
2·3^{2}·151 Posts 

20151105, 23:24  #28 
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 64bit 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 allcomplex 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 allcomplex 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 allcomplex 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 allcomplex 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 allcomplex 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 allcomplex 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 [N1, BrillhartLehmerSelfridge] Running N1 test using base 3 Special modular reduction using allcomplex 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 N1 test using base 5 Special modular reduction using allcomplex 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 N1 test using base 7 Special modular reduction using allcomplex AVX FFT length 2880K, Pass1=640, Pass2=4608 on 10223*2^29588045+1 N1: 10223*2^29588045+1 1/29588060 mro=0.4921875 (appears to run normally from this point) 
20151106, 00:08  #29 
Sep 2012
New Jersey, USA
3B_{16} Posts 
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. Last fiddled with by JimB on 20151106 at 00:10 
20151106, 06:08  #30 
Sep 2011
Germany
2·3^{2}·151 Posts 
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.

20151106, 11:19  #31 
Nov 2010
5^{2} Posts 

20151106, 11:20  #32  
May 2004
FRANCE
1000111011_{2} Posts 
Quote:
Regards, Jean 

20151106, 11:36  #33 
Nov 2010
25_{10} 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 roundoff 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/inifile option)?  Iain 
Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
LLR Version 3.8.20 released  Jean Penné  Software  30  20180813 20:00 
LLR Version 3.8.19 released  Jean Penné  Software  11  20170223 08:52 
LLR Version 3.8.11 released  Jean Penné  Software  37  20140129 16:32 
LLR Version 3.8.9 released  Jean Penné  Software  37  20131031 08:45 
llr 3.8.2 released as devversion  opyrt  Prime Sierpinski Project  11  20101118 18:24 