mersenneforum.org > Data Error rate plot
 Register FAQ Search Today's Posts Mark Forums Read

2016-01-10, 08:58   #100
henryzz
Just call me Henry

"David"
Sep 2007
Cambridge (GMT/BST)

2×2,969 Posts

Quote:
 Originally Posted by Madpoo Found this... pointed me to where in the source that info can be found. http://www.mersenneforum.org/showpos...postcount=1149 It's helpful to see the different max breakpoints for SSE2 and AVX, especially with an experiment I'm doing comparing multi-workers and FFT sizes interacting.
That could be helpful. I spent a while going through the source and couldn't find it.

 2016-12-24, 21:56 #101 patrik     "Patrik Johansson" Aug 2002 Uppsala, Sweden 52×17 Posts Updated error rate plot The error rate plot is updated again. I haven't looked into the increased error rate above 40M yet. (It's too late for me to think clearly.) I don't know if it is only a statistical scatter due to few tests being done, or if it is real. It increases even further, but I only plotted it to 46M, to be able to keep the vertical scale the same. The data files at my web site have also been updated. Attached Thumbnails
 2016-12-25, 15:45 #102 patrik     "Patrik Johansson" Aug 2002 Uppsala, Sweden 52·17 Posts I suppose that the increased error rate above 40M must be due to an effort to make an early verification of tests that has reported an error. Then it would be better to use only the green curve for the part where not all exponents have been double-checked. I post a plot updated accordingly. I also post a second plot which goes up to 80M. Attached Thumbnails
2016-12-25, 21:58   #103
GP2

Sep 2003

5×11×47 Posts

Quote:
 Originally Posted by patrik I suppose that the increased error rate above 40M must be due to an effort to make an early verification of tests that has reported an error.
I think there are a few of us who have been doing early double-checks of exponents (with or without an error code reported) that were originally done by machines with a track record of previous mismatches and bad results. And now with the triple checking project arriving near the finish line, all those mismatches have been rapidly converting into verified bad results.

So it is undoubtedly an artifact that will go away when the wavefront advances and clears more of the routine double-checks.

 2017-12-23, 23:33 #104 patrik     "Patrik Johansson" Aug 2002 Uppsala, Sweden 52×17 Posts Updated error rate plot Here are the updated error rate plots, with data from a few hours ago. Attached Thumbnails
 2018-12-24, 21:18 #105 patrik     "Patrik Johansson" Aug 2002 Uppsala, Sweden 1101010012 Posts Updated error rate plot Here is another update of the error rate plots. Data was downloaded earlier today. Attached Thumbnails
 2019-01-01, 17:39 #106 kriesel     "TF79LL86GIMPS96gpu17" Mar 2017 US midwest 134458 Posts Good work, Patrik, keep it up!
 2019-12-31, 22:21 #107 patrik     "Patrik Johansson" Aug 2002 Uppsala, Sweden 52·17 Posts Updated error rate plot Here are the updated plots for this year. I merged the data collected from primenet in files that I uploaded here: Code: Nbad.zip Nhrf3.zip Nlucas_v.zip Nprp_bad.zip Nprp_unv.zip Nprp_v.zip (The one text file in each zip archive has lines ending in LF, not CR LF.) I think there are still not enough PRP data to make a plot of that. Happy new year! Attached Thumbnails
2020-01-01, 15:06   #108
R. Gerbicz

"Robert Gerbicz"
Oct 2005
Hungary

72·31 Posts

Quote:
 Originally Posted by patrik I think there are still not enough PRP data to make a plot of that.
Probably the main reason is that there is no error ?

2020-01-01, 16:17   #109
kriesel

"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

3×52×79 Posts

Quote:
 Originally Posted by R. Gerbicz Probably the main reason is that there is no error ?
There is very little activity in running PRP DC. More is required to plot a meaningfully sized set of PRP error rate data. Orders of magnitude more. Yes we expect the residual PRP error rate after GEC to be a good approximation of zero, although there were errors found with the code outside the GEC previously. And therefore even fewer resources are being allocated to run PRP DC, than the modest amount running LL DC. LL DC wavefront (~50M) is much lower than the available PRP first-tests on which to run PRP DC (~76M), also, so available PRP DC take longer than available LL DC. PRP DC are perceived as less of a priority since there is less of a backlog, and also less expectation of error.

I think running PRP DC is useful, to empirically confirm the overall error rate is as low as expected, validate hardware and reporting reliability, and just possibly smoke out errors outside the GEC protected code, or some obscure implementation error in the GEC and PRP code.
Remember the v17 prime95 shift bug, where the code was sound, except for the rare ~1ppm case where the shift value was within a word's number of bits of the modulo length, or something like that. Or the pentium FDIV bug of long ago. Each was an implementation issue, such that the code behavior did not follow the number theory in infrequent operand cases.

See https://www.mersenneforum.org/showpo...9&postcount=14 for the big disparity in effort between LL DC and PRP DC.

The changeover from LL to PRP first tests is taking a long time.

Last fiddled with by kriesel on 2020-01-01 at 16:34

2020-01-09, 18:43   #110
kriesel

"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

3·52·79 Posts

Quote:
 Originally Posted by patrik I think there are still not enough PRP data to make a plot of that.
How many do you think are needed?

 Similar Threads Thread Thread Starter Forum Replies Last Post ixfd64 Hardware 4 2011-04-12 02:14 S485122 PrimeNet 15 2009-01-16 11:27 GP2 Data 3 2003-12-01 20:24 dsouza123 Data 6 2003-10-23 22:26 GP2 Data 5 2003-09-15 23:34

All times are UTC. The time now is 15:10.

Mon Dec 6 15:10:22 UTC 2021 up 136 days, 9:39, 0 users, load averages: 1.39, 1.67, 1.62

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.