mersenneforum.org CRUS sieving questions
 Register FAQ Search Today's Posts Mark Forums Read

2022-12-07, 20:15   #12
rogue

"Mark"
Apr 2003
Between here and the

2·72·71 Posts

Quote:
 Originally Posted by storm5510 I suspected as much. The series I am running jumps from 36 to 1770 and upward for the k's. There is no cover-all P for this. I think I will just set it at 1e12 for now and see how it goes. Note: I think you meant 250,000 above.
I meant that the conjectures I am sieving are from n=10000 to n=25000. You are looking at one for n=100000 to n=250000.

Run a test for k*b^200000+1 (+1 or -1 doesn't matter much) in llr for one of the k. The number of seconds for that test is what you should aim for for "seconds per factor" with srsieve2cl. I suggest that you do not specify -P and let it continue running. When you reach the desired removal rate use ^C to stop srsieve2cl.

You should also play with -g. The default is -g8, but I use -g32. That seems to be the sweet spot for my GPUs. I aim for a value that is a power of 2 or a multiple of 8/16 due to how GPUs are built.

2022-12-07, 23:46   #13
storm5510
Random Account

Aug 2009
Not U. + S.A.

23·32·5·7 Posts

Quote:
 Originally Posted by rogue I meant that the conjectures I am sieving are from n=10000 to n=25000. You are looking at one for n=100000 to n=250000. Run a test for k*b^200000+1 (+1 or -1 doesn't matter much) in llr for one of the k. The number of seconds for that test is what you should aim for for "seconds per factor" with srsieve2cl. I suggest that you do not specify -P and let it continue running. When you reach the desired removal rate use ^C to stop srsieve2cl. You should also play with -g. The default is -g8, but I use -g32. That seems to be the sweet spot for my GPUs. I aim for a value that is a power of 2 or a multiple of 8/16 due to how GPUs are built.
I ran the first sieve at -g16. Increasing it to -g32 was not going to make any difference for the second, so I put it back to -g16. For now, I am running -P at 11e11, (1.1e12). I can creep it up as the k's get larger.

Windows: cllr -q"1770*2^200000-1" did not produce any screen output. I do not know what it was doing.

2022-12-08, 02:13   #14
VBCurtis

"Curtis"
Feb 2005
Riverside, CA

2·3·937 Posts

Quote:
 Originally Posted by storm5510 .... I can creep it up as the k's get larger.
Do all the k's at once. See Gary's last post- you replied to it, but didn't answer his "you'll be sieving all the ks at once, correct?"

The software is designed to sieve multiple k's at the same time, and is meaningfully faster that way. Please don't do one k at a time- you're wasting massive human time as well as making the job much much slower.

All k's in a single abcd file, to a single P value.

2022-12-08, 04:15   #15
rogue

"Mark"
Apr 2003
Between here and the

695810 Posts

Quote:
 Originally Posted by storm5510 I ran the first sieve at -g16. Increasing it to -g32 was not going to make any difference for the second, so I put it back to -g16. For now, I am running -P at 11e11, (1.1e12). I can creep it up as the k's get larger. Windows: cllr -q"1770*2^200000-1" did not produce any screen output. I do not know what it was doing.
I believe that the time for the test it is output to a file in that directory.

2022-12-08, 07:54   #16
gd_barnes

"Gary"
May 2007
Overland Park, KS

270178 Posts

Quote:
 Originally Posted by gd_barnes Sieving n=100K-250K is a good range. Just checking: You will be sieving all of the k's at one time. Is that correct? There are no formal reservations for sieving. Just state here in this thread that you will be sieving R60 for n=100K-250K.
Quote:
 Originally Posted by storm5510 I ran the first sieve at -g16. Increasing it to -g32 was not going to make any difference for the second, so I put it back to -g16. For now, I am running -P at 11e11, (1.1e12). I can creep it up as the k's get larger. Windows: cllr -q"1770*2^200000-1" did not produce any screen output. I do not know what it was doing.
Why are you running one k at a time? Per above, I asked if you were sieving all k's at once thinking that you might attempt to run one at a time based on your previous comments. Not only is 1k at a time inefficient from a sieving perspective, it involves much more personal effort. Put all 33 k's in a file and run them all at once. The modern sieving programs were designed for this.

My suggestion at this point: Throw out what you've done and start completely over. It will save you a lot of personal and computer time in the long run.

I guess I'm beating a dead horse since I just realized at the end of my post that Curtis already responded to this. We just don't want you to waste a lot of time.

2022-12-08, 16:55   #17
storm5510
Random Account

Aug 2009
Not U. + S.A.

1001110110002 Posts

Quote:
 Originally Posted by gd_barnes Why are you running one k at a time? Per above, I asked if you were sieving all k's at once thinking that you might attempt to run one at a time based on your previous comments. Not only is 1k at a time inefficient from a sieving perspective, it involves much more personal effort. Put all 33 k's in a file and run them all at once. The modern sieving programs were designed for this. My suggestion at this point: Throw out what you've done and start completely over. It will save you a lot of personal and computer time in the long run. I guess I'm beating a dead horse since I just realized at the end of my post that Curtis already responded to this. We just don't want you to waste a lot of time.
I am always open to ideas and suggestions and consider each carefully!

It would be sort of hard to group them into a single file and run them on three machines. I found a version of srsieve2 which runs on my older Windows 7 systems. There are two. There is a laptop, but it runs hot under a load and I would rather not use it.

I don't see that I'm wasting time. The switch from one k to the next is just a minute or two. I am using a batch file with all the parameters coded in except the k value. All I have to do is start it with the k on the command line and off it goes.

I looked up the "Nash" values for the entire list. I run the smaller ones during my waking hours. Late evening, I will run a larger one which will take into the next morning to finish. 11 of the k's have a Nash < 1000 making them "low" according to kar_bon and his Wiki database. I dabbled in his Riesel project for a while.

My two batch files are below in case anyone is curious:

Code:
For the Windows 7 systems:

@echo off
cls
srsieve2 -n 100e3 -N 250e3 -P 25e11 -s "%1*2^n-1"
echo.
rename b2_n.abcd %1.abcd
echo.

For the Windows 10 system:

@echo off
cls
srsieve2cl -n 100e3 -N 250e3 -P 25e11 -g 16 -M 9000 -s "%1*2^n-1"
echo.
rename b2_n.abcd %1.abcd
echo.
VBCurtis got after me a while back because of my diffficulty in transposing scientific notation. 1e12 > 10e11 > 100e10, and so on. There is no difficulty now!

 2022-12-08, 17:30 #18 rogue     "Mark" Apr 2003 Between here and the 695810 Posts You just need to put all sequences into a single file and specify the filename with -s or you can use -s multiple times on the same command line. If you have 100 sequences and do one k at a time and it takes 100 hours, doing all 100 in a single run will take far less time than 100 hours. Trust us, this will make your life easier. The maximize your output you can either run a different conjecture on each machine or you can sieve to 1e9 on one machine the take that output file and sieve different ranges of p on different machines and save factors using -O. When done, use -I to apply the factors to your original output file.
 2022-12-08, 23:39 #19 gd_barnes     "Gary" May 2007 Overland Park, KS 13·907 Posts Please answer this question before you go any further: Are you running base 2 or base 60? In other words are you running k*2^n-1 or k*60^n-1 ? The batch file that you posted looks like it is for base 2. You should be running base 60. You are wasting a ton of CPU time! It is far more efficient to run all k's in one file. Forget personal time for a minute. Just consider the huge amount of CPU time that you are wasting. To split them across multiple machines, you just sieve different P-ranges, not different k's or k-ranges. What if there were 1000 or 10000 k's to sieve? Do you really want to set up 1000 or 10000 batch processes? Please just try it. One time. You will never go back. In the time that it will take you to sieve all k's individually to 25e11 (2.5e12) others likely could have used lesser resources to sieve everything to 10e12. Does Karsten's Wiki database have Nash values for base 60? That is the base that you should be working on. I know of one for base 2 not for base 60. It would have been a tremendous effort for him to have put together a database of 100s of different k-values and 100s of different bases. If you have found a Wiki database for Nash values for base 60, can you post a link to it? I'd like to see it. Regardless you should be looking at factor removal rate for the entire set of k-values not Nash value for each individual k to determining optimum sieving depth. That removal rate should be compared to an LLR test. Last fiddled with by gd_barnes on 2022-12-08 at 23:51
2022-12-08, 23:48   #20
gd_barnes

"Gary"
May 2007
Overland Park, KS

13·907 Posts

Quote:
 Originally Posted by storm5510 VBCurtis got after me a while back because of my difficulty in transposing scientific notation. 1e12 > 10e11 > 100e10, and so on. There is no difficulty now!
You are aware that 1e12 = 10e11 = 100e10, correct?

I'm not sure why you posted that 1e12 is greater than 10e11 which is greater than 100e10. They are all the same.

Perhaps you were posting an example of what you were previously confused about and I am simply misunderstanding what you mean.

Last fiddled with by gd_barnes on 2022-12-08 at 23:49

2022-12-09, 01:16   #21
storm5510
Random Account

Aug 2009
Not U. + S.A.

23·32·5·7 Posts

Quote:
 Originally Posted by gd_barnes Please answer this question before you go any further: Are you running base 2 or base 60? In other words are you running k*2^n-1 or k*60^n-1 ? The batch file that you posted looks like it is for base 2. You should be running base 60. You are wasting a ton of CPU time! It is far more efficient to run all k's in one file. Forget personal time for a minute. Just consider the huge amount of CPU time that you are wasting. To split them across multiple machines, you just sieve different P-ranges, not different k's or k-ranges. What if there were 1000 or 10000 k's to sieve? Do you really want to set up 1000 or 10000 batch processes? Please just try it. One time. You will never go back. In the time that it will take you to sieve all k's individually to 25e11 (2.5e12) others likely could have used lesser resources to sieve everything to 10e12. Does Karsten's Wiki database have Nash values for base 60? That is the base that you should be working on. I know of one for base 2 not for base 60. It would have been a tremendous effort for him to have put together a database of 100s of different k-values and 100s of different bases. If you have found a Wiki database for Nash values for base 60, can you post a link to it? I'd like to see it. Regardless you should be looking at factor removal rate for the entire set of k-values not Nash value for each individual k to determining optimum sieving depth. That removal rate should be compared to an LLR test.
Well, it looks like I really stepped in it. Everything I have done is junk! I had questioned this several days ago after seeing "base 60." At that moment, I didn't understand the meaning.

What you're suggesting is something like: -p3 to -P300e9 on machine 1, then -p300e9 to -P750e9 on machine 2, then -p750e9 to -P1e12 on machine 3. This is just an example. I would akin this to an assembly-line process. Since I have to start over, from scratch, I will give it a try.

Lesser resources? All my machines are four-core. Only two have eight threads. One, I use the GPU since the latest mtsieve was written on a Win10 system. None will run on an older OS. I don't now, or in the near future, be able to obtain anything newer.

It was my mistake to use ">" in an example. You took it literally while I was indicating a progression from one to the next.

I have no information about Base 60 Nash values. What I was using, I downloaded from a different post here. It is for base 2 only. There is a newer one which I cannot make produce anything.

So, I begin, again. Live and learn...

2022-12-09, 01:40   #22
gd_barnes

"Gary"
May 2007
Overland Park, KS

13·907 Posts

Quote:
 Originally Posted by storm5510 Windows: cllr -q"1770*2^200000-1" did not produce any screen output. I do not know what it was doing.
I'm glad the base confusion got cleared up. I should have picked up on that problem earlier when I saw the above quote, which was posted the day before you posted your batch file. There it's clear you were running base 2.

To get the time per iteration, I always run the GUI version of LLR. It will display the time per iteration right on the screen. Although I use cllr for actual testing, the GUI version is much clearer for seeing the time per iteration.

What you'll do is run LLR for just a short time to get the time per iteration. Let it run until that time stabilizes. It can take just a little while to stabilize after the program first starts. Then you'll multiply that time by the total number of iterations (also shown on screen) to get the approximate total test time. There's no use to run an entire test.

Off the top of my head, I couldn't say where to find the GUI version of LLR but I'm sure others could lead you to where it could be found. The version that I have is older at this point. But like Mark said, I think the iteration time and total number of iterations is shown in a file somewhere for cllr. I just don't remember where since I don't use it for that.

Last fiddled with by gd_barnes on 2022-12-09 at 01:44

 Similar Threads Thread Thread Starter Forum Replies Last Post rebirther Conjectures 'R Us 826 2023-01-25 15:49 The Carnivore Twin Prime Search 13 2019-07-06 03:11 gd_barnes Conjectures 'R Us 143 2014-10-21 23:55 nstaab1 Lounge 15 2013-03-06 13:48 CRGreathouse Puzzles 24 2011-10-28 18:30

All times are UTC. The time now is 11:38.

Fri Jan 27 11:38:13 UTC 2023 up 162 days, 9:06, 0 users, load averages: 1.60, 1.23, 1.16