False primes - Page 2

VBCurtis · 2006-06-17, 01:29

I'm not sure if Jean implied there was an error during the false-prime run, but there had not been an error in the lresults file for roughly 48 hours before the false prime (814608 was last number with an error, with 841793 the false prime). It's quite possible the computer only has errors in a short window each afternoon, when house temp is above 80 or 82F.. if I get periodic residue mismatches, I'll look into the likely time-of-day of the results.

I am in the process of double-checking everything I've done in the past 4-6 weeks; if all residues match, then we have something of a freak occurence; the more that fail to match, obviously, the more of my work going backwards I'll have to double-check.

I'll post an update with the number of residue mismatches (if any) from the first week's double-checking in a week or so.
-Curtis

Kosmaj · 2006-06-17, 06:25

Curtis, what version of LLR did you use during the initial test of 127*2^841793-1? Is it LLR-3.6.2? For some reasons LLR-3.6.2 is prone to return a false prime on error. Have a look here. Grobie had 6 false residues, out of them 4 were reported as false primes, and only 2 as composites with false residues. Can I suggest you to use the new LLR-3.7.1 for double checking? It has some extra debugging features. For example, you can include
InterimResidues=200000
in your llr.ini file to obtain interim resudues. It's possible that on error LLR sets an interim residue to zero, which is then somehow (by means of so-called non-numbers?) being reproduced till the end of computation and returns a false prime. Choose "InterimResidues" value so that you have at least 5 of them during each LLR test.

And finally, can I suggest that you reduce your OC-ing. I'm afraid 33% (1.8 -> 2.4GHz) is a bit too much. How about 15-20% (up to 2.15GHz)?

VBCurtis · 2006-06-18, 02:11

All tests (original error and double-check) were done with 3.7.0. I'll grab 3.7.1 presently.

I've overclocked all of my machines for 8+ years, using Prime95 torture test to test for stability. I'm embarassed that enough dust built up in my case to cause my OC to be unstable, but I'm quite confident (pending these double-checks) after cleaning that backing off the settings just a few percentage points from the previous settings will result in an error-free system. However, I will do nothing but double-check previous work until I've thoroughly discussed the number of errors found when comparing residues.

P4s of this generation OCed frequently to 2600-2700 stably; I erred in ignoring dust levels after 18 months of stability at 2500. My temps are now 9F lower than the conditions that caused the errors; combined with the lower frequency, this is quite a bit of headroom.

Kosmaj · 2006-06-18, 03:04

I think 3.7.0 and 3.7.1 don't differ a lot (if at all) with respect to testing k*2^n-1. Just be sure to include InterimResidues in your llr.ini file. Thanks!

Cruelty · 2006-06-19, 10:30

I am also overclocking CPUs for quite some time, and found out that over time you have to slightly decrease OC to maintain stability... especially during summer-time

Kosmaj · 2006-09-10, 02:57

I just changed the name of the thread, it was "False Primes k=127" but now we have one more: 103*2^472831-1.

As we discussed, this is with a large probability due to CPU over-heating and/or bad RAM. The probability that LLR is producing false primes on stable/good hardware is minimal.

To avoid further problems, please:
1) Reduce or stop over-clocking, be sure that your machine is stable.
2) If you have sudden application crashes or blue screens indicating bad RAM, stop using that machine for LLR, until you find out what is wrong.
3) Double check primes reported by LLR using pfgw, run either
pfgw -tp -q103*2^472831-1 (full proof), or just
pfgw -q103*2^472831-1 which will indicate 3-PRP but it may be enough.

Not that (3) is just to avoid reporting false primes, the possibility of missed primes remain.

sjtjung · 2006-09-11, 01:05

Yeah... I figured that I shouldn't post that result when I'm practically testing the new setting on my computer. I believe over-heating is the main problem of that composite prime (at around 54 degress celcius). I'll be more careful next time.

-Steven

Kosmaj · 2007-03-28, 02:26

What happened with

53*2^548810-1 is not prime. Res64: 9907F0E5FE05C6BA

Verification on Top-5000 failed. Have you mistyped it or was it a hardware (or software) error. Note that latest versions of LLR often report false primes when something goes wrong during computation.

BTW, if it's not a secret

can you tell us what k < 300 you are working on on your own, to mark them reserved on our stats page. Thanks!

SB2 · 2007-03-28, 10:56

Quote:

Originally Posted by Kosmaj

What happened with

53*2^548810-1 is not prime. Res64: 9907F0E5FE05C6BA

Verification on Top-5000 failed. Have you mistyped it or was it a hardware (or software) error. Note that latest versions of LLR often report false primes when something goes wrong during computation.

BTW, if it's not a secret

can you tell us what k < 300 you are working on on your own, to mark them reserved on our stats page. Thanks!

I noticed! The one time I did not double check (long story involving nagging to "hurry let's go!" from the better half) it fails.

It's a hardware or heat problem on that system. To be safe I'm shutting down LLR testing until I have time to run Prime95's stress test on all 35 systems again.

53 & 47

