mersenneforum.org  

Go Back   mersenneforum.org > Great Internet Mersenne Prime Search > Data

Reply
 
Thread Tools
Old 2012-12-24, 23:58   #56
patrik
 
patrik's Avatar
 
"Patrik Johansson"
Aug 2002
Uppsala, Sweden

23·53 Posts
Default Updated error rate plot

I have updated the error rate plot again. There are no major changes. This time I downloaded all the verified LL tests again. (For 2010 and 2011 I didn't download the small verified exponents again, since they wouldn't change.)
Attached Thumbnails
Click image for larger version

Name:	error_rates_50k_50M_zero_20121224.png
Views:	129
Size:	9.4 KB
ID:	9045  
patrik is offline   Reply With Quote
Old 2012-12-25, 15:56   #57
VictordeHolland
 
VictordeHolland's Avatar
 
"Victor de Hollander"
Aug 2011
the Netherlands

23×3×72 Posts
Default

Quote:
Originally Posted by patrik View Post
The red curve shows the error rate (number of bad tests divided by number of tests). The green curve estimates the error rate by also including data from unverified tests. (If two non-matching tests have been done for an exponent, at least one of them must be bad, so I count this one.) The blue curve is the zero error code error rate (number of bad tests with zero error code divided by number of tests). Finally the violet curve estimates the zero error code error rate, by also using unverified tests.
So if I understand this correctly, the blue line only counts verified bad tests that were reported without an error? In other words, if no DC was done, they would go unnoticed? Is the difference between the red and the blue line the error rate of bad test WITH an error reported (LLER)? Are heavy OC-ed machines more prone to produce bad results with or without errors? Is it possible a LLER eventually proved to be correct. And if so, does this happen often?

I only run TF on my GPUs so I'm very familiar with the LL testing phase .
VictordeHolland is offline   Reply With Quote
Old 2012-12-25, 17:22   #58
Dubslow
Basketry That Evening!
 
Dubslow's Avatar
 
"Bunslow the Bold"
Jun 2011
40<A<43 -89<O<-88

3×29×83 Posts
Default

Quote:
Originally Posted by VictordeHolland View Post
So if I understand this correctly, the blue line only counts verified bad tests that were reported without an error? In other words, if no DC was done, they would go unnoticed? Is the difference between the red and the blue line the error rate of bad test WITH an error reported (LLER)? Are heavy OC-ed machines more prone to produce bad results with or without errors? Is it possible a LLER eventually proved to be correct. And if so, does this happen often?

I only run TF on my GPUs so I'm not very familiar with the LL testing phase .
Those are are all correct.

OC-ed machines tend to produce more errors, though I'm not sure if they produce more bad-errorless tests.

The red line counts all bad tests, the blue line counts bad error tests without an error code, and so the difference is bad tests with an error code.

Yes, DC is done to catch the bad tests with no error code. This can happen for a variety of reasons; perhaps an error occurred that Prime95 just didn't catch, or perhaps some memory was corrupted without the program knowing, etc.

Yes, it is possible for a test with an error code to be correct. Prime95 is incredibly robust and can recover from most errors (the fewer there are, the more likely you are to have a decent result), but any and all errors are still counted in the error report.
Dubslow is offline   Reply With Quote
Old 2013-12-29, 12:00   #59
patrik
 
patrik's Avatar
 
"Patrik Johansson"
Aug 2002
Uppsala, Sweden

23×53 Posts
Default Updated LL error rate plot

Thanks to Luke Welsh (M29) for suggesting x- and y-axis labels, and other small changes, to make the plot more readable.

The server seemed slower this year than last year. Data requests that went fine last year often timed out (after 90 s) this year.

Quote:
Originally Posted by VictordeHolland View Post
Are heavy OC-ed machines more prone to produce bad results with or without errors?
I my experience heavily OC-ed machines produce a lot of detected errors (and maybe even more undetected). It is when you reduce the OC so that no more errors are detected that it still may produce undetected errors.

Therefore (in my opinion) you should lower the overclock even further (after getting no detectable errors) and then run at least 20 double-checks and look up your results. (After that, in case of a mismatch, run a triple-check.)
Attached Thumbnails
Click image for larger version

Name:	error_rates_50k_65M_zero_20131228.png
Views:	145
Size:	12.2 KB
ID:	10617  
patrik is offline   Reply With Quote
Old 2014-01-02, 01:54   #60
TheMawn
 
TheMawn's Avatar
 
May 2013
East. Always East.

11·157 Posts
Default

Hah! I almost started up a reply before I saw that the original topic is ancient.

I skipped ahead to what ended up being this year's contribution to the discussion (one whole post) and I'm surprised to see the debate still hovering over the overclocking stuff.


