20150405, 17:29  #1 
P90 years forever!
Aug 2002
Yeehaw, FL
1110101000100_{2} Posts 
Prime95 version 28.6 / 28.7 (28.7 now available!)
Prime95 version 28.7 build 1 is available. See http://www.mersenneforum.org/showpos...40&postcount=2 or the whatsnew.txt file for a list of new features. See next post for bugs found in this release.
Important:The bug that caused the N1 primality test of 1024*3^1877301+1 to fail in PFGW and LLR was a serious bug. It is triggered by a lengthy carry propagation. I cannot prove that Mersenne LL tests are immune to this bug, although I've rerun dozens of Mersenne prime LL tests and every one passed. The bug affects AVX and FMA computers (more details in a later post). The bug has been present since version 27.1. To be safe, I recommend all users with Sandy Bridge or later CPUs upgrade to this version. Download links: Windows 64bit: ftp://mersenne.org/gimps/p95v287.win64.zip Linux 64bit: ftp://mersenne.org/gimps/p95v287.linux64.tar.gz Mac OS X: ftp://mersenne.org/gimps/p95v287.MacOSX.zip FreeBSD 10 64bit: ftp://mersenne.org/gimps/p95v287.FreeBSD1064.tar.gz Windows 32bit: ftp://mersenne.org/gimps/p95v287.win32.zip Linux 32bit: ftp://mersenne.org/gimps/p95v287.linux32.tar.gz Source: ftp://mersenne.org/gimps/p95v287.source.zip Last fiddled with by Prime95 on 20150810 at 03:08 
20150405, 17:29  #2 
P90 years forever!
Aug 2002
Yeehaw, FL
2^{2}·1,873 Posts 
1) In the rarely used undoc.txt feature, TitleOutputFrequency cannot be less than ScaledOutputFrequency. This worked in some 28.5 versions. Fixed in 28.7.
2) Roundoff errors PRPing 55459*2^159718+1 in 32bit mode. For version 28.7, the maximum exponent that can be tested with a 12K SSE2 FFT has been reduced by 0.5%. 3) Base 2 PRP test of (48591^113291)/48590 using AVX FFTs failed. Fixed in version 28.7. 4) Some have complained about the number of roundoff error warnings (and retries) generated. Prime95 will now warn for roundoffs > 27/64 if near the FFT limit and 26/64 for FFTs not near the limit. Fixed in 28.7. 5) Some Intel CPUs not recognized. Added support for CPUID results from several Atom, Haswell, Broadwell, and Skylake CPUs. Fixed in 28.7. 6) A rare bug in generating the final 64bit residue occurred when the shift count was more than exponent  64. Fixed in 28.8. 7) LLR failed testing 13126*39^852171 using AVX FFTs. This is another example of the carry propagation bug in the add and subtract that was "fixed" in 28.6. A hopefully better fix is now in place for version 28.8. 8) PRP of 10223*2^295880451 generated roundoff errors using 2400K to 2688K FFT. Very rare bug computing number of bits to stuff in each FFT word  computation required more than 53 bits of precision. Fixed in 28.8. Last fiddled with by Prime95 on 20151210 at 02:49 
20150405, 17:35  #3 
"Serge"
Mar 2008
Phi(4,2^7658614+1)/2
9,431 Posts 
Thank you!
I will build LLR with gwnum 28.6 and will rerun multiple random tests against a large collection of results that I have (e.g. from CRUS); if any RES64 mismatches will come up, I will share the statistics. EDIT: no RES64 mismatches so far in 14,000 random doublecheck tests (from 0.25 to 4 hours run time range). 7 known primes reconfirmed. Last fiddled with by Batalov on 20150406 at 07:19 
20150405, 17:38  #4 
Basketry That Evening!
"Bunslow the Bold"
Jun 2011
40<A<43 89<O<88
1C35_{16} Posts 
Head post link needs fixing
"http//www.mersenneforum.org/showpost.php?p=368540&postcount=2" 
20150405, 18:13  #5 
P90 years forever!
Aug 2002
Yeehaw, FL
2^{2}×1,873 Posts 
More on the serious carry propagation bug. The bug was in the adding and subtracting code  not in the main FFT code. The error only occurs if a single carry propagates over more than 8 FFT words (and only if the carry chain starts at one particular FFT word). Assuming, there are about 18 bits per FFT word, the chance that random data would trigger this bug is about 1 in 2^(18*8)  i.e. pretty darn low.
If this bug is so rare, how was it found? Well, when testing a prime number the data in the last one or two iterations is decidedly nonrandom and a single carry propagating over more than eight FFT words can happen. Prime95 uses the addition and subtraction code only when it is doing a "square carefully" operation. Further investigation reveals that during an LL test the only time a square careful operation takes place is when a roundoff error > 0.4 is detected and the iteration is redone. Thus to miss a Mersenne prime, you would need to get a roundoff error in the last one or two nonrandom iterations and trigger the bug in carefully redoing the iteration. For PRP tests, the first 30 and last 30 iterations are always done with a square carefully operation. Thus, a PRP test is much more susceptible to the bug. Though at this time there are no known cases of a PRP test failing due to this bug. P.S. Any tests using onepass FFTs or zeropadded FFTs were unaffected by this bug. Last fiddled with by Prime95 on 20150405 at 22:44 
20150406, 07:09  #6 
∂^{2}ω=0
Sep 2002
República de California
2·5·1,163 Posts 
George: Does your code always check that any carryouts = 0?
I similarly allow for carries propagating at most 8 words, but if this is violated, it trips an error message and assertionexit. Not the most elegant solution, but far better than 'silent failure' which allows the run to continue. One quick way to test the relevant logic is to deliberately use an overlong FFT, say 2x as long as the default value. With < 10 bits per word, one is almost guaranteed to get the kinds of longerthanexpected carry propagations you describe. 
20150406, 08:17  #7 
Just call me Henry
"David"
Sep 2007
Cambridge (GMT/BST)
2·5·587 Posts 
Am I correct in thinking that with different shift counts this wouldn't happen in both. If it did it would be a separate random occurance and the chance of the residues being affected the same way is rediculously unlikely.

