Should I abandon this test?

[kriesel]

Originally Posted by paulunderwood

You can be very confident with any number of Gerbicz errors.

Seconded, emphatically. I once had an Athlon 3200+ system running PRP/GEC. It got sufficiently unreliable that it ceased making progress entirely. The GEC is that reliable at detecting errors.Several HUNDRED times better than LL/Jacobi. Most if not all PRP results reported in error had errors outside the PRP code that's protected by GEC. (Imagine completing an entire PRP sequence perfectly. Then, after the final res64 value is obtained, a single bit error occurs in producing the result file output.) See also the latter portion of
https://www.mersenneforum.org/showpo...40&postcount=4

[Prime95]

Originally Posted by kriesel

The GEC is that reliable at detecting errors.Several HUNDRED [thousand order of magnitude] times better than LL/Jacobi.

Several HUNDRED thousand orders of magnitude

Fixed that for you :)

[kriesel]

Originally Posted by Prime95

Several HUNDRED thousand orders of magnitude

Fixed that for you :)

Not really. Observed error rate in LL tests is ~1-4% each. Observed error rate in PRP tests was ~24. ppm over a specific 2 year period examined. 2%/~24ppm is ~833:1.

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 number-theoretical GEC reliability expectations, for GEC-guarded 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 double-LL-tested 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 2019-08-12 to 2021-08-12 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 ~2020-10-04 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 PRP-CF 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 check-guarded-code, 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.

[JuanTutors]

Originally Posted by kriesel

(Imagine completing an entire PRP sequence perfectly. Then, after the final res64 value is obtained, a single bit error occurs in producing the result file output.)[/url]

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.