New PRPnet drive discussion

[rogue]

Gary and Max, have you decided the direction you want to go with this?

[gd_barnes]

Both of us are out of town right now and will be back early to mid next week. Based on previous suggestions, I think it makes sense to have 2 servers, one for base 2 like we are doing here and one for bases (preferrably < 100) with few (perhaps <= 5) k's remaining.

For the 1st option, I think it makes sense to continue with out current k's to n=2M and then add the additional k's that are already at n=2M once we get there as Max initially suggested. For the 2nd option, we can take suggestions on what bases people would like to do. Both options will need sieving done before starting/continuing so 2 different sieving drives will need to be set up.

[rogue]

Originally Posted by gd_barnes

Both of us are out of town right now and will be back early to mid next week. Based on previous suggestions, I think it makes sense to have 2 servers, one for base 2 like we are doing here and one for bases (preferrably < 100) with few (perhaps <= 5) k's remaining.

For the 1st option, I think it makes sense to continue with out current k's to n=2M and then add the additional k's that are already at n=2M once we get there as Max initially suggested. For the 2nd option, we can take suggestions on what bases people would like to do. Both options will need sieving done before starting/continuing so 2 different sieving drives will need to be set up.

Is there any interest in putting base 16 into a server rather than continuing with the manual reservation/submission process?

Is there any benefit in sieving k's from other power of 2 bases with base 2 k's? That is presuming that some of the base 2 k's haven't been sieved past n=2M.

Would the intention be to use sr2sieve or tpsieve for base 2 sieving? You might draw some interest if GPUs could be used to help the sieving process.

[gd_barnes]

Originally Posted by rogue

Is there any interest in putting base 16 into a server rather than continuing with the manual reservation/submission process?

Is there any benefit in sieving k's from other power of 2 bases with base 2 k's? That is presuming that some of the base 2 k's haven't been sieved past n=2M.

Would the intention be to use sr2sieve or tpsieve for base 2 sieving? You might draw some interest if GPUs could be used to help the sieving process.

We've had decent response on the manual drives for bases 6 and 16 so I don't see a reason to change that right now. Also, sieving and putting different powers-of-2 bases in a server is too difficult due to their very different search depths and # of k's remaining. Base 16 is already optimally sieved for n=250K-500K, which is the equivalent of n=1M-2M base 2. R256 is hardly sieved at all and is at n=75K or n=600K base 2.

To the best of my knowledge, tpsieve is only good for contiguous k's. I believe it loses its benefit when there are wide gaps in the k's. So we would use sr2sieve.

[rogue]

Originally Posted by gd_barnes

We've had decent response on the manual drives for bases 6 and 16 so I don't see a reason to change that right now. Also, sieving and putting different powers-of-2 bases in a server is too difficult due to their very different search depths and # of k's remaining. Base 16 is already optimally sieved for n=250K-500K, which is the equivalent of n=1M-2M base 2. R256 is hardly sieved at all and is at n=75K or n=600K base 2.

To the best of my knowledge, tpsieve is only good for contiguous k's. I believe it loses its benefit when there are wide gaps in the k's. So we would use sr2sieve.

Presuming that PRPNet would be used, the server could order by decimal length, which works well when mixing numerous bases. In any case the important thing is to get the sieving sub-projects you've suggested started.

I wasn't aware of that limitation with tpsieve, but presuming you are correct then that would be a problem.

[gd_barnes]

We are now taking suggestions on which bases to include in a new 2nd PRPnet server. Preferred are bases < 100 with <= ~5 k's remaining. It's probably best to stick with bases at a search depth of n<200K to start with.

I have not done a detailed analysis on whether this scope would be too narrow or broad. We can decide that as suggestions come in. We could tweak either the bases, k's remaining, or search depth to include a little more or less as necessary.

[rogue]

Originally Posted by gd_barnes

We are now taking suggestions on which bases to include in a new 2nd PRPnet server. Preferred are bases < 100 with <= ~5 k's remaining. It's probably best to stick with bases at a search depth of n<200K to start with.

I was hoping that you would consider conjectures with a search depth >= 200K. My reasoning is that people tend to reserve lower n ranges then abort conjectures when n gets too large because individual tests take too long. Would it make more sense to set up the second server for any conjectures (excluding those being handled by another project/drive) where n >= 200K?

I'm fine if you disagree. I'm just asking the question.

Presuming you don't change your mind I have no opinions regarding the conjectures to put into a second server.

[Mathew]

Gary,

Here is a quick snap of what I understand your criteria is:

R n≤200K k≤5 b≤100
61 -4 k's
67 -5 k's
70 -3 k's

