20230404, 21:56  #67 
"Gary"
May 2007
Overland Park, KS
5×7×359 Posts 
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 multicore, 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 singlecore process. Everything matched very well. I was especially happy how well it sieves a widerange of k along with multiple n vs. NewPGen's singlen process. Of course this is all likely old news to you since I'm guessing you used it for sieving the original n=480K500K 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. Last fiddled with by gd_barnes on 20230404 at 21:57 
20230405, 01:35  #68  
"Michael Kwok"
Mar 2006
2·607 Posts 
Quote:
Regarding the sieving for the original n=480K500K 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. Last fiddled with by MooMoo2 on 20230405 at 01:35 

20230419, 05:10  #69  
Sep 2011
Potsdam, Germany
5×31 Posts 
Quote:
did you already test the new prprnet server 5.5? Regards Odi 

20230420, 22:45  #70 
"Gary"
May 2007
Overland Park, KS
5·7·359 Posts 
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.

20230722, 18:45  #71  
"Michael Kwok"
Mar 2006
2276_{8} Posts 
Quote:
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 doublecheck with different hardware and possibly different software as well. Gary, could you resieve random ranges (i.e., p=8T9T) 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^17000001, k*2^1700000+1, k*2^16999991, and k*2^17000011. 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. 

20230723, 19:22  #72 
Jul 2022
11 Posts 
These are the first two results from http://www.noprimeleftbehind.net/tps..._tps_12000.txt: Code:
user=odicin [20230613 00:27:22] 385272479865*2^17000001 is not prime. Res64: 7D84DEC6EB43C38B Time : 0.0 sec. user=kruoli [20230613 00:32:49] 385322591955*2^17000001 is not prime. Res64: 37869057674ACF04 Time : 0.0 sec. Code:
LLR Program  Version 3.8.16, using Gwnum Library Version 28.7 385272479865*2^17000001 is not prime. LLR Res64: 7D84DEC6EB43C38B Time : 1681.452 sec. 385322591955*2^17000001 is not prime. LLR Res64: B1ED52BBD9F6DE3E Time : 1703.661 sec. Code:
LLR Program  Version 3.8.16, using Gwnum Library Version 28.7 385272479865*2^17000001 is not prime. LLR Res64: 7D84DEC6EB43C38B Time : 1073.619 sec. 385322591955*2^17000001 is not prime. LLR Res64: B1ED52BBD9F6DE3E Time : 1074.299 sec. Last fiddled with by whengryphonsfly on 20230723 at 20:16 Reason: Correct post based on new information 
20230723, 19:40  #73 
"Oliver"
Sep 2017
Porta Westfalica, DE
1826_{10} Posts 
Is that version running a PRP test? My LLR version does a PRP test.

20230723, 20:15  #74 
Jul 2022
11 Posts 
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:
Code:
385322591955*2^17000001 is not prime. RES64: 37869057674ACF04. OLD64: A693B10635E06D0B Time : 1077.301 sec. 
20230724, 08:16  #75 
"Gary"
May 2007
Overland Park, KS
5·7·359 Posts 
I'll do some sieving for this on Monday as well as run a few doublechecks. 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. Last fiddled with by gd_barnes on 20230724 at 09:20 
20230724, 14:46  #76  
"Alexander"
Nov 2008
The Alamo City
2×3^{3}×19 Posts 
Quote:
Code:
155877*2^30321 is a Fermat Probable prime! (918 decimal digits) Time : 17.529 ms. 155877*2^30321 is prime! (918 decimal digits) Time : 8.533 ms. 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 fixedk (and thus not used here)? Last fiddled with by Happy5214 on 20230724 at 14:48 Reason: Clip first line of quote (didn't respond to it) 

20230724, 15:24  #77 
"Oliver"
Sep 2017
Porta Westfalica, DE
722_{16} Posts 
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.

Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
A question about twin primes and twin practical numbers  sweety439  sweety439  1  20220423 14:32 
find very easy twin prime in the infamy twin primes  hal1se  Miscellaneous Math  13  20181105 16:34 
pie chart: LL attempts  sixblueboxes  PrimeNet  8  20140418 14:46 
Next steps for TPS after Primegrid's record twin discovery  axn  Twin Prime Search  7  20111231 07:04 
LLD attempts and successes  Christenson  Information & Answers  1  20110203 05:25 