Bases 6-32 reservations/statuses/primes

[KEP]

S16 and R16 reservation.

I'm reserving following (8) R16 k's not being worked by any project or indivual:

12587
13703
21555
24987
26378
28967
29885
33023

also I'm reserving following (15) S16 k's not being worked by any project or individual:

2908
6663
10183
17118
24582
30397
35818
40410
42745
44035
53653
57867
60070
64620
65077

This gives a total reservation of 23 SR16 k's not being worked on by any projects or single individual. My plan is to sieve a range from n=500K to n=2.5M to p=500T or whatever is optimal sievedepth for n=1M and then start testing on my haswell from n=500001 to n=1M.

Hope this can be accepted.

Regards

KEP

Ps. The k's currently at n=500K and for k<=10000 for the Riesel side, is sufficiently sieved by PG and test files is available and ready for testing and therefor, is not part of my reservation.

[gd_barnes]

This reservation leaves many holes.

About your PS: Why are you not testing k=443 and k=2297 on the Riesel side? CRUS has already searched them much further than NPLB/RPS and NPLB would not hit n=2M base 2 for a very long time. Also PrimeGrid does not test Riesel numbers.

What about Riesel k=13880 and 19772 that are not being searched by anyone?

Why are you not testing the Riesel k < 10K but you are testing Sierp k < 10K?

To verify: You will be testing >= 23 k's for n=2M to n=4M base 2 and you will be doing this on one machine, your Haswell. Is that correct?

Have you thought this completely through?

[KEP]

Originally Posted by gd_barnes

This reservation leaves many holes.

About your PS: Why are you not testing k=443 and k=2297 on the Riesel side? CRUS has already searched them much further than NPLB/RPS and NPLB would not hit n=2M base 2 for a very long time. Also PrimeGrid does not test Riesel numbers.

What about Riesel k=13880 and 19772 that are not being searched by anyone?

Why are you not testing the Riesel k < 10K but you are testing Sierp k < 10K?

To verify: You will be testing >= 23 k's for n=2M to n=4M base 2 and you will be doing this on one machine, your Haswell. Is that correct?

Have you thought this completely through?

I'm leaving this for someone else. Going to PG or SOB

[unconnected]

Originally Posted by gd_barnes

Why are you not testing k=443 and k=2297 on the Riesel side?

I'll take them in addition to my R256 search.

[gd_barnes]

Originally Posted by unconnected

I'll take them in addition to my R256 search.

Note that KEP has released his entire reservation on R16/S16. So to confirm: Are you reserving only k=443 and 2297 for R16? Did you have a test limit in mind?

Helpful note for k=2297 that you're likely aware of: Since you've already searched k=2297 for R256 to n=330K, you would only need to search the odd n's to n=660K for k=2297 / R16. For n>660K base 16 you would need to search all n's to cover both bases.

[unconnected]

Originally Posted by gd_barnes

Note that KEP has released his entire reservation on R16/S16. So to confirm: Are you reserving only k=443 and 2297 for R16? Did you have a test limit in mind?

Yes. I'm planning to test to n=1M (base 16).

Helpful note for k=2297 that you're likely aware of: Since you've already searched k=2297 for R256 to n=330K, you would only need to search the odd n's to n=660K for k=2297 / R16. For n>660K base 16 you would need to search all n's to cover both bases.

For k=2297/R16 there are ~1/3 more candidates than for 2297/R256. As for k=443/R16 it is exact the same as k=7088/R256, so there will be no additional work.

[gd_barnes]

Originally Posted by unconnected

For k=2297/R16 there are ~1/3 more candidates than for 2297/R256. As for k=443/R16 it is exact the same as k=7088/R256, so there will be no additional work.

Very good. I should have previously recognized that for k=443 and already had you as reserved for R16.

[rebirther]

Reserving R27 to n=2M (1-2M) for BOINC

[rebirther]

Reserving S22 to n=1M (500k-1M) for BOINC

[gd_barnes]

Reserving S17 to n=2M for PRPnet port 1300.

[Cruelty]

S10 tested till n=1.5M
R10 tested till n=1.27M