[QUOTE=aketilander;422193]
[B][COLOR=black][FONT="Arial"]ATH[/FONT][/COLOR][/B]
[COLOR=black][FONT="Arial"]ETA on 8 cores on 5960X ~ 8am UTC on tuesday the 12th.[/FONT][/COLOR][/B][/QUOTE]

That CPU run was scrapped unfortunately since my Prime95 was behaving very weird and I'm now 26 hours into an extensive RAM test with MemTest86 . But it was not important since there have been several other CPU verification with Prime95, it was the CudaLucas run that was the independent software+hardware check.

All of my runs (multiple CUDA and clLucas runs as well as prime95 at 4 and 4.5M FFT ) completed successfully with matching residues and prime final iterations.

The MLucas run is likely complete or very close based on the last update, I'll wait for Serge. We will all wait for George to be ready.

Also, I hope no one feels as if I have some secret and am parading that fact around, on the contrary I am just super excited to help and happy I was trusted to do so. I would guess this is partially due to my understanding of why we keep the exponent under wraps, and due to some personal experience with a previous false positive. The victory of finding the prime belongs to the entire project and everyone who contributed cycles.

[QUOTE=airsquirrels;422218]
Also, I hope no one feels as if I have some secret and am parading that fact around, on the contrary I am just super excited to help and happy I was trusted to do so. I would guess this is partially due to my understanding of why we keep the exponent under wraps, and due to some personal experience with a previous false positive. The victory of finding the prime belongs to the entire project and everyone who contributed cycles.[/QUOTE]

:goodposting:

[QUOTE=airsquirrels;422218]All of my runs (multiple CUDA and clLucas runs as well as prime95 at 4 and 4.5M FFT ) completed successfully with matching residues and prime final iterations.

The MLucas run is likely complete or very close based on the last update, I'll wait for Serge. We will all wait for George to be ready.[/QUOTE]

That is so good! Congratulations!

MLucas version 14.1 [B]approves[/B] the assertion.

Now, let's all exercise patience because the publication process and its intricacies are entirely out of our hands. People with trusted skills in this matter will take care of it.

Reading the previous thread will help anyone who wants to wind back the clock and check what stages took what amount of time can find them there:
[LIST][*][URL="http://mersenneforum.org/showthread.php?p=327045#post327045"]M48[/URL][*][URL="http://mersenneforum.org/showthread.php?p=142693#post142693"]earlier[/URL][*]Or, Search (blue bar, next to FAQ) :: advanced:: text = (press release) :: User = Prime95 :: show [B]posts[/B][/LIST]

I'm glad everything matches :)

[QUOTE=axn;422189]Yet, here we are…[/QUOTE].

[QUOTE=Xyzzy;422239].[/QUOTE]Some of us of a certain age will be facing that IRL soon enough ... :paul:

[QUOTE=Xyzzy;422239].[/QUOTE]

Exactly how I felt last year as I underwent a root canal and several large replacement fillings. "2015 and we're still going through this? Seriously, isn't there some kind of laser or something?!"

[QUOTE=aketilander;422201]...

One thing I have been thinking about is if there is a way to build a version/mode of prime95 to be (even more) [B]rock-solid[/B], to be used (only) for verification issues like this. Maybe with built in checking and double-checking on every iteration (with a lot of cores this would not slow down the process) and error checking on every iteration (with a lot of cores, this again, would not slow down the DC much)? Maybe there are other ways also to build in more error checking in the assembler code or make the program (even more) robust? It may be useful also for the real big LL runs.[/QUOTE]

I would love to do this is just as an informal challenge! I'm playing around with the GMP library, which is open source and independent code to Prime95, and dots rounding on each step, and there are plenty of error and verification checks that can be done, like checking to see if the intermediate residue is stuck at 2.

[QUOTE=CuriousKit;422174]Given that the type of result is marked as "C", not "P", I will hazard a guess that the last 2 digits of the residue are 02, not 00, and is most likely a hardware error - as described in the "Erroneous values of s_n" topic, if a hardware error causes the intermediate residue to become zero at any point, the next value in the sequence will be -2, and then that will become +2, and then +2 will keep reproducing itself from then on.[/QUOTE]

You would think so, but the residue for it in the database really is zero which is why I did a double-check.

The fact that it's marked C in that report might just indicate that it hasn't been listed as a known prime or something... I forget how that report decides whether to show a C or not, but that's probably what it is.