Error rates and ECC

[S485122]

I just downloaded all LL tests returned in the past year : between 2022-05-30 and 2023-05-29.

Some LL results are unverified or the Mersenne number has been factored, then there are a few duplicate results (same user, final residue and shift, slandrum returned a whole lot on 2022-12-18 and Ryan Popper on 2023-01-06).

Of the remaining 78165 LL results returned between 2022-05-30 and 2023-05-29 506 are bad : about 0,65% (excluding exponents below 60M or above 120M doesn't change this significantly.)

Which brings me on the subject of ECC. IMHO ECC memory is not necessary for CPU primality testing (at least with DDR3, DDR4 ; not enough data about DDR5 or DDR6.) DDR2 was not reliable, but with DDR3 and DDR4 machines can run LLs year after year without an error.

[kriesel]

Offered as a possible counterexample:
https://www.mersenne.org/report_LL/?..._id=martinette
i5-1035G1 64GiB DDR4 laptop
31 verified LL, 5 bad; 5/36 = 13.9% bad
Note that the actual track record of the 64 GiB incarnation is worse than computed above, as the verified include some results from the original more reliable 16 GiB configuration. The 64GiB is 2 new SODIMMs obtained from ATech.

Its still-16-GiB twin (the laptop I'm typing on) is 47-0:
https://www.mersenne.org/report_LL/?...comp_id=martin

[retina]

Originally Posted by S485122

IMHO ECC memory is not necessary for CPU primality testing ...

Agreed. It never was necessary, even for known bad memory. The user just gets more and more frustrated with continual bad results.

But, IMO, for preserving sanity, ECC is fabulous. No^* wasted computing cycles or electrons.

^*Technically it should be "fewer", but I've never personally seen any bad results when using ECC.

[Jurzal]

It is not just ECC, it is also CPU throwing up an error even if memory works just fine.
In overclocking community we use P95 to stress-test CPU overclocks, especially with AMD Zen PBO2 algorithm and undervolting, ensuring stable operations is critical.

PC can work all fine with heavy undervolt, until you put 24h stress test and in 1-2 hours with raised temps errors start to creep in from the CPU calculations due to undervolt. Also, CPU silicon degradation matters and older overclocked CPU's need to reduce the overclocks with age, and raise voltages just to keep the same performance.

All my errors in LL and PRP were caused by too aggressive undervolt and overclock on my 5900X.
Even with tuned RAM, but ECC can't match regular tuned RAM performance for Zen 3. Reliability yes, performance, no.

EDIT: Don't get me wrong, ECC is great for prime search reliability. But it is not a silver bullet, there are other components affecting it too.

[R. Gerbicz]

Originally Posted by S485122

Of the remaining 78165 LL results returned between 2022-05-30 and 2023-05-29 506 are bad : about 0,65% (excluding exponents below 60M or above 120M doesn't change this significantly.)

Which brings me on the subject of ECC. IMHO ECC memory is not necessary for CPU primality testing

And even using LL with ECC+-Jacobi test does not help you to catch (all) FFT errors.

[slandrum]

Originally Posted by S485122

I ... then there are a few duplicate results (same user, final residue and shift, slandrum returned a whole lot on 2022-12-18 ...

Those were an error on my part, I moved a bunch of files to a new location as I was updating software and scripts, and neglected to copy the files that said which results had already been sent so a bunch of results got sent again.

[Xyzzy]

Is this interesting and/or useful?

https://pdos.csail.mit.edu/papers/so...opson-meng.pdf

[kriesel]

Definitely interesting. Now if we could find a full software implementation for Linux or Windows...

https://www.academia.edu/12046032/A_...puting_Systems

EDAC (Linux) is access to hardware error detection counts (Ram, cache, PCI). https://buttersideup.com/mediawiki/index.php/Main_Page

This one needs a bit of hardware support too; https://www.researchgate.net/publica...n_for_Memories

[kriesel]

Originally Posted by S485122

Of the remaining 78165 LL results returned between 2022-05-30 and 2023-05-29 506 are bad : about 0,65% (excluding exponents below 60M or above 120M doesn't change this significantly.)

I suspect if you break it down such as separate error rates for 57-60M and 114-120M intervals, you'll find a lower error rate at lower exponent, and high error rate and few samples at higher exponent. Run time at 120M will be ~4.3 times as long as at 60M, so on the same hardware, final LL residue error rate could easily be ~4 times as high. The server stopped issuing LL first test assignments some time ago.

[cxc]

I looked at the user list to see if there were any patterns in the last year, but unfortunately the LL-DC user report doesn’t allow a breakdown results by exponent range. I tried aggregating the data a little:

                   All        1–9 attempts      10–99     100–999    1000+ attempts
--------------|-------------|--------------|------------|----------|----------------
No failures:   1517 / 2009    1078 / 1282     433 / 651    6 / 69     0 / 7*
At least 1:     492 /          204 /          218 /       63 /        7*/
Only 1 failure: 286 /          143 /          129 /       14 /          /
More than 1:    206 /           61 /           89 /       49 /        7*/
2–9 failures:   186 /           61 /           85 /       38 /        2 /
     2 fails:    92 /           44 /           29 /       19 /          /
     3 fails:    41 /            7 /           31 /        3 /          /
     4 fails:    18 /            5 /           11 /        2 /          /
     5 fails:    10 /            3 /            3 /        4 /          /
     6 fails:     9 /            2 /            4 /        2 /        1 /
     7 fails:     9 /              /            4 /        5 /          /
     8 fails:     5 /              /            2 /        2 /        1 /
     9 fails:     2 /              /            1 /        1 /          /
More than 10:    20 /             N/A           4 /       11 /        5*/
More than 100:    5 /             N/A            N/A       3 /        2*/
More than 1000:     /             N/A            N/A        N/A         /
* Includes unidentified -Anonymous- combined as a single contributor

Two prolific contributors in the 1000+ attempts column have fewer than 10 failures; even those with more failures are still running at ~98% success minimum (the six non-anonymous contributors are at 98%, 98%, 98.6%, 99.4%, 99.6%, and 99.6%) which is solid, given the fleet of machines that have to be coordinated to achieve this. In each of the bands with fewer attempts a majority of contributors have two or fewer failures; overall 5.7% of users have more than two failures (and when picking through the data, there seem to be a few clear cases where machines are no longer being maintained and/or have h/w faults that make it difficult to run the LL test anyway).

[kriesel]

Getting the current or recent error rate lower is definitely good. But achieving a low current test error rate does not mean the mismatch rate on DC would be that low. It's common that a DC run today will be for an exponent whose first test was run several years ago, on older slower hardware, before the addition of the Jacobi check to prime95, so probably at at least double the error rate per test, probably considerably more.
Mismatch rate is first test error rate plus DC test error rate.
The top producers of DC output shows a wide variation of success rate among individuals.
Mismatch rate = 1 - successes / attempts. Summing the successes and attempts of the top N for n=1 to 60 yielded mismatch rate ranging from 2.05% at N=1 to 4.08% peak at N=20.
One could carry that out for top 500 too I suppose, although from 20 to 60, it looks like it stabilizes around 3.8%.
That would be rate per exponent; mean error rate per test (old and new) would be ~half that; 1.9%. (A little less than half I think, because some get 3 or four tests before matches are achieved.)
See second and third attachments of https://www.mersenneforum.org/showpo...91&postcount=6 for top 60 data and analysis.