Error rates and ECC

[S485122]

Originally Posted by cxc

...
Two prolific contributors in the 1000+ attempts column have fewer than 10 failures; even those with more failures
...

A mismatch by a user doesn't mean a bad LL result : it may be the previous result that is bad.

For instance the top LL DC producer has 23902 attempts and 23418 successes on the LL DC top producers report. Of the 484 results that were not a success in the past year (202-06-26 <-> 2023-06-25), only one result was bad. In that same period only 512 bad LL results were returned : LL results

Not all non successes are failures ;-)

One can argue that a mismatch implies a bad result, but one can not add that bad result to the tally if it isn't in the period considered.

[Uncwilly]

Originally Posted by S485122

A mismatch by a user doesn't mean a bad LL result : it may be the previous result that is bad.

This is the case for all of my DC's. I have had several mismatches, but have not had a single bad result since 2008. That is 1670 results with 0 bad.

[xilman]

Originally Posted by S485122

DDR2 was not reliable, but with DDR3 and DDR4 machines can run LLs year after year without an error.

An hour or so ago I purchased 48G (12x4) of DDR2 ECC memory.

The reason is not that I want reliability, just that the only machine I can easily and inexpensively upgrade to 64GB is a Dell T7400 and that is what it takes.

Up to now 16GB systems have been adequate for my purposes --- just. Finishing a C165 with CADO-NFS took a bit of tweaking and the machine swapped a little but it completed. The C180 currently running will not stand a chance. The merge phase is already up to 17G virtual and 13G physical. The machine is swapping like crazy and cpu utilization is about 2% on average. Linear algebra will take a close approximation to forever.

[kriesel]

Originally Posted by S485122

A mismatch by a user doesn't mean a bad LL result : it may be the previous result that is bad.

A mismatch means there was at least one bad result, but does not identify which is/are bad.
They can't both be right, but they can both be wrong, at some low probability.
That's how we get to triple checks, or quad, rarely 5, and in a very few past cases, 6 for the record AFAIK with some past help by James Heinrich to search the database for many-tests&residue-values exponent cases.
In project terms, it does not matter as much which was wrong, or when a bad result was produced, as that a tiebreaker or occasionally more than one will be needed.

[S485122]

Originally Posted by kriesel

A mismatch means there was at least one bad result, but does not identify which is/are bad.
...
In project terms, it does not matter as much which was wrong, or when a bad result was produced, as that a tiebreaker or occasionally more than one will be needed.

Indeed a mismatch points to a at least one bad result.

If you are evaluating the error rate of the tests of the past year, the fact that some of those tests reveals bad results returned years ago isn't relevant.

[charybdis]

Originally Posted by xilman

Up to now 16GB systems have been adequate for my purposes --- just. Finishing a C165 with CADO-NFS took a bit of tweaking and the machine swapped a little but it completed. The C180 currently running will not stand a chance. The merge phase is already up to 17G virtual and 13G physical. The machine is swapping like crazy and cpu utilization is about 2% on average. Linear algebra will take a close approximation to forever.

...or use msieve for postprocessing and then GNFS up to the high 180s will fit in 16GB. Worth it for the small amount of manual intervention required, and the linear algebra is much faster, too.

[xilman]

Originally Posted by charybdis

...or use msieve for postprocessing and then GNFS up to the high 180s will fit in 16GB. Worth it for the small amount of manual intervention required, and the linear algebra is much faster, too.

Thanks for the advice. I may well try it in the near future.

The memory will go into a machine here in Cambridge. All the data resides on a machine in La Palma. Large data transfers are generally done by sneakernet using a 4TB external USB disk. The work directory currently holds 49GB.

The additional memory will still come in useful though. A machine with 8 cpus running 8 sievers, each taking 2.3G (for the C180) needs more than 16G RAM to exploit its abilities properly.

[charybdis]

Originally Posted by xilman

The additional memory will still come in useful though. A machine with 8 cpus running 8 sievers, each taking 2.3G (for the C180) needs more than 16G RAM to exploit its abilities properly.

The CADO siever can run multithreaded and share the memory between threads. It defaults to 2 threads per client (I guess your 8 sievers may each be running on 2 threads of a hyperthreaded core?) but you shouldn't lose much if any efficiency by setting it to 4 with --client-threads 4 in the invocation. Above that you may start to see <100% CPU utilization.

[Andrew Usher]

I'd say it's clear that the approach of S185422, counting explicitly bad results (of all those that have been checked at all), is the best for verifying the actual error rate. And 0.65% (which includes some hardware that definitely shouldn't be running LL) sounds reasonable.

Estimating error rates in the past, on the other hand, is more relevant to the chance of a mismatch. In this case, the average rate as used by Kriesel will be an overestimate - it is the best mismatch rates gotten by productive users that bound the past error rate. I can certainly believe it was higher than today for the same exponent range, but not by much, it seems.

In addition, our 'failure' statistics seem to include some things that don't imply bad results - look at Fabrice Bellet, who has a 'failure' rate over half, though the database doesn't show any bad results for him since 2013. This presumably is related to his current practice of turning in LL and PRP results years late after someone else has completed them, though I can't understand the details. 'Anonymous' users and others also have such late results, and may fall under the same condition.

[kriesel]

Originally Posted by S485122

If you are evaluating the error rate of the tests of the past year, the fact that some of those tests reveals bad results returned years ago isn't relevant.

An individual user that's conscientiously trying to lower his own error rate would look at his own error rate, versus time and down to the application, system or GPU level. Users can't do much about old errors, other than understand why they occurred and do something about the possible root causes to lower or at least control the rate of future errors on their own hardware. Casual or unaware users probably won't.

Answering questions about the overall project error rate, and identifying root causes, would take the broader view, in application, user, exponent and time. Some users have been identified as producing lots of errors, and their results prioritized for reevaluation. Some applications & versions have been identified as more error prone and are largely avoided or recommended against.

Both perspectives have their uses.

I've assembled links and rates in an LL and PRP error rates reference post here. Please PM me with any links to well reasoned and documented rate computations I've missed.

I'm contemplating a reference post on root causes of errors & perhaps countermeasures also. Constructive contributions are welcome, here perhaps, in a new thread not yet created for the purpose, or legitimately in the reference info discussion thread.

[S485122]

Originally Posted by kriesel

...
I've assembled links and rates in an LL and PRP error rates reference post here.
...
reference info discussion thread.

I'm sorry but I drown in your reference information, after two topics and three lines I am lost.

I can only say (repeat ?) that if you want to evaluate the error rate of current contributions, you must not look at mismatches which might be a bad or a correct result (often proving a result from previous years bad.) Just look at recent LL results returned. Don't choose a range, don't limit yourself to a few results (as in "quite small sample sizes used"), evaluate the production of a whole year (using "text" for output will provide you with 10000 rows at a time).

I will concede that since the high ranges are mostly being done with PRP and not LL the double-checkers and lower exponents are over represented in those figures.

But those figures are what we are discussing, i.e. the current LL error rate and that current error rate is less than 0,7 %.