Double-checking attempts and successes

[piforbreakfast]

I'm reconfiguring my main computers to do primarily double-checking 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/

[S485122]

At submission a Double-Check 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.

[piforbreakfast]

Originally Posted by S485122

At submission a Double-Check 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.

But there's no risk of missing a prime since there would have been an indication on the first test that M may be prime?

[kruoli]

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.

[S485122]

Originally Posted by piforbreakfast

But there's no risk of missing a prime since there would have been an indication on the first test that M may be prime?

No : "prime" results get a manual treatment anyway and this is something independent of the calculation of "Success" in the report you speak off.

(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 "Double-Checking 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".

[kriesel]

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 all-zeros, 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 all-zero 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

[Viliam Furik]

Originally Posted by kruoli

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.

The chance of the last 64 bits of random residues matching is, ignoring the 0x00 and 0x02, 1 in 2⁶⁴, which is about 1.8446744e+19, which is less than the ten-billion human-second century (https://www.youtube.com/watch?v=8Ko3TdPy0TU), but considering the GIMPS has been around for about 25 years, has far less than 10 billion participants, and (sadly) does not produce a test result every second, it's safe to say that it has never occurred.

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.

[firejuggler]

let me show you an ancient case
https://www.mersenne.org/report_expo...exp_lo=6225623

2 bad result followed by a LL/DC

[Viliam Furik]

Originally Posted by firejuggler

let me show you an ancient case
https://www.mersenne.org/report_expo...exp_lo=6225623

2 bad result followed by a LL/DC

But the bad residues are not matching. In the above post, I was describing the probability of two bad residues randomly matching.

[kriesel]

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.

[Madpoo]

Originally Posted by kriesel

...The most common bad res64 is 0x00; the second is 0x02, which occur systematically, not randomly....

That's generally true, if by "most common" you mean the bad residues with the highest counts.

However, most bad results simply have a totally wrong (and random-ish) 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.