![]() |
|
|
#111 |
|
Dec 2011
After milion nines:)
26458 Posts |
It will be very useful ( nice option) if LLR delete processed entries from input file.
You can add that in next version
|
|
|
|
|
|
#112 |
|
Dec 2011
After milion nines:)
5·172 Posts |
It looks like I found one bug under Linux LLR3.8.13 ( on windows there is no such problem)
Start dynamically or static version of llr64 3.8.13 using command ./llr64 -d -q"2*7^22581-1" and then stop process ( since this is very small prime you must react quickly) Then resume process and in the end you will get some output like this You can stop process in first phase or in second (Lucas test) but error will be same. Iter: 12412/63392, ERROR: ROUND OFF (3.264928722e+13) > 0.4 Continuing from last save file. 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. Iter: 12412/63392, ERROR: ROUND OFF (3.264928722e+13) > 0.4 Continuing from last save file. Unrecoverable error, Restarting with next larger FFT length... U((N+1)/7) is coprime to N! Time : 7.176 sec. This number is prime ( verified under PFGW and LLR on Win) So if someone reproduce this and verify this... Last fiddled with by pepi37 on 2015-01-26 at 21:42 |
|
|
|
![]() |
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| LLR Version 3.8.18 released [deprecated] | Jean Penné | Software | 43 | 2017-02-20 12:05 |
| LLR Version 3.8.17 released [deprecated] | Jean Penné | Software | 18 | 2017-02-01 12:49 |
| LLR Version 3.8.14 released (deprecated) | Jean Penné | Software | 67 | 2015-05-02 07:24 |
| Prime95 version 28.5 (deprecated, use 28.7) | Prime95 | Software | 162 | 2015-04-05 16:19 |
| Beta version 24.12 available | Prime95 | Software | 33 | 2005-06-14 13:19 |