Come join us!

[Mini-Geek]

Originally Posted by Puzzle-Peter

Thank you! One last question: when using the script for starting a new base, will kmin equal 1 or 2? 2 is default, is 1 excluded for some reason?

1*b^n-1 is never prime except for the Mersenne primes, because b-1 divides it.
1*b^n+1 can only be prime when n=2^m, i.e. for GFNs.
I'd recommend just making the kmin 1, because the script will automatically do what needs to be done.

[Puzzle-Peter]

nuggetprime, several are marked as "not started" and have no entry in http://www.noprimeleftbehind.net/cru...e-reserves.htm so I assumed I'd have to start from scratch?

[nuggetprime]

yep if there is no reservation you can/have to start it from scratch. Which sierp/riesel base are you going to take?

[Puzzle-Peter]

Originally Posted by nuggetprime

yep if there is no reservation you can/have to start it from scratch. Which sierp/riesel base are you going to take?

R698, it has the smallest conjectured k of all bases left up to 1030.

[rogue]

Originally Posted by Puzzle-Peter

R698, it has the smallest conjectured k of all bases left up to 1030.

That is a good place to start. I recommend running to nmax of 1000. You can go higher than 1000, but if you go too high, then it will take you a much longer time to do the base. After the script has completed, you can run srsieve like this:

srsieve -n1000 -N25000 -P1e12 -m1e12 -w pl_remain.txt

You do not need to sieve that deeply as it depends upon the removal rate of each n. I recommend getting a removal rate of about one n every two minutes. If you intend to do the PRP work on one core, then PFGW is all you need (after modifying the pfgw file output by srsieve). If you then intend to split the PRP work across multiple cores, use PRPNet (you will need to install MySQL).

[gd_barnes]

Originally Posted by nuggetprime

IMPORTANT:
ALL Sierp/Riesel bases < 1030 have been searched to some extent.
Look here
http://www.noprimeleftbehind.net/crus

Huh? I don't think so. This page says nothing about whether or not we have started some bases. If the base is not shown on Riesel conjectures or Sierpinski conjectures or shows "no testing done" then it has not been started. Many bases have not been started. See summarized process stats where it shows "not tested". Nearly 600 bases have not been started...~29% of all of them.

[Puzzle-Peter]

Thanks rogue.

I am used to do LLR from the command line on many cores as I did a lot of offline tests for Prime Grid ( sr5 at the moment). The most recent versions of LLR can test bases other than 2. Or is that too inefficient? A test in the n=580K range takes about 40min on a 3GHz Xeon 5160.

BTW does the CRUS package in the software thread contain the most recent software? I downloaded it yesterday and it had
srsieve 0.6.17
sr1sieve 1.4.1
sr2sieve 1.8.11
llr 3.8.1 windows only. I'm using llr 3.8.4 for Linux from prpnet 4.0.4beta for the sr5 tests.
The readme files point to geocities but all I get there is a page telling me geocities has closed.

If memory serves, sieving speed does not depend too much from the range of n, so I'll probably sieve to N=100K or 1M. When I get bored with testing maybe someone else will pick up the rest of the candidates.

[gd_barnes]

Originally Posted by Puzzle-Peter

Thanks rogue.

I am used to do LLR from the command line on many cores as I did a lot of offline tests for Prime Grid ( sr5 at the moment). The most recent versions of LLR can test bases other than 2. Or is that too inefficient? A test in the n=580K range takes about 40min on a 3GHz Xeon 5160.

BTW does the CRUS package in the software thread contain the most recent software? I downloaded it yesterday and it had
srsieve 0.6.17
sr1sieve 1.4.1
sr2sieve 1.8.11
llr 3.8.1 windows only. I'm using llr 3.8.4 for Linux from prpnet 4.0.4beta for the sr5 tests.
The readme files point to geocities but all I get there is a page telling me geocities has closed.

If memory serves, sieving speed does not depend too much from the range of n, so I'll probably sieve to N=100K or 1M. When I get bored with testing maybe someone else will pick up the rest of the candidates.

