mersenneforum.org Mersenne software error detection or correction opportunities
 Register FAQ Search Today's Posts Mark Forums Read

 2018-06-24, 14:26 #2 science_man_88     "Forget I exist" Jul 2009 Dumbassville 26·131 Posts Guessing you know -2,-1,0,1,2 before last iteration will all get stuck at an unchanging residue for the rest of the test. Modified LL (starting from a real LL) can be used to check factors as well but it's extremely inefficient.
 2018-06-24, 15:07 #3 kriesel     "TF79LL86GIMPS96gpu17" Mar 2017 US midwest 22·1,481 Posts Yes, and thanks for the reminder on +/-1, and hinting I had left out residue-validity checks from primality testing. For conciseness below I'm using M as the mersenne number's binary representation. In algebra, 1 if it occurs gives -1 as iteration result; -1 repeats. But doesn't -1 represent as M-1? (M-1)^2-2 = M^2 -2M +1 -2 M^2-2M-1 mod M is -1 Wouldn't -1 be represented as M-1 again? Or does the -1 stay in the FP convolution where negative values are native, not wrapped around modulo M? Has either been observed in practice? (64-bit residue 0xfffffffffffffffe, not observed in practice to my knowledge.) +/-2 for s_j is very bad, yields (+/-2)^2-2 = 2. 2 then repeats to the last iteration, unless another error occurs. This has been observed. In CUDALucas 2.06beta April, the repeating residue 0xfffffffffffffffd was observed, after a 2 or -2 in 2.05 was continued with 2.06. That's the 64-bit residue we'd expect for (unsigned) M-2 mod M. And it repeated. I think most known-bad residue cases are already checked for in prime95 and CUDALucas. Not so in clLucas as I recall. The general repeating residue, not otherwise a special value, is not to my knowledge checked for in any primality test software yet. Zero 64-bit residue repeating would be a sign probably of multiple errors reoccurring. Lists of known-bad residues I have collected are: 'cllucas', '0x0000000000000002, 0xffffffff80000000', 'cudalucas', '0x0000000000000000, 0x0000000000000002, 0xfffffffffffffffd', 'cudapm1', '0x0000000000000000, 0x0000000000000001', 'gpuowl', '0x0000000000000000', The programs don't do algebra, they do computations, and need to check for the binary representations that are present. So instead of checking for -1 or -2, they check for the least 64 bits of M-1 or M-2. The clLucas second value is a special case that surfaces when fft length used is much too short, as I recall. Last fiddled with by kriesel on 2018-06-24 at 15:20
 2018-08-06, 17:08 #4 kriesel     "TF79LL86GIMPS96gpu17" Mar 2017 US midwest 22·1,481 Posts legitimate unusual residues in LL If counting LL iterations from s0=4, such that the final iteration is numbered p-2, iteration p-3 in the case of a Mersenne prime produces +- 2(p+1)/2. At p>127, this produces res64=0x0000 0000 0000 0000 or 0xffff ffff ffff ffff legitimately. Error detection must allow for these in LL programs. see also http://www.hoegge.dk/mersenne/resultspenultimate.txt http://www.hoegge.dk/mersenne/penultimate.txt http://www.mersenneforum.org/showthread.php?t=5862
 2018-08-06, 17:36 #5 kriesel     "TF79LL86GIMPS96gpu17" Mar 2017 US midwest 10111001001002 Posts Are there special residues near the end of PRP-3, like there are for LL? I wonder if there are special ending 64-bit residues, for Mersenne primes, that might otherwise appear to be indicative of errors, during PRP-3 sequences.
2018-08-06, 17:50   #6
GP2

Sep 2003

258510 Posts

Quote:
 Originally Posted by kriesel I wonder if there are special ending 64-bit residues, for Mersenne primes, that might otherwise appear to be indicative of errors, during PRP-3 sequences.
Gerbicz error correction for PRP-3 catches a much broader category of error than obviously anomalous bit patterns. So it's probably a moot point. Any special 64-bit residues would be corrected out of existence before you saw them.

2018-08-06, 21:15   #7
kriesel

"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

22×1,481 Posts

Quote:
 Originally Posted by GP2 Gerbicz error correction for PRP-3 catches a much broader category of error than obviously anomalous bit patterns. So it's probably a moot point. Any special 64-bit residues would be corrected out of existence before you saw them.
Gerbicz error detection and recomputation of errored spans of iterations may be pretty bulletproof and is very useful, but it too has limits, at least as implemented and when running on significantly unreliable hardware.

I have one hardware case, which provided a severe test for the Gerbicz check, an old Athlon system, that was sufficiently unreliable in long error runs, that it went far beyond maxing out the prime95 error check counts, to in some cases, logging numbers of consecutive error iterations longer than the prime95 Gerbicz check interval. In that case, some of the errored iterations appear to me to escape recomputation. The Gerbicz check is still in that case effective enough that the retreat on iteration number it makes, substantially lengthens the time estimate to completion, and it logs lots of Gerbicz detected errors and retreats to earlier iteration numbers. Percent complete indicated gradually ramps up, and then drops back. Eventually it reached a point where no net progress was being made in a month, at ~6.8% on a 77M exponent PRP. It was powered off at that point. I'm not sure looking at its logs would be worth Prime95's while, but they could be made available.

A quick perl test program indicates the second to last iteration of a Mersenne prime's PRP3 is -3 (actually Mp-3; 0x[1 or 7] f...fc) at least at small residue < 264 implying exponent <64.

 Similar Threads Thread Thread Starter Forum Replies Last Post kriesel GPU Computing 48 2020-01-14 02:56 preda GPU Computing 14 2017-05-09 07:47 Raman Forum Feedback 72 2013-06-22 07:24 GuloGulo Software 3 2011-01-19 00:36 SPWorley Factoring 7 2009-08-16 00:23

All times are UTC. The time now is 22:10.

Fri Dec 3 22:10:29 UTC 2021 up 133 days, 16:39, 0 users, load averages: 1.52, 1.56, 1.47