n=1.7M and n=3.322M Twin-Sophie record attempts

[gd_barnes]

Nice detailed analysis! A true stats nerd like me.

I downloaded TwinGenX. It's a very nice GUI program even from 2012! It's basically a modernized NewPGen for multi-core, if you can call 2012 modernized at this point. I feel like it's aged well. I ran some parallel tests running TwinGenX on multiple cores vs. NewPGen's single-core process. Everything matched very well. I was especially happy how well it sieves a wide-range of k along with multiple n vs. NewPGen's single-n process. Of course this is all likely old news to you since I'm guessing you used it for sieving the original n=480K-500K range here.

I mostly concur with your percentages. I'd even put it at ~90% that the prime gods are just being mean to us. I still feel PRPnet is pretty low because I've run this version of PRPnet (5.3.2) for so long at NPLB and on my personal efforts that it looks pretty clean. It has handled twin prime searches pretty well even though it was never tested on Sophies. (I see that Mark has recently fixed the Sophie issue in version 5.5.7.)

Here are my percentages:

90% mean prime gods
4% LLR
3% PRPnet
2% hardware from various users
1% sieving software

If we hit 100,000 tests without a prime, all bets are off. Perhaps some real investigation may be in order.

[MooMoo2]

Originally Posted by gd_barnes

Nice detailed analysis! A true stats nerd like me.

I downloaded TwinGenX. It's a very nice GUI program even from 2012! It's basically a modernized NewPGen for multi-core, if you can call 2012 modernized at this point. I feel like it's aged well. I ran some parallel tests running TwinGenX on multiple cores vs. NewPGen's single-core process. Everything matched very well. I was especially happy how well it sieves a wide-range of k along with multiple n vs. NewPGen's single-n process. Of course this is all likely old news to you since I'm guessing you used it for sieving the original n=480K-500K range here.

I mostly concur with your percentages. I'd even put it at ~90% that the prime gods are just being mean to us. I still feel PRPnet is pretty low because I've run this version of PRPnet (5.3.2) for so long at NPLB and on my personal efforts that it looks pretty clean. It has handled twin prime searches pretty well even though it was never tested on Sophies. (I see that Mark has recently fixed the Sophie issue in version 5.5.7.)

Here are my percentages:

90% mean prime gods
4% LLR
3% PRPnet
2% hardware from various users
1% sieving software

If we hit 100,000 tests without a prime, all bets are off. Perhaps some real investigation may be in order.

Hmmm, interesting ;)

Regarding the sieving for the original n=480K-500K range, I think the bulk of it was done via Ken's TPSieve software (https://www.mersenneforum.org/showpo...&postcount=308 ; some sample outputs and very early benchmarks are at https://www.mersenneforum.org/showpo...9&postcount=68).

IIRC, NewPGen was used only for a very short time at the very beginning of the sieve, and TwinGen/TwinGenX wasn't used at all.

[odicin]

Originally Posted by gd_barnes

[..] So something is clearly messed up.

At this point, I contacted Mark (rogue) who created everything related to PRPnet. He said he thought there was a bug in the server code and would need to work on it.

My thinking at this point: No one had ever attempted to run a PRPnet server for SGs before -or- there is something in my process messing things up. I'm leaning towards the former but can't say for sure.

I think we don't want to introduce any new code at this point. Let's see if Mark can get the existing code working correctly for SGs. I'll then do some extensive testing on it.

In the mean time, let's make sure we get off on the right foot and stick to having the server run twins. If Mark gets the code fixed and I'm convinced through extensive testing that it works correctly, then we can consider having it run SGs instead since the files are going to be quad sieved.

Hi Gary,

did you already test the new prprnet server 5.5?

Regards Odi

Originally Posted by rogue

I have posted PRPNet 5.5 over at sourceforge. Here are the changes:

[..]
Fixed Sohpie-Germain server support.
[..]

[gd_barnes]

Originally Posted by odicin

Hi Gary,

did you already test the new prprnet server 5.5?

Regards Odi

I have not. Max has updated our 2 private servers to version 5.4.7 and we have been running "normal" tests on it with no problems. I'm not sure if that version has the fix for Sophies in it. I'd rather wait to do an upgrade on a public server until we've done extensive testing on it.

[MooMoo2]

Originally Posted by gd_barnes

Nice detailed analysis! A true stats nerd like me.

I downloaded TwinGenX. It's a very nice GUI program even from 2012! It's basically a modernized NewPGen for multi-core, if you can call 2012 modernized at this point. I feel like it's aged well. I ran some parallel tests running TwinGenX on multiple cores vs. NewPGen's single-core process. Everything matched very well. I was especially happy how well it sieves a wide-range of k along with multiple n vs. NewPGen's single-n process. Of course this is all likely old news to you since I'm guessing you used it for sieving the original n=480K-500K range here.

I mostly concur with your percentages. I'd even put it at ~90% that the prime gods are just being mean to us. I still feel PRPnet is pretty low because I've run this version of PRPnet (5.3.2) for so long at NPLB and on my personal efforts that it looks pretty clean. It has handled twin prime searches pretty well even though it was never tested on Sophies. (I see that Mark has recently fixed the Sophie issue in version 5.5.7.)

Here are my percentages:

90% mean prime gods
4% LLR
3% PRPnet
2% hardware from various users
1% sieving software

If we hit 100,000 tests without a prime, all bets are off. Perhaps some real investigation may be in order.

I've tried to "ignore" (for lack of a better word) this issue in the hopes that it would resolve itself once more tests were done and some primes were found. But we're now at 135,890 tests done for n=1.7M with not a single prime found

Statistically, we should have found 7 primes by now and had a 99.9% chance of at least one prime. I know the prime gods can be mean, but I don't think they're that mean...

I'd like to run a limited double-check with different hardware and possibly different software as well. Gary, could you re-sieve random ranges (i.e., p=8T-9T) on the n=1.7M sieve file with NewPGen and/or TwinGenX to see if any candidates are removed? The "Lucky Minus" sieve option should be selected, which sieves k*2^1700000-1, k*2^1700000+1, k*2^1699999-1, and k*2^1700001-1. Another thing we could do is to create a new sieve file from scratch (let's call this "Sieve A"), sieve it to a relatively low depth, and compare it to our current sieve file ("Sieve B"). Due to the different sieve depths, it's expected that some candidates in Sieve A will not appear in Sieve B, but if there are any candidates in Sieve B that do not appear in Sieve A, that would be a huge red flag.

Also, could someone randomly select and test a few candidates for n=1.7M, k<450G? Everything in that range has already been tested, and the residues should match those at: http://www.noprimeleftbehind.net/tps/results/llrnet/ If everything checks out, the problem most likely lies in PRPNet and/or LLR.

[whengryphonsfly]

I suspect this is a hardware/software issue. See next two replies.

These are the first two results from http://www.noprimeleftbehind.net/tps..._tps_12000.txt:

user=odicin
[2023-06-13 00:27:22]
385272479865*2^1700000-1 is not prime.  Res64: 7D84DEC6EB43C38B  Time : 0.0 sec.
user=kruoli
[2023-06-13 00:32:49]
385322591955*2^1700000-1 is not prime.  Res64: 37869057674ACF04  Time : 0.0 sec.

Here are those tests rerun on "alpha", a Linux Mint 21.2 Ryzen 3900X machine:

LLR Program - Version 3.8.16, using Gwnum Library Version 28.7
385272479865*2^1700000-1 is not prime.  LLR Res64: 7D84DEC6EB43C38B  Time : 1681.452 sec.
385322591955*2^1700000-1 is not prime.  LLR Res64: B1ED52BBD9F6DE3E  Time : 1703.661 sec.

And here are those tests rerun on "beta", a Windows 10.0.19044 Core i7-9750H machine:

LLR Program - Version 3.8.16, using Gwnum Library Version 28.7
385272479865*2^1700000-1 is not prime.  LLR Res64: 7D84DEC6EB43C38B  Time : 1073.619 sec.
385322591955*2^1700000-1 is not prime.  LLR Res64: B1ED52BBD9F6DE3E  Time : 1074.299 sec.

Edit: I'm testing more candidates just to make sure it wasn't a fluke.

[kruoli]

Is that version running a PRP test? My LLR version does a PRP test.

[whengryphonsfly]

I was running a true primality test, not a PRP test. And you are correct in thinking that was the issue. Rerunning with -oForcePRP=1:

385322591955*2^1700000-1 is not prime.  RES64: 37869057674ACF04.  OLD64: A693B10635E06D0B  Time : 1077.301 sec.

[gd_barnes]

I'll do some sieving for this on Monday as well as run a few double-checks. I had done a little test sieving previously to a lower depth and did not find there were any tests missing in our big sieve. I don't think it's going to be a sieving problem.

There is almost definitely a problem in either LLR or PRPnet at this point. There were quite a few changes in LLR related to PRP tests and the such in the last year or so. It's possible that PRPnet is not picking something up on residuals correctly or that LLR is writing out primes in an unusual manner. Perhaps PRPnet is having problems specifically related to running twin searches.

[Happy5214]

Originally Posted by gd_barnes

There is almost definitely a problem in either LLR or PRPnet at this point. There were quite a few changes in LLR related to PRP tests and the such in the last year or so. It's possible that PRPnet is not picking something up on residuals correctly or that LLR is writing out primes in an unusual manner. Perhaps PRPnet is having problems specifically related to running twin searches.

Here's an example LLR 3.8.24 log output from one of my archives:

155877*2^3032-1 is a Fermat Probable prime! (918 decimal digits)  Time : 17.529 ms.
155877*2^3032-1 is prime! (918 decimal digits)  Time : 8.533 ms.

PRPNet doesn't actually recognize the first line, so it uses the second line and correctly marks it as a prime (and would correctly recognize a PRP that turns out to be a pseudoprime with the LLR test residue).

I've used PRPNet (granted, more recent versions) with LLR 3.8.24 and newer without issues for a couple of years. I'll admit I've never done twin searching with PRPNet (my twin tests on the results tend to be perfunctory), so I couldn't tell you if that's a possible issue. Looking at the prpserver.ini comments, shouldn't a Twin server type be fixed-k (and thus not used here)?

[kruoli]

As a test, I quadruple sieved b=2, n=1.7e6 up to k=1e9 and p=1e12 and got the same results (plus extra ones, of course) as the server was loaded with.