You'll want to use PFGW or PRPnet (vs. LLR/LLRnet) on this project. PFGW is as fast as LLR and you can easily tell it to stop searching a k when it finds a prime. You can use the GUI version or the command-line version. I've used both.

Sieving speed varies by the square root of n so is affected by it by quite a bit if you sieve way too much. I don't recommend sieving up to n=1M on most bases. It will take 3 times longer than sieving to n=100K and a lot of it will be wasted on sieving k's where a prime is found at a small n.

One hint that I strongly suggest: Do not bite off too much. It's very easy to do on this project. My suggestion: Reserve one base with not too high of a conjecture, use the script to test it to n=1000 or 2500 and then sieve n=1K-25K or 2.5K-25K and finish testing that. That will give you a good idea of the time involved. Then at that point, you can choose to sieve n=25K-100K if you feel you want to continue with the base.

[gd_barnes]

Originally Posted by rogue

That is a good place to start. I recommend running to nmax of 1000. You can go higher than 1000, but if you go too high, then it will take you a much longer time to do the base. After the script has completed, you can run srsieve like this:

srsieve -n1000 -N25000 -P1e12 -m1e12 -w pl_remain.txt

You do not need to sieve that deeply as it depends upon the removal rate of each n. I recommend getting a removal rate of about one n every two minutes. If you intend to do the PRP work on one core, then PFGW is all you need (after modifying the pfgw file output by srsieve). If you then intend to split the PRP work across multiple cores, use PRPNet (you will need to install MySQL).

I would suggest running srsieve to -P 100e6. Then run sr2sieve to a removal rate of about 30-60 seconds, which for the smaller conjectured bases that are currently remaining is usually around 100e9 to 200e9. Srsieve is very inefficient other than to get started. Peter, there are instructions in the "come join us" thread for running srsieve/sr2sieve. Sr2sieve can be a little tricky if you've never used it before. But once you've used it a couple of times, it's real easy.


Gary

[rogue]

Originally Posted by gd_barnes

I would suggest running srsieve to -P 100e6. Then run sr2sieve to a removal rate of around 2 seconds, which for the smaller conjectured bases that are currently remaining is usually around 100e9 to 200e9. Srsieve is very inefficient other than to get started. Peter, there are instructions in the "come join us" thread for running srsieve/sr2sieve. Sr2sieve can be a little tricky if you've never used it before. But once you've used it a couple of times, it's real easy.

The nuances of sr2sieve, such as the extras steps to use it, are why I have avoided it. Isn't there a point where having too many k makes sr2sieve run slower than srsieve?

Also, since sieving to n=25000 takes less than 24 hours with srsieve (for a small number of k), that's probably not a huge loss. Now if you want to sieve to a higher n, then I would agree that the extra steps for using sr2sieve pay off since you need to sieve for multiple days.

PRPNet can use LLR for bases other than powers of 2. There is a server setting called usellroverpfgw that can be used to force the clients to use LLR if it is available.

[gd_barnes]

Originally Posted by rogue

The nuances of sr2sieve, such as the extras steps to use it, are why I have avoided it. Isn't there a point where having too many k makes sr2sieve run slower than srsieve?

Also, since sieving to n=25000 takes less than 24 hours with srsieve (for a small number of k), that's probably not a huge loss. Now if you want to sieve to a higher n, then I would agree that the extra steps for using sr2sieve pay off since you need to sieve for multiple days.

PRPNet can use LLR for bases other than powers of 2. There is a server setting called usellroverpfgw that can be used to force the clients to use LLR if it is available.

Using srsieve vs. sr2sieve is a huge loss at virtually all levels and #'s of k's. If you have avoided it, you've been using well too much time for testing. (I say testing vs. sieving because you're effectively not sieving enough.) Try it one time and you will never go back. I believe there are detailed instructions in the first few posts in this thread. You'll get optimum sieve depths in the P=150G-200G vs. 40G-50G range for some of the smaller bases and have many less tests to run due to many more pairs removed.

There is only one extra step to use on sr2sieve: Remove factors.

The only time that sr2sieve cannot be used is for huge #'s of k's and that's only because of memory allocation. A recent example is S63. But for all reasonable bases that new users will be starting, sr2sieve is a must.


Gary