[QUOTE=gd_barnes;266453]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.[/QUOTE]

Sounds good to me. It shouldn't take too long to get those bases to n=200000.

As Lennart mentions, the server can hand tests out by decimal length (option l), which is good if you mix bases that are powers of one another, i.e. 2, 4, 16, etc. The server can also hand out tests by n, which (IMO) works would be a more typical usage of the server when handling multiple bases.

onekperclient is only helpful if there are many more k's than clients. Under other circumstances, clients wouldn't get work. If someone were to start a public server for a conjecture with a large number of remaining k (R19 is a good example), then that option could probably be used.

[QUOTE=rogue;266491]Sounds good to me. It shouldn't take too long to get those bases to n=200000.

As Lennart mentions, the server can hand tests out by decimal length (option l), which is good if you mix bases that are powers of one another, i.e. 2, 4, 16, etc. The server can also hand out tests by n, which (IMO) works would be a more typical usage of the server when handling multiple bases.

onekperclient is only helpful if there are many more k's than clients. Under other circumstances, clients wouldn't get work. If someone were to start a public server for a conjecture with a large number of remaining k (R19 is a good example), then that option could probably be used.[/QUOTE]


To make the initial effort not "too small", we can sieve n=100K-500K and test n=100K-250K leaving the n=250K-500K portion of the sieve files for future use. That should still take quite a while because all of the bases are > 32 and there should be quite a few top-5000 primes in there. After that, we can look at testing some bases < 32 with 3-5 k's remaining for n=250K-500K and perhaps others with only 1-2 k's remaining for n=~400K/500K-1M.

I'll be out of town until Weds. and am very busy on weekends so will not be able to respond much more or start anything. Next Thurs. and Fri., we can finallize the bases and perhaps begin a sieving drive shortly after that.


Gary

FYI: I'm back from my trip as of about an hour ago. :smile:
[QUOTE=gd_barnes;266408]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.[/QUOTE]
Yes, this is correct. tpsieve/ppsieve is of little use for conjecture searches unless some of their k's can be converted to base 2 k's within the range of another large sieve such as PrimeGrid's (which goes up to k=10,000, n=6M; I'm not sure any of our power-of-2 k's fit within this).

As for what to load into the servers (port 1300 and one or more new servers), I don't have too much of a preference myself. I do like the idea of having two separate servers, one for base 2 as we're currently doing on port 1300, and one for assorted other bases with a small handful of k's remaining. As a suggestion, we may want to instead do the base 2 stuff in the new server, and use port 1300 for the assorted stuff; we could put the new server on port 1200 and thus capitalize on the mnemonic connection of base 2/port 1200 (like what I was thinking with port 1100 for the future 1-k drive). Since we are not likely to have any base 3 PRPnet efforts in the foreseeable future, 1300 would be a good choice for assorted bases. :smile:

I could also set up a base 16 server on port 1600, as has been suggested; that said, I agree with Gary that it may be better to stick to manual reservations on that one. With port 1300, an additional server coming soon, and port 1100 for the future 1-k drive, we'll have three PRPnet servers running, which will in and of itself be spreading the project's PRPnet resources pretty thin. I'm not sure we'd be able to attract enough interest to maintain any more servers than that. I've noticed that there seems to be two pools of resources in the project, one for manual work and one for PRPnet; there is some overlap between them but it is not total. We thus need to be a little careful with moving already-successful manual efforts from manual to PRPnet, so as to not move them out of reach of the manual pool and instead into the PRPnet pool which will have quite plenty of work between the aforementioned three servers.

Max :smile:

I will continue sieves (S183,185,187,189) to 2T, and start R61 n=100K-500K.

[QUOTE=mdettweiler;266533]As for what to load into the servers (port 1300 and one or more new servers), I don't have too much of a preference myself. I do like the idea of having two separate servers, one for base 2 as we're currently doing on port 1300, and one for assorted other bases with a small handful of k's remaining. As a suggestion, we may want to instead do the base 2 stuff in the new server, and use port 1300 for the assorted stuff; we could put the new server on port 1200 and thus capitalize on the mnemonic connection of base 2/port 1200 (like what I was thinking with port 1100 for the future 1-k drive). Since we are not likely to have any base 3 PRPnet efforts in the foreseeable future, 1300 would be a good choice for assorted bases. :smile:[/QUOTE]

I think that having 3 servers would be overkill. If we were to do a 1k only PRPnet server, it would need to be after we finish this initial effort that we are talking about for a 2nd server. But at this point, we're talking about taking a bunch of bases < 100 (or maybe < 200) with <= 5 k's remaining to n=200K or n=250K and following that up with taking perhaps bases <= 32 to n=500K to 1M somewhere.

IMHO port 1300 should be left as is with base 2 stuff to keep all score and primes together for the base on the display page. The mnemonics mean little to nothing on the servers. You can choose whatever port you want for our new server.

I'm now thinking that we may want to expand the effort for the new server to include bases < 200 searched as high as n=200K already and search everything to n=250K. That would add quite a few 1k bases, which I think would be interesting to people. Many would only end up being searched from n=200K to 250K but at least that would make things consistent. Taking bases with several k's remaining to n=250K while leaving 1kers at n=100K, 150K, or 200K would be inconsistent with and a disserve to our efforts to prove bases so increasing the search depth of those 1kers would be a good thing, even if it's only from n=150K or 200K to n=250K.

