Bases 33-100 reservations/statuses/primes

[Rincewind]

OK that sounds good.

And with this information SoB looks like the smaller project ;)

[Xentar]

Originally Posted by Rincewind

And with this information SoB looks like the smaller project ;)

That may be correct, but I think, the feeling of success is bigger here, because we (try to) eliminate so many different bases, with much more primes.

[Rincewind]

Originally Posted by Xentar

That may be correct, but I think, the feeling of success is bigger here, because we (try to) eliminate so many different bases, with much more primes.

That's so true.

I'll reserve the rest of the Riesel-Base 36 pairs.
Reserved Pairs:

1148*36^n-1
4737*36^n-1
7362*36^n-1
7399*36^n-1
8472*36^n-1
11014*36^n-1
12320*36^n-1
15687*36^n-1
15909*36^n-1
16168*36^n-1
18203*36^n-1
19035*36^n-1
20092*36^n-1
22164*36^n-1
25204*36^n-1
25788*36^n-1
26355*36^n-1
32302*36^n-1
33877*36^n-1
36113*36^n-1
37480*36^n-1
39898*36^n-1
40327*36^n-1
40995*36^n-1
41727*36^n-1
42623*36^n-1
43809*36^n-1
45148*36^n-1
46102*36^n-1
47435*36^n-1
47927*36^n-1
50183*36^n-1
50948*36^n-1
51172*36^n-1
51392*36^n-1
51434*36^n-1
53538*36^n-1
53945*36^n-1
54278*36^n-1
54759*36^n-1
55020*36^n-1
57682*36^n-1
57785*36^n-1
58387*36^n-1
60237*36^n-1
62087*36^n-1
68535*36^n-1
70338*36^n-1
72762*36^n-1
73187*36^n-1
80883*36^n-1
81177*36^n-1
81695*36^n-1
84759*36^n-1
85189*36^n-1
86618*36^n-1
88399*36^n-1
90575*36^n-1
92908*36^n-1
92943*36^n-1
93432*36^n-1
94055*36^n-1
95350*36^n-1
95977*36^n-1
98530*36^n-1
99790*36^n-1
102088*36^n-1
106302*36^n-1
106448*36^n-1
107782*36^n-1
108525*36^n-1
109772*36^n-1
110423*36^n-1
112934*36^n-1
113403*36^n-1

(Includes my reserved pairs, and excludes the pairs reserved by others and the one with n=500k
I generated a Sieve file for 25k < n < 500k and started sieving.
My plan is to sieve until finding a factor takes longer than a LLR-Test. After needing longer for an LLR-Test than finding a factor I'll restart sieving and so on.
The worst case could be that I can only provide sieve files for this candidates up to n=500k-
Progress will be posted.

[gd_barnes]

Rincewind,

How many cores do you plan to put on the base 36 effort?


Gary

[rogue]

Originally Posted by Rincewind

That's so true.

I'll reserve the rest of the Riesel-Base 36 pairs.

(Includes my reserved pairs, and excludes the pairs reserved by others and the one with n=500k
I generated a Sieve file for 25k < n < 500k and started sieving.
My plan is to sieve until finding a factor takes longer than a LLR-Test. After needing longer for an LLR-Test than finding a factor I'll restart sieving and so on.
The worst case could be that I can only provide sieve files for this candidates up to n=500k-
Progress will be posted.

I have a recommendation which is to help ensure that you don't oversieve. Typically you want to sieve until the removal rate is about the same as the average time for a PRP test for a number in the range. This will be around n=350K, which is about two-thirds through the range.

Even at that removal rate, you are probably over-sieving. You need to consider that some k will be removed along the way, so within that range you will not be testing a number of candidates (that have longer PRP tests).

This is what I recommend:

1) Sieve for n from 25K to 500K until the removal rate is approximately the same as the time for a PRP test at n=100K.
2) Take the sieve output file and run with PFGW or better yet a local PRPNet server, especially if you are going to use multiple cores.
3) Once n gets close to 100K, remove all tests that have been performed from the sr_36.pfgw file.
4) Use the srfile tool to remove k from sr_36.pfgw
5) Use srsieve (or sr2sieve) to continue sieving until the removal rate is close to the time for a test where n=200K.
6) If using PRPNet, use the prpadmin tool to remove candidates based upon the factor file generated by srsieve/sr2sieve.
7) If using PFGW, continue testing with the updated sr_36.pfgw file.
8) Repeat steps 3 through 7 as n reaches 200K, 300K, and 400K.

I would be that the original sieving (step 1) might be sufficient for the task. Granted you can change those thresholds to multiples of 25K or 50K if you choose. 100K is just my example.

