20211012, 06:12  #1 
Oct 2020
Terre Haute, IN
150_{8} Posts 
Doublechecking attempts and successes
I'm reconfiguring my main computers to do primarily doublechecking and noticed that there is one column listed for DC attempts and the other for successes. What is an unsuccessful DC?
https://www.mersenne.org/report_top_500_lld/ 
20211012, 07:46  #2 
"Jacob"
Sep 2006
Brussels, Belgium
1,777 Posts 
At submission a DoubleCheck test result is counted as a success if it matches (one of the) previous unverified result.
If it doesn't match, it is counted as an attempt but not as a success an an another test is needed. In most cases the previous work was the bad one, but sometimes, the absence of success means a bad result has been returned. Once the result has been tallied by the server as a "Success" or not, subsequent results don't change that any more. In other words, and without a manual intervention in the database, the number of tests that were not counted as a success can only go up. 
20211012, 07:48  #3  
Oct 2020
Terre Haute, IN
68_{16} Posts 
Quote:


20211012, 08:27  #4 
"Oliver"
Sep 2017
Porta Westfalica, DE
348_{16} Posts 
That would only be possible if the original result is bad and your result is bad. In most cases, a TC will then be performed. There is a mathematical, but extremely small chance, that the bad results may match by chance, but that's nothing we have to worry about.

20211012, 08:35  #5  
"Jacob"
Sep 2006
Brussels, Belgium
1,777 Posts 
Quote:
(Supposing an exponent for which there is already a non zero result, if a double check returns a zero result meaning the Mersenne number is prime, it will not be tallied as a "Success" in the "DoubleChecking Top Producers" report, but for all other purposes it will be treated as any "Prime" result.) If you want to know the real success rate of a computer or a user you must compute it based on the "LL results" in the "Detailed reports". 

20211012, 12:28  #6 
"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest
2×3,061 Posts 
LL DC success is when the res64 reported matched another for the same exponent.
The likelihood of two bad runs or one good and one bad matching res64 depends on whether the errors are random or systematic. The most common bad res64 is 0x00; the second is 0x02, which occur systematically, not randomly. CUDALucas ~2.05 and earlier was known for this. If a memcopy or other operation fails in a way that the interim residue becomes allzeros, squaring that and subtracting two gives 2 mod Mp. Squaring and subtracting again starts a loop of +2 until the end. CUDALucas 2.06 tests for early 2 and halts if it finds it. Other LL software also has the issue. Other software can also hit the erroneous allzero condition. I occasionally see it on gpuowl PRP, quickly caught by the GEC. There's more on primality test errors at https://www.mersenneforum.org/showpo...40&postcount=4 
20211012, 16:50  #7  
"Viliam Furík"
Jul 2018
Martin, Slovakia
2·373 Posts 
Quote:
To be specific, assuming an error rate of 2%, and the errors resulting in random residues, we would need to perform about 9.223372e+20 tests on one particular exponent. Assuming a number of 50,000 active computers, each hypothetically outputting one result every second, it would take roughly 584942417.355 years of testing, to expect one single matching duplicate. 

20211012, 17:39  #8 
"Vincent"
Apr 2010
Over the rainbow
5×19×29 Posts 
let me show you an ancient case
https://www.mersenne.org/report_expo...exp_lo=6225623 2 bad result followed by a LL/DC Last fiddled with by firejuggler on 20211012 at 17:41 
20211012, 17:44  #9  
"Viliam Furík"
Jul 2018
Martin, Slovakia
2·373 Posts 
Quote:


20211012, 18:00  #10 
"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest
2·3,061 Posts 
IIRC there are cases of up to 4 bad res64.
If the first two bad res64 results for the same exponent were both bad, and matched, and were not zero or two, how would we know they were bad? Would we even know to check the logs for anomalies? Heck, if one is good, and the other is a bad calculation that by some fluke produces the correct res64 anyway, we would not know. Absolute certainty is hard to obtain. The odds of matching ordinary res64 values indicating two good runs are strongly in our favor, but are not quite equal to 1. Last fiddled with by kriesel on 20211012 at 18:01 
20211101, 19:45  #11  
Serpentine Vermin Jar
Jul 2014
CFC_{16} Posts 
Quote:
However, most bad results simply have a totally wrong (and randomish) residue, so they don't match anything else. Ahem... see this as a very recent result of an exponent with multiple bad runs... special attention for kriesel. LOL M64387151 Just goes to show that the bad results may be the first one, may be the second one... I haven't done any deep analysis of how often the bad result is first, 2nd (or 3rd+) but my general sense of it, having done quite a few triple+ checks, is that generally speaking, the bad one is going to be the first one. Special cases exist where a particular user/computer was consistently turning in bad results. But in general I think computers have just become more reliable over time? I could be wrong. 

Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
Double checking  gd_barnes  Riesel Prime Search  69  20210321 00:54 
Doublechecking PRP  preda  Math  13  20180924 19:37 
Attempts vs. Successes oddity  Rodrigo  GPU Computing  8  20140919 08:44 
Double checking  Unregistered  Information & Answers  19  20110729 09:57 
LLD attempts and successes  Christenson  Information & Answers  1  20110203 05:25 