[quote=mdettweiler;185624]All four k's remaining on Sierp. base 22 have now been loaded into G3000 for n=150K-200K. I've also upped the time limit for that server to 3 days (it was at 6 hours for debug purposes) in accordance with the much longer tests.

Gary, you can marked all k's on this base as reserved by "PRPnet" on the web pages.[/quote]


OK, will do. Just to make it official: we have now loaded the final 4 k's of Sierp base 22 into port G3000 here starting at n=150K. This will be considered "production" work.

Although we aren't confident that the server can handle many cores, since these are fairly long tests, we believe it should work OK with up to 10-15 cores so we'd ask that anyone running the server please limit their machines to 4 cores to begin with. With the exception of the occassional blank residue, all residues have been accurate. From time to time, we will check for blank ones.


Gary

Just in case I get lucky, is there a proof code for PRPNet for use over at the good professor's site?

[quote=MyDogBuster;185904]Just in case I get lucky, is there a proof code for PRPNet for use over at the good professor's site?[/quote]
As with LLRnet, you'll need to use the prover code for the respective application used by PRPnet for the proof. PRPnet records this info on both the server and client ends (on the server, see the file PRP.log). Though, if you're testing non-power-of-2 numbers and all of your clients have PFGW installed for use with PRPnet, then it's safe to assume that's what they used for the proof. Likewise, if it's a base 2 number, the proof program will be LLR.

To clarify for anyone connecting to port G3000 here, for Sierp base 22, you'd use the following in your proof code at the top-5000 site if you found a prime:

PFGW, srsieve, CRUS

Max, I inadvertently left my quad as 50% on port 3000 so we shot up past n=160K real quickly here on Sierp base 22 but I didn't make near the progress on k=147 that I had expected to in the last couple of days. I've now corrected that with k=147 at n=975K and moving ahead quickly again to n=1M. I'm ready for that to be out of my hair so that I can start on k=289 doublecheck from n=800K.


Gary

[QUOTE=mdettweiler;185907]As with LLRnet, you'll need to use the prover code for the respective application used by PRPnet for the proof. PRPnet records this info on both the server and client ends (on the server, see the file PRP.log). Though, if you're testing non-power-of-2 numbers and all of your clients have PFGW installed for use with PRPnet, then it's safe to assume that's what they used for the proof. Likewise, if it's a base 2 number, the proof program will be LLR.[/QUOTE]

Agreed. AFAIAC, neither PRPNet nor LLRNet should be mentioned in the prover codes. If you have a project which happens to use PRPNet or LLRNet, then you can set up a prover code for those projects. That prover code could then reference PRPNet or LLRNet.

I've tried to argue with people before (re Shane) that these other tools don't do any sieving or primality testing. They are not needed to find primes.

[quote=gd_barnes;185921]Max, I inadvertently left my quad as 50% on port 3000 so we shot up past n=160K real quickly here on Sierp base 22 but I didn't make near the progress on k=147 that I had expected to in the last couple of days. I've now corrected that with k=147 at n=975K and moving ahead quickly again to n=1M. I'm ready for that to be out of my hair so that I can start on k=289 doublecheck from n=800K.[/quote]
Actually, I think most of that was from Lennart. :smile: But, yes, I did notice from the logs that it looked like your quad had been essentially going 100% on G3000 for a while--which makes sense, since that server had been offline for quite a while, leading the client to do more work on k=147 than the 50% would specify. Thus, now with G3000 back online, it's trying to make up for lost time. :smile: As I mentioned before, these rolling averages can be reset by simply restarting the client.

[quote=mdettweiler;185950]Actually, I think most of that was from Lennart. :smile: But, yes, I did notice from the logs that it looked like your quad had been essentially going 100% on G3000 for a while--which makes sense, since that server had been offline for quite a while, leading the client to do more work on k=147 than the 50% would specify. Thus, now with G3000 back online, it's trying to make up for lost time. :smile: As I mentioned before, these rolling averages can be reset by simply restarting the client.[/quote]

Yeah, I had already figured that out but I really wanted it 100% on k=147 so I changed the .ini file to do that exclusively, stopped, and restarted them.

G3000 port # change
 

In preparation for the upcoming transferral of various NPLB servers (currently hosted by IronBits) to a new server run by Gary, I've changed the Conjectures 'R Us G3000 PRPnet server to port 1300 instead, making it now G1300. This is because when we move all of IronBits' servers over to Gary's server, we'll only have one set of available port #'s to work with, whereas currently we have two. Thus, there are a couple numbering conflicts that will need to be worked out. G3000 doesn't have any particular conflicts, but after merging the two sets of servers, we won't have very many free ports on the even 1000's. As such, I've decided that we'll have NPLB servers on x000 port numbers, and CRUS servers in the range of 1x00. Essentially, then, we'll have room for up to 10 servers for each project before having to use other ranges.

To reiterate: [B]PRPnet G3000 is now G1300. Change your clients accordingly.[/B] Additionally, all future CRUS servers will be on port numbers in the range 1x00 (1100, 1200, etc.)

I figured this was a pretty good time to make the switch, since right now there are no clients actively working on G3000. I apologize for any inconvenience this may cause.

Max :smile:

Nice work on thinking ahead Max. Good idea.

Email prime notification now available!
 

Hi all,

I am pleased to announce that we now have automatic email notification of primes on the G1300 PRPnet server. Actually, as I recently discovered, it turns out that I would have been able to set this up a while back, but thought all the while that there was an extra technical hurdle that turned out to be a moot point...anyway, that's a somewhat long story that I won't go into here. :smile:

This also affects any private servers I'm running at nplb-gb1.no-ip.org. So far this is just two total, one for Gary and one for me (though if anyone else wants one, don't hesitate to ask). :smile:

Max :smile:

Sierp base 22 will complete to n=200K in < 2 days. In the mean time, the n=200K-300K range for the combination of Riesel/Sierp base 22 has an optimum sieve depth near P=~7T for breaking off n=200K-300K from the combined n=200K-1M file.

With a current sieve depth of P=6T, I am sieving it another trillion and it should be complete in just a little over 2 days. Therefore, there will be a pause in this effort of about a day. At that point, we'll load n=200K-250K for the Sierp side into the PRPnet server and I will update the sieve file on the web page for the Riesel side.

An n>200K prime for this high base would be > 260K digits. Come check it out after I'm done sieving if you have some spare cores. On the Riesel side (not in this drive), there is only one k remaining. You could be the one to prove the conjecture! :smile:


Gary