Riesel base 3 - mini-drive I

[KEP]

Originally Posted by gd_barnes

The web pages have been updated and files posted for all efforts at CRUS except for here and some of the Riesel bases > 32. I'll get to this drive within the next few hours.

I see that KEP has stopped his involvement in this effort. I'll slowly get the applicable threads moved back into the main project. For efforts outside of this drive on Riesel base 3, it will likely will take me a few days to review what has been done and integrate it back into my pages.


Gary

I feel like I should add, that though I'm stopping my involvement in the Riesel base 3 effort, I'm going to complete my reservations

KEP

[MyDogBuster]

Taking 70K - 72K

[MyDogBuster]

65K - 70K complete 8 proven primes

42417904*3^65244-1 is prime! (211.2358s+0.0019s)
24417992*3^66175-1 is prime! (235.0610s+0.0019s)
41417806*3^66386-1 is prime! (238.8586s+0.0019s)
17079448*3^67796-1 is prime! (309.5642s+0.0019s)
25860818*3^68010-1 is prime! (553.1417s+0.0019s)
6669932*3^68991-1 is prime! (286.8298s+0.0020s)
80222026*3^69259-1 is prime! (558.1668s+0.0020s)
67469658*3^69930-1 is prime! (299.3137s+0.0020s)

Results emailed

[MyDogBuster]

Taking 72K - 75K

[MyDogBuster]

70K - 72K Complete 7 proven primes

85814782*3^70091-1 is prime! (1122.5192s+0.0021s)
54543212*3^70142-1 is prime! (290.8622s+0.6756s)
75947348*3^70454-1 is prime! (298.2278s+0.0021s)
38772262*3^70476-1 is prime! (295.8234s+0.0021s)
71927116*3^71246-1 is prime! (310.0062s+0.0021s)
47735858*3^71585-1 is prime! (306.2180s+0.0021s)
79317748*3^71748-1 is prime! (1160.9236s+0.0021s)

Results emailed

[MyDogBuster]

72K - 75K complete

3 prover primes

94180334*3^72817-1 is prime! (582.8346s+0.0021s)
16754078*3^73938-1 is prime! (324.5091s+0.0022s)
74417656*3^74246-1 is prime! (3321.8293s+0.0022s)

results emailed

[gd_barnes]

Files are up to date with k's removed that have primes.

[mdettweiler]

Taking 75K-76K for the new PRPNet beta server. This will be denoted as reserved by "PRPNet (G3000)", similar to how we denote LLRnet reservations.

[gd_barnes]

Originally Posted by mdettweiler

Taking 75K-76K for the new PRPNet beta server. This will be denoted as reserved by "PRPNet (G3000)", similar to how we denote LLRnet reservations.

I read that other thread. It looks like Rogue did a huge amount of work on that. Thanks Rogue! It also looks like it took some effort to get the server set up on my machine. Thanks Max!

There is just one thing I want to check on. I know it's a beta-version but this is a "production" effort therefore I need to ask:

Are we 100% sure that the primality testing part is sound?
Are we 100% sure that no k/n pairs will be skipped?

Having been a mainframe programmer for years, IMHO for beta testing, we don't generally do that with "production" files. In this case, it might have been better to take an already-completed n-range file and run a parallel test on it to compare residues.

As it is right now, the best we can do is run a double-check on it after PRPnet completes it and hold off testing any higher n-ranges until the double-check is complete. In the "real" world, the problem with running something in production and then double-checking it using other methods is that invalid data in the new process can affect existing processes while double-checking is going on. In this case, if we miss a prime or two or find a "prime" that later turns out to be composite, that would affect files as they are posted for higher n-ranges. Therefore it's best if we double-check it thru completion before handing out any higher n-ranges.

I'm sure we'll probably be OK but this is just food for thought for future beta testing.


Gary

[mdettweiler]

Originally Posted by gd_barnes

I read that other thread. It looks like Rogue did a huge amount of work on that. Thanks Rogue! It also looks like it took some effort to get the server set up on my machine. Thanks Max!

There is just one thing I want to check on. I know it's a beta-version but this is a "production" effort therefore I need to ask:

Are we 100% sure that the primality testing part is sound?
Are we 100% sure that no k/n pairs will be skipped?

Having been a mainframe programmer for years, IMHO for beta testing, we don't generally do that with "production" files. In this case, it might have been better to take an already-completed n-range file and run a parallel test on it to compare residues.

As it is right now, the best we can do is run a double-check on it after PRPnet completes it and hold off testing any higher n-ranges until the double-check is complete. In the "real" world, the problem with running something in production and then double-checking it using other methods is that invalid data in the new process can affect existing processes while double-checking is going on. In this case, if we miss a prime or two or find a "prime" that later turns out to be composite, that would affect files as they are posted for higher n-ranges. Therefore it's best if we double-check it thru completion before handing out any higher n-ranges.

I'm sure we'll probably be OK but this is just food for thought for future beta testing.


Gary

Well, PRPnet uses standard LLR and Phrot executables for its actual primality testing, so the tests should be sound, assuming of course that the machines running the tests are stable, as usual. And we'll know if the server setup is reporting primes correctly as soon as the server receives its first PRP.

Also, I will definitely be 100% sure at the end of the range that no k/n pairs have been skipped, since after processing the results into normal LLR format as I do with LLRnet results, I will be verifying them all with the original sieve file using the exact same proven-reliable method that I use for LLRnet results.

[gd_barnes]

Originally Posted by mdettweiler

Well, PRPnet uses standard LLR and Phrot executables for its actual primality testing, so the tests should be sound, assuming of course that the machines running the tests are stable, as usual. And we'll know if the server setup is reporting primes correctly as soon as the server receives its first PRP.

Also, I will definitely be 100% sure at the end of the range that no k/n pairs have been skipped, since after processing the results into normal LLR format as I do with LLRnet results, I will be verifying them all with the original sieve file using the exact same proven-reliable method that I use for LLRnet results.

OK, sounds good.

I'm very excited about this. We'll be able to load up Sierp base 6 now. Also, it sounds like in the future we'll be able to get faster testing on the NPLB servers.


Gary