Error rate plot

[patrik]

I took the last of the v4 server status files (03 Feb 2008) and plotted the error rate.

The red curve shows verified (lucas_v) and bad (bad) data only, while the green curve also counts exponents with more than one unverified test performed. (See GP2's old discussion in this thread.)

[patrik]

And one more post with the plot going up to 40M.

[patrik]

Sorry, these was a small mistake in the first plot.

[retina]

Could the spike at ~33M be the initial groups of testers taking 1year (or more) to complete? One imagines that the longer the test runs the more chance there is for it to go wrong.

Actually, this would tend to validate my assumption about the recent PC hardware becoming more reliable. The trend seems to be coming down with (what is presumably) people upgrading their machines to newer, more reliable, models.

[tha]

Originally Posted by retina

Could the spike at ~33M be the initial groups of testers taking 1year (or more) to complete?

If you look at the actual machines that did those tests, it appears to me that the overclockers joined the land rush over there much more fanatically than non overclocked machines. Overclocked machines tend to be much more unreliable.

[Mini-Geek]

Originally Posted by tha

If you look at the actual machines that did those tests, it appears to me that the overclockers joined the land rush over there much more fanatically than non overclocked machines. Overclocked machines tend to be much more unreliable.

Do reasonably OCed machines increase total GIMPS throughput? A better way to say it may be: If all the machines were OCed but still mostly stable, would GIMPS's total speed be higher than if they were all at standard clock speeds?

[tha]

Originally Posted by Mini-Geek

Do reasonably OCed machines increase total GIMPS throughput? A better way to say it may be: If all the machines were OCed but still mostly stable, would GIMPS's total speed be higher than if they were all at standard clock speeds?

I believe (literally, not based on figures) the extra throughput is entirely wiped out by errors in the results. Of course a little overclocking does less harm than more aggressive overclocking etc. Still I don't see a reason to overclock for GIMPS machines.

[Brian-E]

Originally Posted by tha

If you look at the actual machines that did those tests, it appears to me that the overclockers joined the land rush over there much more fanatically than non overclocked machines. Overclocked machines tend to be much more unreliable.

Originally Posted by tha

I believe (literally, not based on figures) the extra throughput is entirely wiped out by errors in the results. Of course a little overclocking does less harm than more aggressive overclocking etc. Still I don't see a reason to overclock for GIMPS machines.

Probably overclocking is to the advantage of people who are chasing the prize for being the first to find a 10-million decimal digit prime. By testing as many exponents as possible around exponent 33 million in a less than fully reliable way they are probably increasing their individual chance of this prize. But I guess that you are very likely correct in your judgment that overclocking does not help the categorisation of Mersenne numbers generally. It is also very possible that a Mersenne prime around this range could be missed for the time being due to an overclocked computer giving a false negative result.

[davieddy]

Isn't the decline in the green line from 20M to 40M
simply down to fewer double checks to expose "bad" tests?

David

[patrik]

I have spent some time yesterday and today downloading the Lucas-Lehmer results in 50000 lines chunks (maximum allowed) and have made my own files similar to bad.txt, hrf3.txt and lucas_v.txt. Then I updated the error rate plot from February 2008. Almost no changes.

[garo]

Thanks for the great work. I wonder what the twin spikes at 15M and 17.5M due to. Perhaps due to wrong FFT boundaries? They were changed in v22.4 so perhaps the previous SSE2 boundaries were incorrect?