S n≤200K k≤5 b≤100
70 -5 k's
75 -2 k's
100 -5 k's

-----------------------------------------
Other things to look at:

b≤32²
R
10² - n=200K - 1k
28² - n=100K - 2k's
30² - n=100K - 1k

S
10² - n=100K - 5k's
26² - n=150K - 1k
28² - n=100K - 1k

There are 6 Riesel (159,163,173,177,181,182) & 5 Sierpinski (118,183,185,187,189) 1k's with b≤200 n≤200K all have sieve files to at least 1.5T MyDogBuster stated he usually sieves to only 500G.

B133 has 5k's n≤100 and a sieve file to 10T

[MyDogBuster]

Nice list Mathew, I say, throw it all that stuff in the new server. That will give us plenty of time to do more sieving. I'll sieve to whatever limit is agreed upon.

I would also include all bases up to b=200 that have 2, 3, 4 or k's left and n<=200K. That would match the upper boundary of the 1ker's you listed. I think a limit of b<=100 is a bit narrow.

I have about 2 weeks remaining on the ck<10K bases yet to be started.
I have them reserved and sieved, so it's just test time left. That will free up about 12 cores for this effort.

[gd_barnes]

Originally Posted by rogue

I was hoping that you would consider conjectures with a search depth >= 200K. My reasoning is that people tend to reserve lower n ranges then abort conjectures when n gets too large because individual tests take too long. Would it make more sense to set up the second server for any conjectures (excluding those being handled by another project/drive) where n >= 200K?

I'm fine if you disagree. I'm just asking the question.

Presuming you don't change your mind I have no opinions regarding the conjectures to put into a second server.

The reason that I suggested excluding conjectures where n>200K is that there are very few of those, most of which are bases < 32, and if we have the server hand out tests by size, they will be reserved for a very long time before we ever do any testing on them if we start the server from n=50K or 100K. For instance, I wouldn't want to tie up bases like R22, R23, R26, R27, R31, S22, S26, S30, etc. waiting for higher bases like what Mathew suggested to get to n=250K or 300K or higher. Such efforts are too disparate to include with higher bases only searched to n=50K or 100K.

Tell you what, let's see what we all decide with likely a subset of what Mathew suggested and run something like that up to about n=200K while still allowing people to manually reserve the smaller bases that are already searched to n>200K. Then we can potentially look at the smaller bases for a 2nd effort on this 2nd server, perhaps bringing those with <= 5 k's remaining up to n=500K-1M.

What this will do is give the heavy hitters some big tests in base 2 with our current server and the rest of us some intermediate sized tests in the new server with a reasonable chance at a few proofs.


Gary

[Lennart]

Originally Posted by gd_barnes

The reason that I suggested excluding conjectures where n>200K is that there are very few of those, most of which are bases < 32, and if we have the server hand out tests by size, they will be reserved for a very long time before we ever do any testing on them if we start the server from n=50K or 100K. For instance, I wouldn't want to tie up bases like R22, R23, R26, R27, R31, S22, S26, S30, etc. waiting for higher bases like what Mathew suggested to get to n=250K or 300K or higher. Such efforts are too disparate to include with higher bases only searched to n=50K or 100K.

Tell you what, let's see what we all decide with likely a subset of what Mathew suggested and run something like that up to about n=200K while still allowing people to manually reserve the smaller bases that are already searched to n>200K. Then we can potentially look at the smaller bases for a 2nd effort on this 2nd server, perhaps bringing those with <= 5 k's remaining up to n=500K-1M.

What this will do is give the heavy hitters some big tests in base 2 with our current server and the rest of us some intermediate sized tests in the new server with a reasonable chance at a few proofs.


Gary

// sortoption= tells the server how to hand out candidates for testing. This
// is a comma delimited list of sort criteria. These are the available choices
// for the list (which is case-insenstive):
// a - age, older candidates have higher priority
// l - length, short candidates have higher priority
// k - k, lower k have higher priority
// b - b, lower b have higher priority
// n - n, lower n have higher priority
// c - c, lower c have higher priority
//
// When comparing to the previous version:
// L is equivalent to l,a
// A is equivalent to a,l
// K is equivalent to b,k,n,c
// N is equivalent to b,n,k,c
sortoption=l,a

-------------

-------------

// onekperclient= only applies to Sierpinski/Riesel type servers
// By setting this to 1, it will ensure that each client will work on
// a k/b/c and that other candidates for the same k/b/c will not be given
// to another client. Setting this to 1 will also set the sortoption
// to k,n,b,c which cannot be overridden.
onekperclient=0

Lennart