20100628, 21:26  #1 
May 2007
Kansas; USA
10100000000110_{2} Posts 
Sieving drive Riesel base 6 n=1M2M
This is a sieving drive for the final 2 k's remaining on Riesel base 6 for n=1M2M. Lennart has kindly gotten us started. The k's remaining and their weights are:
k=1597; weight 272 k=36772; weight 583 This is a very exciting base where k's have fallen quickly. We now have a very good chance of proving it over the next 12 years. The optimum sieve depth is probably in the P=170T175T range. We will be using sr2sieve but because the 2 k's are so different weight, we will possibly eventually sieve them to different depths using sr1sieve. It is recommended that you run 64bit sr2sieve on a 64bit machine. Let us know if you need the executable or more detailed instructions on using it. Here is an example of the command to execute at the command prompt: sr2sieve p 50e12 P 60e12 i sieverieselbase61M2M.txt The above would be if you were sieving P=50T60T. The file is listed after the "i" command and is the actual file name that is attached below. Feel free to name it something shorter if you want or use the "srwork" older convention where you don't have to specify a file name. When complete, you should have a factors.txt file. Just post the file here in this thread or if it is too big, please Email the file to me at: gbarnes017 at gmail dot com A P=1T range should take ~12 CPU days on one core of a modern 64bit machine. Please reserve ranges in multiples of P=1T and plan to reserve no more than ~7 days of work at a time. When making reservations, please post your estimated completion date. This can be seen in sr2sieve about one minute after you start your sieve. Attached is the latest sieve file. All factors up to P=100T have been removed. We will remove additional factors as the drive progresses to slightly speed up sieving. Reservations: Code:
Prange reserved by status est. completion date 0T 40T Lennart complete 40T 45T Flatlander complete 45T 70T Lennart complete 70T 80T Dougal complete 80T180T gd_barnes complete All help is greatly appreciated! Thank you, Gary Last fiddled with by gd_barnes on 20110122 at 08:11 Reason: status update 
20100628, 22:29  #2  
"Lennart"
Jun 2007
2^{5}·5·7 Posts 
Quote:
I can start the sieve. Lennart Last fiddled with by gd_barnes on 20100630 at 09:11 Reason: remove quoted part not applicable 

20100628, 22:40  #3 
May 2007
Kansas; USA
2×47×109 Posts 
Great, after you have sieved to some nominal depth, perhaps P=1T or something like that, just send me the 2 files and I'll start a formal drive.
k=1597 would be higher priority right now. When the sieving for it is complete, we can start searching n>1M. 
20100629, 21:40  #4  
"Lennart"
Jun 2007
2^{5}·5·7 Posts 
Quote:
I am soon done to 13T I use sr2sieve 1.8.11 it is a little faster when you have a few sequences. Lennart 

20100629, 23:24  #5 
"Lennart"
Jun 2007
2^{5}·5·7 Posts 
Her is the file in abcd format. Sieved to 13T
I reserve 13T22T ( they are started ) Lennart Last fiddled with by Lennart on 20100629 at 23:32 
20100629, 23:54  #6 
A Sunny Moo
Aug 2007
USA (GMT5)
3×2,083 Posts 
I've split off the posts regarding n=1M2M sieving to a new thread so they don't clutter up the main drive thread. Gary, I'll leave it up to you to set up a reservations table and whatnot since I don't know exactly at what point you were going to start that.

20100630, 03:36  #7 
"Phil"
Sep 2002
Tracktown, U.S.A.
1118_{10} Posts 
I really don't understand the logic of sieving these two sequences separately. The optimum sieving depth for sieving together should be greater than the optimum depth for separate sieving, shouldn't it?

20100630, 05:58  #8  
May 2007
Kansas; USA
10246_{10} Posts 
Quote:
I'd like to run a few tests myself because the calculations are quite complex with 2 extremely different weights. Since these remaining k's are so different in weight, one is nearly double the weight of the other, I was advocating sieving them separately. Personally, I would like to run them separately at some point but for the time being, we'll go ahead and run them together. Perhaps once we reach P=~50T or so, we should do a detailed analysis of what works best. In other words, we may find that THIS: lowweight k sieved to P=300T highweight k sieved to P=500T Is more effective as for total sieving and testing CPU time than this: Both k's sieved to P=400T. It will be a tricky calculation but one that I feel is worth it at such a high nlevel. One other big reason that I was thinking we would like to sieve them separately is that the high weight k is only tested to n=600K right now whereas the low weight k is already at n=1M. We may not need the high weight k sieve file at all. Lennart, because we don't have k=36772 searched to n=1M yet, what do you think about separating them at about P=50T and only sieve k=1597 for a while using sr1sieve? Based on the circumstances, what do others think? Last fiddled with by gd_barnes on 20100630 at 08:28 

