20211022, 18:20  #12  
"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest
2·11·269 Posts 
Quote:
https://www.mersenneforum.org/showpo...40&postcount=4 

20211022, 23:17  #13 
P90 years forever!
Aug 2002
Yeehaw, FL
3^{2}×853 Posts 

20211023, 12:37  #14  
"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest
2·11·269 Posts 
Quote:
I think we're talking about different things. I was referring to what error rate in practice we see by looking at actual historical data in PrimeNet server reports. Not for numbertheoretical GEC reliability expectations, for GECguarded code spans only, and programmed perfectly from the beginning. from https://www.mersenneforum.org/showpo...40&postcount=4 "Current error rate of final residue from LL testing (in the absence of substantial hardware issues or software misconfiguration or certain logged error types) is around 2% per LL primality test, 4% per doubleLLtested exponent. Error rate rises to around 40% for prime95 LL tests with illegal sumout errors logged. Error rate of final residue from PRP3 with Gerbicz check is quite small by comparison, but nonzero; hardware error or bugs affecting software operation 'outside' the Gerbicz error check of blocks of iterations can occur and affect the results, and have occurred since introduction of the Gerbicz check. Software has been rewritten to reduce the occurrence of errors outside the GEC. An evaluation of PRP errors found and verified results over the period 20190812 to 20210812 for exponents above 77M or above 50M yielded an observed PRP/GEC and PRP/GEC/proof combined error rate of ~24. per million PRP tests (~24 ppm). That's about 800. times lower than the LL without Jacobi check error rate, and corresponds to 3 PRP errors total, at least one of which occurred before the prime95 modification to reduce errors occurring outside the GEC error check, such as handling the final residue value." That was based upon 3 bad PRP results above 77M for the period, versus 123519 records of PRP tests above 77M for the period. 3/123519 ~24.3 ppm. (Yes I still had the downloaded report files.) Similarly, regarding proof verification errors, https://mersenneforum.org/showpost.p...&postcount=476 https://mersenneforum.org/showpost.p...&postcount=405 (yours) & a few following posts ~20201004 discuss a proof error rate of 4/30,000 (133. ppm) and subsequently fixing a gpuowl issue and hardening of the prime95 code. One of which was a PRPCF proof error, likely far below the 77M threshold. So your post, and my reference info text, are probably describing the same 3 error cases. SPEs happen. (Skilled programmer errors) And get dealt with later. https://mersenneforum.org/showpost.p...&postcount=109 https://mersenneforum.org/showthread...22471&p=465431 gave ~2/Mp. https://mersenneforum.org/showpost.p...&postcount=104 ~1/Mp. At super low expected algorithmic error detection miss rate, an occasional random bit flip outside the checkguardedcode, or effect of a proof generation bug, can drastically increase the observed error rate above the expected. (Infinitesimal +3) errors/ ~120000 result reports is dominated by the 3 on a log scale. Last fiddled with by kriesel on 20211023 at 12:41 

20211121, 18:32  #15 
"Juan Tutors"
Mar 2004
13×43 Posts 
Sorry for resurrecting an old thread. The thought just came to me. Is a bad results file not easy to test against? I know that error checking can be done quite confidently, and depending on how rare this is, relative to the importance of having accurate results files, checking against a bad output file could be done with obscene accuracy.

Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
I found the primality test, there seems to be no composite numbers that pass the test  sweety439  sweety439  7  20200211 19:49 
Modifying the Lucas Lehmer Primality Test into a fast test of nothing  Trilo  Miscellaneous Math  25  20180311 23:20 
Double check LL test faster than first run test  lidocorc  Software  3  20081203 15:12 
Will the torture test, test ALL available memory?  swinster  Software  2  20071201 17:54 
A primality test for Fermat numbers faster than Pépin's test ?  T.Rex  Math  0  20041026 21:37 