77.9M exponents
 

A new one just completed:

77909939,73, ,0xFF0AA5467D38CD__,19-Nov-03 01:35,hsoftdev17,Geek2

Unfortunately, the two previous 77.9M exponents don't set a promising precedent:
77900461,Team_Prime_Rib,DSheets_60,WZ1,0B003300
77909869,Team_Italia,Paperino,WZ1,0B014103

Check out the scary error codes (last field).

Let's cross our fingers and check out the next HRF3.TXT to see how the error code for the latest one turned out.

I was just curious: How do you check out 77.9m exponents for testing? I'm not really interested in doing one, but I was just wondering.

I think you have to specially request them.

I suppose some people might be doing them for QA of the code at higher FFT sizes, or some people might be doing them so that they can 'dump a bomb' in the statistics charts.

We'll have to see what the error codes look like for this latest one, and also a few others in the pipeline. My instinct is that it doesn't make sense to do these with current hardware.

It probably only makes sense to do these if you do the double-check at the same time. Take two machines and set InterimFiles and InterimResidues to 500,000 or so. Compare the residues as the test progresses. If they get out of sync, back them up until you find the error and get back in sync.

Note this might also be useful for a marginal machine. Rather than hoping you can do all 10 or 20 million iterations of a test without error, you can team up with someone and an error will set you back only a little bit.

George,

If I run two parallel checks as you describe, and in the end both computers report back identical residues, do I get credit for both the first time LL and the doublecheck? The two results would have different shift counts, but the user ID would be the same for both. I seem to recall that you don't officially credit the doublecheck if the user ID is the same.

[QUOTE][i]Originally posted by Prime95 [/i]
[B]It probably only makes sense to do these if you do the double-check at the same time. Take two machines and set InterimFiles and InterimResidues to 500,000 or so. Compare the residues as the test progresses. If they get out of sync, back them up until you find the error and get back in sync.

Note this might also be useful for a marginal machine. Rather than hoping you can do all 10 or 20 million iterations of a test without error, you can team up with someone and an error will set you back only a little bit. [/B][/QUOTE]

Hi George,

Do you know if Ken is still running the QA effort? Just curious, thanks.

I think Ken is out of the Mersenne hunting business. I wish him well.

I just remembered this thread, and how it was going to have the error code for M77909939 once HRF3.TXT got updated. So here's the line from HRF3.TXT:

77909939,hsoftdev17,Geek2,WY1,10001000

Although I am not sure, I think this qualifies as a non-harmful error code, and therefore this test could actually be worth something!

[QUOTE=GP2;14185]A new one just completed:

77909939,73, ,0xFF0AA5467D38CD__,19-Nov-03 01:35,hsoftdev17,Geek2

Unfortunately, the two previous 77.9M exponents don't set a promising precedent:
77900461,Team_Prime_Rib,DSheets_60,WZ1,0B003300
77909869,Team_Italia,Paperino,WZ1,0B014103

Check out the scary error codes (last field).

Let's cross our fingers and check out the next HRF3.TXT to see how the error code for the latest one turned out.[/QUOTE]

Almost 13 years later, the double-check results are:
[URL="http://www.mersenne.org/report_exponent/?exp_lo=77909939&full=1"]77909939[/URL]: verified good
[URL="http://www.mersenne.org/report_exponent/?exp_lo=77900461&full=1"]77900461[/URL]: verified good
[URL="http://www.mersenne.org/report_exponent/?exp_lo=77909869&exp_hi=&full=1"]77909869[/URL]: mismatch, as mentioned in [URL="http://www.mersenneforum.org/showthread.php?t=1203"]this thread[/URL]. The original test in 2003 took 150 days.

These were the very first 7xM results ever attempted, back in 2003, along with [URL="http://www.mersenne.org/report_exponent/?exp_lo=77900497&exp_hi=&full=1"]77900497[/URL] which was recently verified good by Mark Rose.

This sounds like a fairly low error rate for exponents done so far ahead of the curve.