2006-09-11, 01:05	#18
sjtjung Mar 2006 Columbus, OH 7·11 Posts	Yeah... I figured that I shouldn't post that result when I'm practically testing the new setting on my computer. I believe over-heating is the main problem of that composite prime (at around 54 degress celcius). I'll be more careful next time. -Steven Last fiddled with by sjtjung on 2006-09-11 at 01:06

2007-03-28, 02:26	#19
Kosmaj Nov 2003 2×1,811 Posts	SB2 What happened with 53*2^548810-1 is not prime. Res64: 9907F0E5FE05C6BA Verification on Top-5000 failed. Have you mistyped it or was it a hardware (or software) error. Note that latest versions of LLR often report false primes when something goes wrong during computation. BTW, if it's not a secret can you tell us what k < 300 you are working on on your own, to mark them reserved on our stats page. Thanks!

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
About two false primes	VBCurtis	Riesel Prime Search	12	2013-01-24 12:02
R.H. May be False? wtf	flouran	Math	34	2009-12-08 00:09
False primes	Unregistered	Information & Answers	8	2009-01-21 01:45
False primes!	MooooMoo	Twin Prime Search	23	2007-01-23 17:53
Four False Primes	amphoria	Riesel Prime Search	74	2006-03-12 11:45

2006-06-17, 01:29	#12
VBCurtis "Curtis" Feb 2005 Riverside, CA 4861₁₀ Posts	I'm not sure if Jean implied there was an error during the false-prime run, but there had not been an error in the lresults file for roughly 48 hours before the false prime (814608 was last number with an error, with 841793 the false prime). It's quite possible the computer only has errors in a short window each afternoon, when house temp is above 80 or 82F.. if I get periodic residue mismatches, I'll look into the likely time-of-day of the results. I am in the process of double-checking everything I've done in the past 4-6 weeks; if all residues match, then we have something of a freak occurence; the more that fail to match, obviously, the more of my work going backwards I'll have to double-check. I'll post an update with the number of residue mismatches (if any) from the first week's double-checking in a week or so. -Curtis

2006-06-17, 06:25	#13
Kosmaj Nov 2003 2×1,811 Posts	Curtis, what version of LLR did you use during the initial test of 127*2^841793-1? Is it LLR-3.6.2? For some reasons LLR-3.6.2 is prone to return a false prime on error. Have a look here. Grobie had 6 false residues, out of them 4 were reported as false primes, and only 2 as composites with false residues. Can I suggest you to use the new LLR-3.7.1 for double checking? It has some extra debugging features. For example, you can include InterimResidues=200000 in your llr.ini file to obtain interim resudues. It's possible that on error LLR sets an interim residue to zero, which is then somehow (by means of so-called non-numbers?) being reproduced till the end of computation and returns a false prime. Choose "InterimResidues" value so that you have at least 5 of them during each LLR test. And finally, can I suggest that you reduce your OC-ing. I'm afraid 33% (1.8 -> 2.4GHz) is a bit too much. How about 15-20% (up to 2.15GHz)?

2006-06-18, 02:11	#14
VBCurtis "Curtis" Feb 2005 Riverside, CA 4,861 Posts	All tests (original error and double-check) were done with 3.7.0. I'll grab 3.7.1 presently. I've overclocked all of my machines for 8+ years, using Prime95 torture test to test for stability. I'm embarassed that enough dust built up in my case to cause my OC to be unstable, but I'm quite confident (pending these double-checks) after cleaning that backing off the settings just a few percentage points from the previous settings will result in an error-free system. However, I will do nothing but double-check previous work until I've thoroughly discussed the number of errors found when comparing residues. P4s of this generation OCed frequently to 2600-2700 stably; I erred in ignoring dust levels after 18 months of stability at 2500. My temps are now 9F lower than the conditions that caused the errors; combined with the lower frequency, this is quite a bit of headroom.

2006-06-18, 03:04	#15
Kosmaj Nov 2003 2×1,811 Posts	I think 3.7.0 and 3.7.1 don't differ a lot (if at all) with respect to testing k2^n-1. Just be sure to include InterimResidues* in your llr.ini file. Thanks!

2006-06-19, 10:30	#16
Cruelty May 2005 2³×7×29 Posts	I am also overclocking CPUs for quite some time, and found out that over time you have to slightly decrease OC to maintain stability... especially during summer-time

2006-09-10, 02:57	#17
Kosmaj Nov 2003 E26₁₆ Posts	I just changed the name of the thread, it was "False Primes k=127" but now we have one more: 1032^472831-1. As we discussed, this is with a large probability due to CPU over-heating and/or bad RAM. The probability that LLR is producing false primes on stable/good hardware is minimal. To avoid further problems, please: 1) Reduce or stop over-clocking, be sure that your machine is stable. 2) If you have sudden application crashes or blue screens indicating bad RAM, stop using that machine for LLR, until you find out what is wrong. 3) Double check primes reported by LLR using pfgw, run either pfgw -tp -q1032^472831-1 (full proof), or just pfgw -q1032^472831-1 which will indicate 3-PRP but it may be enough. Not that (3) is just to avoid reporting* false primes, the possibility of missed primes remain.