SkylakeX teasers (aka prime95 29.5)

[simon389]

Originally Posted by GP2

Another possibility is that Gerbicz error checking was somehow turned off. Either by changing the settings as per undoc.txt, or by a memory-corruption overwrite of the flags within the running program.

Does the output of the program show that the Gerbicz error checks (especially the final two) were actually performed?

I can search the machine for logs, and if they don’t exist, do another PRP doublecheck and make sure to save the logs this time (or enable more verbose logs if P95 has that option).


Edit:


I checked the old logs (which I assume are just all these TXT files in the Prime95 folder) and the best I can find related to failed PRP double checks is stuff like this (some values for 79143199 have been masked):

[Thu Jan 24 11:13:25 2019]
{"status":"C", "exponent":79143199, "worktype":"PRP-3", "res64":"E83251C4FEE30A__", "residue-type":1, "res2048":"__E83251C4FEE30A__", "fft-length":4300800, "shift-count":40723076, "error-code":"00000000", "security-code":"1BE976__", "program":{"name":"Prime95", "version":"29.5", "build":8, "port":4}, "timestamp":"2019-01-24 19:13:25", "errors":{"gerbicz":0}, "user":"simon389", "computer":"9800X", "aid":"DE0E654B61244E083532__"}

It does say Gerbicz:0. Maybe this helps you guys. I'm more than happy to run another PRP doublecheck with more verbose logging enabled if that's an option.

[Prime95]

Yes, Simon's PRP tests ran with Gerbicz error checking.

My plan is to scrutinize the code for vulnerabilities. For example, after each Gerbicz block completes, I believe there is only one copy of the intermediate computation value -- if a memory corruption happened right then we'd get an undetected bad result.

We can never completely eliminate all potential problems. For example, a hardware error could corrupt the instruction pointer such that prime95 jumps straight to the "report the residue" code.

[GP2]

Originally Posted by simon389

I'm more than happy to run another PRP doublecheck with more verbose logging enabled if that's an option.

In the JSON output "port":4 means you're running Prime95 on Windows 64-bit.

So normally the Prime95 output window should have a bunch of lines, mostly Iteration counts, but also every 1 million iterations it should say it's doing a Gerbicz error check.

Of course if you've shut down your computer to replace power supplies and whatnot, then all that window output is long gone. But I guess you could start a new PRP test if you want, and monitor what it's doing, especially at the end where it will do two final Gerbicz error checks just before completion.

In your prime.txt file you could change the WorkPreference= line to say WorkPreference=151, that will do double-checks of other people's first-time PRP tests. Or keep it as WorkPreference=150 to continue doing first-time PRP tests.

In prime.txt you could set InterimResidues=n and InterimFiles=n to print out interim residue values or create interim save files every n iterations. Assuming you have enough disk space, you could set n to something like 1000000 . But you have to remember to turn it off later or it will quickly fill up your directory with litter.


Anyway, those are just some ideas. Presumably George can provide guidance about what might be useful to him.

[Prime95]

Simon, you could add this to prime.txt:

GerbiczVerbosity=3

I doubt the minor amount of extra info will help.

[Prime95]

Simon, can you PM (or email) the results.txt file? Unlikely, but it might show something useful.

[R. Gerbicz]

Originally Posted by Mysticial

Without knowing anything about PRP and the Gerbicz check:

See https://mersenneforum.org/showthread...22471&p=465431 and https://mersenneforum.org/showthread.php?t=22510 (for the original idea on Proth numbers).

[R. Gerbicz]

Originally Posted by GP2

There is a Gerbicz error check every 1 million iterations, and then right before completion, there are two more Gerbicz error checks for good measure.

For example, taking another exponent in that same 79M range, for M79253869 the final error checks were at iterations 79253009 and 79253850, which is 99.998915% and 99.999976% complete.

So for Simon's exponents, it passed all those tests and then something went wrong at the very very very very end. Not just for 79075979 but for several others.

There should be no such thing, every iterations should be error checked. Probably this wasn't written in these forums, but here it is how you can change the "L" value in the check:
(so why p95 can change the checks for reliable/unreliable hardwers in a smooth way)

You can also use a Gerbicz error check using different L values, if you have a checked residue at iteration=t, then use a new base:
b=a^(2^t) mod N and you can now use a different L_2.
The only modification in this setup is that now you need to multiple by b not with the small a=3 in the check, but the overhead is very tiny (the extra cost means ~100 more iterations for p~1e8 if you check at every ~1M).

In the last block, where from the last check there is still u*L_2+v (say <L_2*L_2) iterations then after u*L_2 iterations do a check. In the final very few v iterations where you would see v<L_2 iterations force an error check for L_3=v, but this is basically equivalent to a standard boring double check repeating the last v iterations.

[preda]

Originally Posted by tServo

Does this mean that gpuowl shouldn't do any first-time PRP tests;
or only avoid using it to check previous PRP tests done with PRIME95 ?

GpuOwl, which recently is doing type-4, should not be used to double-check a type-1 PRP result (because to double-check the type must be the same). Thus, one can't use GpuOwl to double-check a PRP coming from prime95.

In the other direction, prime95 can be used to double-check a type-4 result from GpuOwl (because prime95 is able to do all the types).

So ideally, GpuOwl would be used for the initial PRP. If a double-check is needed, it should be done on prime95.

If there is a serious need to double-check on GpuOwl, it would be possible to switch it back to type-1, although type-4 is a bit simpler.

[preda]

Originally Posted by R. Gerbicz

There should be no such thing, every iterations should be error checked. Probably this wasn't written in these forums, but here it is how you can change the "L" value in the check:
(so why p95 can change the checks for reliable/unreliable hardwers in a smooth way)

You can also use a Gerbicz error check using different L values, if you have a checked residue at iteration=t, then use a new base:
b=a^(2^t) mod N and you can now use a different L_2.
The only modification in this setup is that now you need to multiple by b not with the small a=3 in the check, but the overhead is very tiny (the extra cost means ~100 more iterations for p~1e8 if you check at every ~1M).

In the last block, where from the last check there is still u*L_2+v (say <L_2*L_2) iterations then after u*L_2 iterations do a check. In the final very few v iterations where you would see v<L_2 iterations force an error check for L_3=v, but this is basically equivalent to a standard boring double check repeating the last v iterations.

In GpuOwl I simply extend the computation past the end to the first multiple of blockSize (L). If that passes, the end was validated. (the residue is extracted at the right spot "end", but the block is continued past that point).

[R. Gerbicz]

Originally Posted by preda

GpuOwl, which recently is doing type-4, should not be used to double-check a type-1 PRP result (because to double-check the type must be the same). Thus, one can't use GpuOwl to double-check a PRP coming from prime95.

In the other direction, prime95 can be used to double-check a type-4 result from GpuOwl (because prime95 is able to do all the types).

Thought that I know what type4, but in undoc.txt in p95:

4 = 64-bit residue of a^((N-c+1)/2), only available if b=2

but for Mersenne number N=2^p-1, so c=-1 --> N-c+1 is odd, so the exponent is not an integer...

[preda]

Originally Posted by R. Gerbicz

Thought that I know what type4, but in undoc.txt in p95:

4 = 64-bit residue of a^((N-c+1)/2), only available if b=2

but for Mersenne number N=2^p-1, so c=-1 --> N-c+1 is odd, so the exponent is not an integer...

https://www.mersenneforum.org/showpo...&postcount=209

type-4 seems to be:
3^((N+1)/2)
where N=2^p - 1,

so type-4 is: 3^(2^(p-1))