Mathew, can you prepare a new list of all bases with the following conditions:
base <= 200
<= 5 k's remaining
n<250K search depth
(Note that I doubt there are any that are 200K<n<250K but if there are, we'd want to give them a small nudge up to n=250K for consistency. I know there are many that are exactly at n=200K.)

The only disadvantage of this is that it may tie up some 1k bases for quite a while that are already searched to n=150K or 200K. If we get a ways into it and it seems as though we are "hoarding" bases without searching them for an extended timeframe, we can pull some out.)

The above should be quite a few bases. We'll then use that list to pare down to a more reasonable number of bases. The idea will be to search them all to n=250K and then come back around with a 2nd effort to perhaps search bases <= 50 with <=5 k's remaining to n=500K or higher.

Thanks!


Gary

[QUOTE=gd_barnes;266567]I think that having 3 servers would be overkill. If we were to do a 1k only PRPnet server, it would need to be after we finish this initial effort that we are talking about for a 2nd server. But at this point, we're talking about taking a bunch of bases < 100 (or maybe < 200) with <= 5 k's remaining to n=200K or n=250K and following that up with taking perhaps bases <= 32 to n=500K to 1M somewhere.

IMHO port 1300 should be left as is with base 2 stuff to keep all score and primes together for the base on the display page. The mnemonics mean little to nothing on the servers. You can choose whatever port you want for our new server.[/QUOTE]
Okay, sounds good. Note that what I was thinking regarding switching to a new port # for base 2 stuff was that it would actually stay in the same server, but I'd just reconfigure it to run on a different port. That is, I would transplant port 1300 onto port 1200 and create a new, blank port 1300 in its place. But, I see your point...the mnemonic coincidences are really quite unimportant in the grand scheme of things. It's not like it's [I]that[/I] hard to keep track of the contents of two (or at max three) servers. :rolleyes:

[CODE]Riesel Sierpinski
------ ----------
61 (100K) 4k 37 (200K) 3k
67 (100K) 5k 43 (200K) 1k
70 (100K) 3k 55 (200K) 4k
80 (200K) 3k 68 (200K) 2k
93 (200K) 1k 73 (200K) 2k
94 (200K) 1k 75 (100K) 2k
100 (200K) 1k 86 (200K) 1k
103 (100K) 3k 100 (100K) 5k
109 (200K) 1k 102 (100K) 3k
112 (150K) 3k 107 (100K) 4k
133 (100K) 2k 112 (150K) 2k
152 (200K) 1k 122 (200K) 1k
158 (100K) 3k 133 (100K) 3k
160 (200K) 1k 135 (50K) 5k
162 (50K) 5k 140 (100K) 2k
163 (100K) 1k 155 (200K) 1k
172 (50K) 5k 157 (100K) 3k
177 (100K) 1k 173 (200K) 1k
181 (100K) 1k 174 (200K) 1k
182 (100K) 1k 183 (150K) 1k
191 (100K) 2k 185 (100K) 1k
200 (100K) 2k 187 (100K) 1k
189 (100K) 1k
191 (50K) 4k[/CODE]Note: I ignored ones that are reserved

Wow, well, that's a lot of bases. Do I hear any opinions on which of these bases we should (or should not) take up to n=250K in a new PRPnet server? The only thing is that it wouldn't seem as bad as it looks because many of the bases are already at n=200K.

[QUOTE=gd_barnes;266613]Wow, well, that's a lot of bases. Do I hear any opinions on which of these bases we should (or should not) take up to n=250K in a new PRPnet server? The only thing is that it wouldn't seem as bad as it looks because many of the bases are already at n=200K.[/QUOTE]

I suggest excluding those at 200K for the moment. That should cut the list almost in half. Once all are at 200K, you can decide what is next.

[QUOTE=rogue;266619]I suggest excluding those at 200K for the moment. That should cut the list almost in half. Once all are at 200K, you can decide what is next.[/QUOTE]

OK, that's reasonable. The only problem is that it's still 29 bases...quite a few. Contrarily, the problem if we cut it off at base 150 is that it would only be 14 bases. There's a lot of bases 150-200.

Hum...how about we cut it off at base 180. That would leave 20 bases...about perfect as far as I'm concerned.

So what does everyone think of including the 20 bases with the following parameters in the new PRPnet server?:

base <= 180
search depth n<200K
k's remaining <= 5

We would sieve them all to n=500K and test them to n=200K. This would be phase 1 of the new server. We could then decide whether to take the phase 1 bases higher (to maybe n=250K) or start on (perhaps) bases <= 50 and test them from (maybe) n=~200K to ~500K or higher, which might be called phase 2. With a couple of heavy hitters on phase 1 like Ian or Lennart fairly consistently, it would not be a real long drive. We would then move on to the real time-consuming stuff in phase 2. In effect, phase 1 would be a good "set up" for phase 2 where many big top-5000 primes are found.


Gary