The error rate looks to be decreasing fairly dramatically. Is there a way to plot it versus time as opposed to versus the exponent? I can't say for sure but I think overclock is much more common these days than it was before when the error rates were higher.

My machine is overclocked to give 20%-30% more throughput. I had it stable using 0.05 V less and 0.1 GHz more, stable being 24 hours of stress tests (this was back when I was doing this for temps as I had not joined GIMPS yet). Since then, I've had one reproducible rounding error (the only one I can find in my logs) and none of my DC's have been mismatches.

My heavily overclocked machine falls well below the average error rate in that regard.
TheMawn is offline   Reply With Quote
Old 2014-01-02, 09:53   #61
S485122
 
S485122's Avatar
 
Sep 2006
Brussels, Belgium

32×181 Posts
Default

Quote:
Originally Posted by TheMawn View Post
The error rate looks to be decreasing fairly dramatically. Is there a way to plot it versus time as opposed to versus the exponent? I can't say for sure but I think overclock is much more common these days than it was before when the error rates were higher.
I do not see how you arrive at that conclusion, if you look at the older data you will also see fewer bad results for higher exponents. This is just because less of them have been checked.
Then the newer versions of Prime95 count fewer types of errors (see a discussion of this in the Software Forum.) I am not sure about the error counting of non Prime95 software (used on GPU for instance.)
Quote:
Originally Posted by TheMawn View Post
My heavily overclocked machine falls well below the average error rate in that regard.
You could say this with certainty if you did double-checks only :-)

Jacob
S485122 is online now   Reply With Quote
Old 2014-12-24, 00:08   #62
patrik
 
patrik's Avatar
 
"Patrik Johansson"
Aug 2002
Uppsala, Sweden

23·53 Posts
Default Updated error rate plot

Merry Christmas!

Enjoy this year's updated error rate plot.
Attached Thumbnails
Click image for larger version

Name:	error_rates_50k_65M_zero_20141223.png
Views:	172
Size:	12.0 KB
ID:	12120  
patrik is offline   Reply With Quote
Old 2015-05-11, 13:03   #63
diep
 
diep's Avatar
 
Sep 2006
The Netherlands

22×173 Posts
Default

Good Afternoon,

Good to see an estimate. I'm looking for the measurement.

What's the measured number of errors in double checks carried out for GIMPS on tests the past few years now that we have all these high clocked i7's and fast AVX LL?

Regards,
Vincent
diep is offline   Reply With Quote
Old 2015-05-11, 16:48   #64
VictordeHolland
 
VictordeHolland's Avatar
 
"Victor de Hollander"
Aug 2011
the Netherlands

23×3×72 Posts
Default

Quote:
Originally Posted by diep View Post
Good Afternoon,

Good to see an estimate. I'm looking for the measurement.

What's the measured number of errors in double checks carried out for GIMPS on tests the past few years now that we have all these high clocked i7's and fast AVX LL?

Regards,
Vincent
The red and blue lines are measured, the green and purple lines are estimates. You can't say anything about the error rate of a perticular type of processor based on this graph. There is a wide variety of machines running GIMPS, from Pentium 4s (maybe even some older toasters) to server grade Xeon v3 .

I'd love to see plots of OCed computers vs. stock clock computers vs. server grade hardware, but it's not realistic to extract that from the data the server stores.
VictordeHolland is offline   Reply With Quote
Old 2015-12-23, 20:33   #65
patrik
 
patrik's Avatar
 
"Patrik Johansson"
Aug 2002
Uppsala, Sweden

6508 Posts
Default Updated LL error rate plot

I have updated the error rate plot again.

Merry Christmas!
Attached Thumbnails
Click image for larger version

Name:	error_rates_50k_70M_zero_20151223.png
Views:	118
Size:	12.9 KB
ID:	13609  
patrik is offline   Reply With Quote
Old 2015-12-24, 00:45   #66
diep
 
diep's Avatar
 
Sep 2006
The Netherlands

22×173 Posts
Default

Great!

Do i correctly interpret the red as that from all verified tests between about 2% to 4% in the 40M range gives an error?

So

(P( has error AND was verified test ) / P( all verified tests) ) = [2% ; 4%]

Did i read this correct?

If so - excuse my ignorance, how can the green be above the red in the estimate?
diep is offline   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
error rate and mitigation ixfd64 Hardware 4 2011-04-12 02:14
EFF prize and error rate S485122 PrimeNet 15 2009-01-16 11:27
A plot of Log2 (P) vs N for the Mersenne primes GP2 Data 3 2003-12-01 20:24
What ( if tracked ) is the error rate for Trial Factoring dsouza123 Data 6 2003-10-23 22:26
Error rate for LL tests GP2 Data 5 2003-09-15 23:34

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

Thu Dec 3 10:34:40 UTC 2020 up 6:45, 0 users, load averages: 1.03, 1.34, 1.32

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.

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.