My recommendation for conjectures with fewer k would be to sieve more deeply as k will be removed at a much slower rate. The worst are the single k conjectures because you just don't know when that last elusive prime will be found.

[mdettweiler]

Originally Posted by rogue

I have a recommendation which is to help ensure that you don't oversieve. Typically you want to sieve until the removal rate is about the same as the average time for a PRP test for a number in the range. This will be around n=350K, which is about two-thirds through the range.

Even at that removal rate, you are probably over-sieving. You need to consider that some k will be removed along the way, so within that range you will not be testing a number of candidates (that have longer PRP tests).

This is what I recommend:

1) Sieve for n from 25K to 500K until the removal rate is approximately the same as the time for a PRP test at n=100K.
2) Take the sieve output file and run with PFGW or better yet a local PRPNet server, especially if you are going to use multiple cores.
3) Once n gets close to 100K, remove all tests that have been performed from the sr_36.pfgw file.
4) Use the srfile tool to remove k from sr_36.pfgw
5) Use srsieve (or sr2sieve) to continue sieving until the removal rate is close to the time for a test where n=200K.
6) If using PRPNet, use the prpadmin tool to remove candidates based upon the factor file generated by srsieve/sr2sieve.
7) If using PFGW, continue testing with the updated sr_36.pfgw file.
8) Repeat steps 3 through 7 as n reaches 200K, 300K, and 400K.

I would be that the original sieving (step 1) might be sufficient for the task. Granted you can change those thresholds to multiples of 25K or 50K if you choose. 100K is just my example.

My recommendation for conjectures with fewer k would be to sieve more deeply as k will be removed at a much slower rate. The worst are the single k conjectures because you just don't know when that last elusive prime will be found.

One small addition that I'd like to note: if you're using a PRPnet server to run your reservation, we'd actually prefer that rather than using prpadmin to remove candidates throughout, you load in the subranges individually as they are sieved optimally. For example, if p=5T is optimal for n=25K-100K, then sieve to 5T and load in that portion; and if (say) 10T is optimal for 100K-200K, sieve to that and load in 100K-200K from the 10T file. This ensure that specific subranges can be matched up with specific sieve files, which is a very big help when we have to sort and verify the results afterwards. (This can be quite difficult to do when the sieve depth varies wildly throughout.)

My apologies for any additional hassle this may cause. Believe me, they're far smaller than the hassles involved in attempting to verify results over a jumble of sieve depths.

[Rincewind]

@gd_barnes: I'm using one core for the sieving at the moment. Later I'll use 2 or 3 more for LLR.

After reading this tips I'll shrink my sievefile to 25k - 100k.

[gd_barnes]

Originally Posted by Rincewind

@gd_barnes: I'm using one core for the sieving at the moment. Later I'll use 2 or 3 more for LLR.

After reading this tips I'll shrink my sievefile to 25k - 100k.

I asked because n=25K-500K is probably a 25+ (possibly 50+) CPU year effort! Frequently new people here will reserve much more than can handle for their resources. When you upped the reservation, I assumed that you had anywhere from 3-5 quad core machines or more to run it.

If you would like to reserve n=25K-100K, that is fine but even that may take as long as 3-5 CPU years! (A rough educated guess.) After all, it is ~90 k's. I would recommend at least 4 cores on it, which might be able to complete it < 1 year.

That said, if you would like to sieve n=25K-100K and then only test n=25K-50K and provide us with the remainder of the sieve file, that would be good. Even that will still take a few months on 2-3 cores but is a fairly typical sized time for a reservation here.

Regardless, good luck with the effort! :-)


Gary

[Rincewind]

OK, you have a lot more experience compared to me. So I'll sieve 25k - 100k and reserve 25k -50k for tests.

[gd_barnes]

Originally Posted by Rincewind

OK, you have a lot more experience compared to me. So I'll sieve 25k - 100k and reserve 25k -50k for tests.

OK, I'll mark you down for that.

No one is stopping you from testing 25K-100K and taking several years to do it. That's no problem. I just wanted you to be aware of it ahead of time how much time it would take before you got into it.

Here is one thing that you might do after sieving to get an idea how long the effort will take: Test a candidate at 60% of the n-range of what you plan to test. So for n=25K-50K, that would be n=40K, i.e. (50K-25K)*.6+25K. Take that test time and multiply it by the number of candidates in your sieve file. That should give a good total CPU time estimate. Then of course you can divide it by the # of cores you plan to use on testing and that will be how much calendar time it will take.

Normally I would say 70% (or 2/3rds) of the n-range but some k's will drop due to primes.


Gary

[Rincewind]

Reducing the range is OK.
After Browsing a bit more through this Forum I decided to use the strategy you mentioned.