[QUOTE]So what does everyone think of including the 20 bases with the following parameters in the new PRPnet server?:
[/QUOTE]I don't see why we need phases. I liked Mathew's last list. I would not be in favor of cutting it down. I also believe sieving it past the stated limit of the drive, n=250K, would be a waste of time, especially if we find a prime.

If you ask me, just take Mathew's last list and feed it into the server up to n=250k. It's probably enough work to keep us busy for quite some time, but that is not a bad thing.

Gary, I think that this discussion on the future of port 1300 (and the new port) should be put into another thread.

[QUOTE=rogue;266694]Gary, I think that this discussion on the future of port 1300 (and the new port) should be put into another thread.[/QUOTE]

We have several opinions now ranging from make it a smaller effort to make it a large one so it will be a little while before we decide. I'll continue the discussion on Weds.

Any other thoughts from anyone?

It has been my intent to create a separate thread for this discussion. I'll do that on Weds.

Mathew's list. :tu::tu::tu:

Lennart :smile:

I'm sieving R191 and R200 100K-250K to 2T

(From Mathew's list)

I think we have 4 votes (Mathew, Ian, Peter, and Lennart) to take Mathew's list, i.e. all bases <= 200 with <= 5 k's remaining, to n=250K. I'd prefer a little smaller effort but that's OK with me. It's a large effort but certainly one that we can do.

The next question is how much to sieve for each base. I like Ian's suggestion better than the one that I had suggested, that is sieveing everything to n=500K. If we do as he suggested, we should keep in mind that only sieving n=200K-250K is very inefficient due to such a small n-max/n-min ratio. It's best to sieve at least a 2x ratio so here is what I would suggest:

Bases currently at n=50K or 100K; sieve n=50K-250K or 100K-250K
Bases currently at n=150K; sieve n=150K-300K
Bases currently at n=200K; sieve n=200K-500K

I suggest a large range for the n=200K bases because a large majority of those only have 1 or 2 k's remaining and we'll need a big range given their already high search depth to have a decent chance of proof down the line after this server has completed its effort. It would involve much deeper sieving for those and we would not need to load them in the server right away. In other words, we can sieve just the bases at n=50K or 100K to begin with, which won't take as long to sieve as the others due to the smaller sieve range.

Thoughts?


Gary

Makes sense to me. Now all we need is a limit for each range and I'm useless when it comes to those.

When you go to create the thread for this drive, you should include 2 tables up front. The normal primes found table and a sieving status table. I think we can handle everything in one thread.

[QUOTE=MyDogBuster;266746]Makes sense to me. Now all we need is a limit for each range and I'm useless when it comes to those.

When you go to create the thread for this drive, you should include 2 tables up front. The normal primes found table and a sieving status table. I think we can handle everything in one thread.[/QUOTE]

I would say: Sieve everything to P=5T to start with and then we'll determine the optimum depth for each base from there. For such a high n-range on such high bases, I can guarantee that the optimum will be P>5T for all of them. (I've usually had optimums in the P=2T-3T range just for n=50K-100K, although that is for 20-50 k's remaining.) Likely it will be P>10T for all of them but I'd prefer not to over sieve any of them. Sieving will be no small task on this! We'll likely need a fair amount of Lennart's massive resources for it, especially for the the bases that we'll be sieving for n=200K-500K.

I'll have to take stock of the sieve files that Mathew has sent me in the last 2-3 days. Anything before that is uploaded on the reservations pages. I'll probably get those uploaded later on Monday.

Someone correct me on this one. Optimal sieve depth is usually calculated using 1 core sieving to find the depth for 1 core testing. If we have say 20 cores testing, wouldn't the optimal sieve depth be 20 times smaller because you can run 20 times more tests in the same time you could run 1 test?

[QUOTE=MyDogBuster;266748]Someone correct me on this one. Optimal sieve depth is usually calculated using 1 core sieving to find the depth for 1 core testing. If we have say 20 cores testing, wouldn't the optimal sieve depth be 20 times smaller?[/QUOTE]
Only if you're sieving on one core and testing on 20 cores. If you're sieving and testing with approximately the same number of cores, it balances out the same as if you're using just 1 core for both.

Note that this assumes you're only minimizing wall-clock time; to minimize CPU time, you need to calculate optimal depth as if you're both sieving and testing on one core, regardless of how many are doing each. This makes for a more efficient use of resources in the long run, even if it does extend the wall-clock time a bit.