20100630, 07:13  #9 
"Lennart"
Jun 2007
2^{5}×5×7 Posts 
Reserving 22T40T
I shall start a test on the low k and compare p/sec. at 13T 1M2M I have k 1597 5921 candidates left k 36772 12229 left. I will now start a test on sr1sieve on each k and give you p/sec and one with both on sr2sieve I will use one computer and use t8 Lennart Last fiddled with by Lennart on 20100630 at 07:25 
20100630, 07:44  #10 
May 2007
Kansas; USA
2·47·109 Posts 
I have done a calculation running sr1sieve vs. sr2sieve:
Set up: Intel I7 @ 2.94 Ghz. 3 other LLR/PFGW processes running in background so as to not affect the throughput in any way. Test 1: Sr2sieve on both k's for P=1G5G. Time: 349 secs. Test 2: Sr1sieve on k=1597 for P=1G5G. Time: 155 secs. Sr1sieve on k=36772 for P=1G5G. Time: 202 secs. Total time: 357 secs. Sr2sieve is 357 / 349  1 = ~2.3% faster. Sr1sieve tests were run in batch so as to avoid any extra CPU time from manually starting each of them. One could conclude this intuitively if one knew that sr1sieve and sr2sieve use the exact same types of calculations, which they apparently do now. Why? Because the further apart the weights are, the greater difference in time taken between the 2 and the less efficient it becomes to sieve the lower weight k. That is, if there were only 10 terms remaining on k=1597 and all remaining terms were on k=36772, it would be highly inefficient to sieve only the 10 terms. BUT...it was not clear to me if the 2 programs were using the exact same processes. I am now convinced of such. Therefore: It always makes sense to run sr2sieve to at least the optimal depth of the lower weight k, if that depth is calculated while running sr1sieve and then run sr1sieve on the higher weight k until it is at optimal using that program. Conclusion: We should definitely use sr2sieve up to some, as of yet, unknown depth. That depth should be based on 3 things: 1. The optimal depth of k=1597 run only by itself using sr1sieve. 2. The chance of k=36772 having a prime for n=600K1M. 3. Can we have and will we be ready to start testing k=1597 for n>1M before testing of k=36772 is complete to n=1M? #'s 1 and 2 can be calculated, although deciding how the chance in #2 should reduce the optimal depth of running both k's together is not very clear. #3 is very tough to decide upon. This seems unlikely to happen but: If we cannot have k=1597 fully sieved for n=1M2M before k=36772 testing is done to n=1M, it makes sense to just sieve both k's using sr2sieve to nearly the optimal depth of k=1597 (computing it's optimum using sr1sieve), and then run k=36772 to it's optimal depth running sr1sieve. That's the way I would approach it if k=36772 was already tested to n=1M. Lennart, as of yet, I haven't turned it into a formal sieving drive. When I do, I'll edit the 1st posting for reserved ranges and the such and sticky the thread. If you would just like to keep on running both k's with sr2sieve up to P=50T or 100T as your resources allow, I think that is quite reasonable. We don't have any huge demand for testing k=1597 for n>1M at this moment. One more thing: Because max n / min n = 2, as demonstrated by VBCurtis at RPS, no ranges should be broken off. We'll sieve the entire nrange to the same depth (for each k, although different depths for the 2 k's) and it should be sievied until the removal rate equals the test time of a candidate at approximately 5560% of the nrange, i.e. n=1.55M1.6M. I have an exact calculation on that from some work I've done on some of my personal efforts that I can demonstrate later on. Gary Last fiddled with by gd_barnes on 20100630 at 09:18 
20100630, 08:14  #11 
"Lennart"
Jun 2007
10001100000_{2} Posts 
Here are my timings.
sr1sieve 1.41 1597 sr1sieve 133514792 p/sec 36772 sr1sieve 111216565 p/sec Both k using sr2sieve 1.8.11 71742478 p/sec Lennart 
Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
Riesel base 6  team drive #4  EIGHT OR BUST!  gd_barnes  Conjectures 'R Us  401  20150527 15:15 
Riesel base 16  team drive #2  gd_barnes  Conjectures 'R Us  213  20140226 09:35 
Sieving Riesel & Sierp base 16  gd_barnes  Conjectures 'R Us  13  20091214 09:23 
Sieving drive Riesel base 6 n=150K1M  gd_barnes  Conjectures 'R Us  27  20091008 21:49 
Riesel base 3  minidrive I  gd_barnes  Conjectures 'R Us  199  20090930 18:44 