Register FAQ Search Today's Posts Mark Forums Read

2011-01-20, 17:56   #67
Mini-Geek
Account Deleted

"Tim Sorbera"
Aug 2006
San Antonio, TX USA

4,271 Posts

Quote:
 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.

 2011-01-20, 17:58 #68 Puzzle-Peter     Jun 2009 22×173 Posts 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? Last fiddled with by Puzzle-Peter on 2011-01-20 at 17:58
 2011-01-20, 18:04 #69 nuggetprime     Mar 2007 Austria 1001011102 Posts yep if there is no reservation you can/have to start it from scratch. Which sierp/riesel base are you going to take?
2011-01-20, 18:29   #70
Puzzle-Peter

Jun 2009

69210 Posts

Quote:
 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.

2011-01-20, 18:42   #71
rogue

"Mark"
Apr 2003
Between here and the

197D16 Posts

Quote:
 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).

2011-01-20, 19:48   #72
gd_barnes

May 2007
Kansas; USA

2·3·5·353 Posts

Quote:
 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.

Last fiddled with by gd_barnes on 2011-01-20 at 20:06

 2011-01-20, 19:53 #73 Puzzle-Peter     Jun 2009 12648 Posts 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.
2011-01-20, 20:00   #74
gd_barnes

May 2007
Kansas; USA

2×3×5×353 Posts

Quote:
 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.

Last fiddled with by gd_barnes on 2011-01-20 at 20:05

2011-01-20, 20:10   #75
gd_barnes

May 2007
Kansas; USA

2×3×5×353 Posts

Quote:
 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

Last fiddled with by gd_barnes on 2011-01-20 at 21:21

2011-01-20, 21:01   #76
rogue

"Mark"
Apr 2003
Between here and the

652510 Posts

Quote:
 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.

2011-01-20, 21:21   #77
gd_barnes

May 2007
Kansas; USA

2×3×5×353 Posts

Quote:
 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

Last fiddled with by gd_barnes on 2011-01-20 at 21:26

 Similar Threads Thread Thread Starter Forum Replies Last Post gd_barnes No Prime Left Behind 36 2021-10-14 20:05 maxmax Information & Answers 5 2011-02-09 21:59 gian92 Software 0 2008-02-22 21:08 drakkar67 15k Search 2 2005-08-30 18:20 junky NFSNET Discussion 3 2004-07-05 04:05

All times are UTC. The time now is 03:40.

Wed Jan 19 03:40:59 UTC 2022 up 179 days, 22:09, 0 users, load averages: 0.84, 0.92, 1.04