Reserving R3 to n=800k (750-800k) (0-2.147G) for BOINC

[QUOTE=rogue;509282]I can now estimate when I expect to complete these ranges. I have one older laptop that is doing about 20,000 rows from the ABC file per day. Based upon how I split the sieved range across 5 threads, this will take close to 120 days to complete. The newer computers are able to do nearly 60,000 rows per day. I estimate those to take about 40 days to complete. In fact the faster ones are nearly 20% done with a 1G range. I also realized that I sieved way too deeply. I waited until the removal rate was about one term every four seconds, but I only needed to wait for it to remove about one term every two seconds (as I sieved on a faster machine).[/QUOTE]

I have an update. The first core is done with PRP testing. The rest of the cores on that machine should finish in the next few days. That will complete the first 1G range of my reservation to n=100000

[QUOTE=rogue;512220]I have an update. The first core is done with PRP testing. The rest of the cores on that machine should finish in the next few days. That will complete the first 1G range of my reservation to n=100000[/QUOTE]

About 15% of the PRPs in the one range failed the pfgw primality test. :glare:

Fortunately the latest llr shows that they are prime, so this tells me that the current official release of pfgw is somehow failing to prove them prime.

I do have an unofficial release of pfgw that has the latest gwnum, gmp, and pirmesieve. It does prove primality on the numbers, but as I just got it to compile and link today, I won't be using it for these ranges. I don't have a AVX512 CPU so I wouldn't gain much by using it at this time.

Because the "in development" version of pfgw works, I will not fix 3.8.3. This leads me to suspect that some primes were missed for n < 25000 if that range was tested with pfgw, which is what srbsieve does. The reason is that srbsieve will do a primality test before accepting a candidate as prime and removing the k.

If it hasn't been done, there might be value in rerunning the remaining k for S3 and R3 to n=25000, but using llr for primality tests instead of pfgw. Interestingly none of the failed primality tests were for n under 30000.

If anyone has version 3.7.7, 3.7.8 or 3.7.9, can you do a primality test on 58003099298*3^49921-1 and let me know the results? I rarely touch the primality testing code and I don't see how any changes I made to the version in development that would fix the issue I see found in 3.8.3.

[QUOTE=rogue;512268]About 15% of the PRPs in the one range failed the pfgw primality test. :glare:

Fortunately the latest llr shows that they are prime, so this tells me that the current official release of pfgw is somehow failing to prove them prime.

I do have an unofficial release of pfgw that has the latest gwnum, gmp, and pirmesieve. It does prove primality on the numbers, but as I just got it to compile and link today, I won't be using it for these ranges. I don't have a AVX512 CPU so I wouldn't gain much by using it at this time.

Because the "in development" version of pfgw works, I will not fix 3.8.3. This leads me to suspect that some primes were missed for n < 25000 if that range was tested with pfgw, which is what srbsieve does. The reason is that srbsieve will do a primality test before accepting a candidate as prime and removing the k.

If it hasn't been done, there might be value in rerunning the remaining k for S3 and R3 to n=25000, but using llr for primality tests instead of pfgw. Interestingly none of the failed primality tests were for n under 30000.

If anyone has version 3.7.7, 3.7.8 or 3.7.9, can you do a primality test on 58003099298*3^49921-1 and let me know the results? I rarely touch the primality testing code and I don't see how any changes I made to the version in development that would fix the issue I see found in 3.8.3.[/QUOTE]

I´m not entirely sure that I used PFGW 3.6.4 when using srbsieve for R3 k>15G-60G for n<=25K - but has you tried to see what result your candidate comes back with when using PFGW 3.6.4?

If PFGW 3.6.4 proves the PRP as prime, then I think (hope) that nothing is missed, because even though its been a while now, I do honestly think that it was version 3.6.4 of the console version of PFGW that I used for all my srbsieve work :smile:

It might be worth testing if the problem actually does not emerge/appear before n>30K - because it is a bit of a work to look for a "few" missed k´s among the several hundred thousand k´s remaining at n=25K - it´s a job that can somewhat be easily done but is it worth it? Of course if we have missed 15% of our k´s and their primes because of a faulty primality test it will definently be worth it :smile:

I´ve begund a doublecheck for following range:

kMin=59840314894
kMax=59999908952

I´ll use LLR 3.8.21 console version and StopOnPrimedK=1

In about an hour, I´ll have the 1,000 k´s sieved to p=1G and then I´ll split the file in four and start testing n=1 to n=25K for missed primes.

Hopefully nothing turns out, but if in fact PFGW fails to prove 15% of the PRPs as prime, there might very well be something to Marks suspecsion :smile:

I´ll get back to you all, once I have the final result.

Take care

I was hoping that someone could test the number I provided on one or more older versions of pfgw. Right now I'm suspecting a miscompile or an issue in that v28.6 of gwnum. I cannot compare the results to llr because it uses a different method to prove primality.

[QUOTE=KEP;512286]I´ve begund a doublecheck for following range:

kMin=59840314894
kMax=59999908952

I´ll use LLR 3.8.21 console version and StopOnPrimedK=1

In about an hour, I´ll have the 1,000 k´s sieved to p=1G and then I´ll split the file in four and start testing n=1 to n=25K for missed primes.

Hopefully nothing turns out, but if in fact PFGW fails to prove 15% of the PRPs as prime, there might very well be something to Marks suspecsion :smile:

I´ll get back to you all, once I have the final result.

Take care[/QUOTE]

I´m still waiting for LLR to complete testing. LLR is ineffecient on these small tests, but still around n=11K.

PFGW console version 3.8.3.7 Windows 64-bit has found no PRPs and therefor no missed primes among these 1,000 k´s according to PFGW. I expect LLR (the 4 latest versions) to conqur on that result. There might be missing k´s on the Sierpinski side, but all my srbsieve work did use the much older PFGW console version 3.6.4 - so I think at least all my R3 n<=25K work should be safe and OK. But sure it will be a mess if something was actually missed on the Sierpinski side.

I´ve finished checking this range:

kMin=59840314894
kMax=59999908952

Total k´s: 1000 (sieved to p=1e9)

No Primes found and therefor 0 k´s missed

I´ve used PFGW3.8.3.7, LLR 3.8.18, LLR 3.8.20, LLR 3.8.21 and LLR 3.8.22

This range is in other words tested 5 times plus the original run. PFGW aswell LLR has matching residues, so in total has now an exact amount of 685,865 tests computed 5 matching residues for each k*3^n-1 test when PFGW and LLR results are compared. So to be honest I do not think we have any problems on the Riesel side and I think that PFGW 3.6.4 is safe and all testing done with PFGW version 3.6.4 should be considered safe :smile:

Take care everyone and hope it helped :smile:

KEP

58G completed to n=100000. 4450 primes are attached. These were proven prime with a combination of the old pfgw and llr then verified again with the current pfgw in development.

[QUOTE=rogue;512814]58G completed to n=100000. 4450 primes are attached. These were proven prime with a combination of the old pfgw and llr then verified again with the current pfgw in development.[/QUOTE]


Do you have a results file? I usually ask for results for n>25K.

[QUOTE=gd_barnes;512832]Do you have a results file? I usually ask for results for n>25K.[/QUOTE]

Sorry, but I do not. I had just assumed that the file would be unmanageable. If I take on more reservations for n>25000, I will do that.