20150406, 13:54  #8 
P90 years forever!
Aug 2002
Yeehaw, FL
7492_{10} Posts 
Correct. The different shift counts result in different FFT data. The bug would not affect both LL runs.

20150406, 13:58  #9 
P90 years forever!
Aug 2002
Yeehaw, FL
7492_{10} Posts 

20150406, 15:35  #10  
"Serge"
Mar 2008
Phi(4,2^7658614+1)/2
9,431 Posts 
I can see now why this was happening (that's the carry effect in two runs with different FFT sizes, one correct and one "undercarried"):
Quote:


20150406, 21:44  #11 
Dec 2011
After milion nines:)
2×3^{2}×79 Posts 
I found a bug ( maybe it is feature ) ? :)
If worktodo.txt looks like [Worker #1] PRP=95,10,466002,1 [Worker #2] PRP=95,10,466002,1 then in first window is this [Apr 6 23:42:04] Worker starting [Apr 6 23:42:04] Setting affinity to run worker on any logical CPU. [Apr 6 23:42:04] Setting affinity to run helper thread 1 on any logical CPU. [Apr 6 23:42:04] Starting PRP test of 95*10^4660021 using AVX FFT length 112K, Pass1=448, Pass2=256, 2 threads and in second is this [Apr 6 23:42:04] Waiting 5 seconds to stagger worker starts. [Apr 6 23:42:10] Worker starting [Apr 6 23:42:10] Setting affinity to run worker on any logical CPU. [Apr 6 23:42:10] Setting affinity to run helper thread 1 on any logical CPU. [Apr 6 23:42:10] Resuming PRP test of 95*10^4660021 using AVX FFT length 112K, Pass1=448, Pass2=256, 2 threads [Apr 6 23:42:12] Iteration: 2 / 1548031 [0.00%]. But since PRP is start from zero it is incorrect. Also no calculation or backup file is written for second window... Also in 28.6 I cannot get to work TitleOutputFrequency=5000 ClassicOutput=1 TimingOutput=1 In 28.5 this settings works perfectly, and in any moment I can put mouse on icon and get current status. But in 28.6 this doesnot work :( Last fiddled with by pepi37 on 20150406 at 21:48 Reason: add more info 
Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
Prime95 version 27.3  Prime95  Software  148  20120318 19:24 
Prime95 version 26.3  Prime95  Software  76  20101211 00:11 
Prime95 version 25.5  Prime95  PrimeNet  369  20080226 05:21 
Prime95 version 25.4  Prime95  PrimeNet  143  20070924 21:01 
When the next prime95 version ?  pacionet  Software  74  20061207 20:30 