![]() |
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. :smile: 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. |
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 [I]are[/I] 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? |
[QUOTE=gd_barnes;399396]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 [I]are[/I] 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?[/QUOTE] I'm leaving this for someone else. Going to PG or SOB :smile: |
[QUOTE=gd_barnes;399396] Why are you not testing k=443 and k=2297 on the Riesel side? [/QUOTE]
I'll take them in addition to my R256 search. |
[QUOTE=unconnected;399431]I'll take them in addition to my R256 search.[/QUOTE]
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. |
[QUOTE=gd_barnes;399435]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?
[/QUOTE] Yes. I'm planning to test to n=1M (base 16). [QUOTE] 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.[/QUOTE] 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. |
[QUOTE=unconnected;399441]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.[/QUOTE]
Very good. I should have previously recognized that for k=443 and already had you as reserved for R16. |
Reserving R27 to n=2M (1-2M) for BOINC
|
Reserving S22 to n=1M (500k-1M) for BOINC
|
Reserving S17 to n=2M for PRPnet port 1300.
|
status report
S10 tested till n=1.5M
R10 tested till n=1.27M |
| All times are UTC. The time now is 22:40. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.