mersenneforum.org - Report top-5000 primes for all k<=1001

[QUOTE=gd_barnes;626984]I just now double-checked it. LLR version 3.8.23 says otherwise:

909*2^2056937-1 is prime! (619203 decimal digits) Time : 1299.213 sec.

Max's machines have been quite stable. He just now found another prime and I also verified that it is prime. I'll report it in the next post.

The new top-5000 site appears to be wrong! They need to work on their verification process. It takes many hours for the tests to start, it takes too long to run the test (over an hour for this one), and now it outputs the wrong result.

Anyone else care to test this?

Edit: I just now used their "let us know if anything isn't working" process to Email them about the problem.[/QUOTE]
Ah, yes - I noticed the same issue last night. The top-5000 site sent me an automatic email informing me of the verification failure. I re-tested the candidate myself last night twice using different programs, the first time with the very latest LLR2 v1.3.3 (gwnum 30.11), and the second as an N+1 test with an older PFGW 3.7.10 (gwnum 28.7), similar to what the top-5000 site tried to run. Both confirmed primality without issue - although like others here, I did get several round-off errors during the PFGW test (which PFGW was able to detect and self-heal by going to a more cautious FFT).

I wouldn't be surprised if the reason the problem only showed up just now on this candidate is because it's most sensitive near an FFT boundary (where self-correcting roundoff errors like this are common - but might not be self-correcting if there's an underlying hardware/software issue).

I was going to email them myself about it today, but was busy for much of the day and by the time I checked in the evening, saw that the top-5000 site was already actively retrying it. (The first re-try failed again, but I saw another one was in progress, which ultimately turned out prime.) Now I see that's because Gary emailed them - thanks! :smile:

Glad to see the root cause was found and resolved (per Gary's note just above) - and that everyone here is so on top of this! I was wondering if it was something like an AVX-512 issue, as that's the only sort of issue I could imagine manifesting like this in a cloud-computing environment (where the hardware is invariably server-grade with ECC RAM, which prevents most "random" bit-flip errors).