I've moved the new beta-testing server over to Gary's machine, and it is now officially open for business at the following address and port:

server: nplb-gb1.no-ip.org
port: 3000

Currently the server is loaded with work from the Riesel base 3 mini-drive I, though this may change at some point, and in fact we may eventually load the server with multiple types of work, which is now possible due to the way PRPnet works (which, in fact, is somewhat fundamentally different from LLRnet, though clients may not see much of a difference).

I've uploaded a copy of my PRPnet client build for 32-bit Linux here. To get started, unzip it to a folder on your computer, open prpclient.ini and set the following values:

email=[your email address here]clientid=[enter an identifier for your client here--not sure if this has to be unique within a given email address]maxworkunits=10 [Note: there is currently a maximum of 10 set on the server end. I'll probably change this to something like 100 later today. If you enter a value in the client higher than the server's maximum, the server will give you its maximum number of k/n pairs to process.]

The server name is already set to the G3000 beta server. As we add more servers later on, feel free to add more servers as described in the prpclient.ini file.

Binaries for LLR 3.7.1c and Phrot 0.61 are included in the zip file, and prpclient.ini is pre-set to point to those binaries. Feel free to swap these binaries out as new versions of LLR and Phrot are released.

One thing to keep in mind: PRPnet automatically batches its k/n pairs in a manner somewhat similar to that of PrimeGrid's batching edition of the LLRnet client. Essentially, if you set maxworkunits to 10 in prpclient.ini, it will download 10 k/n pairs, process them, and send back all 10 at once. Then it will grab another 10 and repeat the process.

You probably won't want to set maxworkunits to 1, since the client goes idle for about 5 seconds each time it has to talk to the server to get more work. This is a somewhat negligible amount, especially considering how much time this client saves as compared to LLRnet , but it can rack up really quickly if you set maxworkunits too low. I recommend setting it to at least 10 for the size of numbers we're doing right now (~70 seconds apiece on a Core 2 Duo 2.2Ghz).

I don't have any status pages or other automatic handling scripts set up for this new PRPnet server yet; it's very different from LLRnet, and thus I'll probably have to start mostly from scratch with my scripts for it. I'll let everyone know when I've got something set up, though.

At this time I do not have a Windows build available for either the client or the server, though as rogue said he'll probably have one available tomorrow.

In addition to the base 3 candidates already in the server (which, by the way, we are progressing nicely on, thanks in part to Lennart who apparently decided to lend a few cores to our beta test server ), I've added 200 k/n pairs from our Sierp. base 6 LLRnet server that we're trying to dry out, via the method which we're using over in the Drive #3 thread to produce manual files from the server. This should be an interesting test of PRPnet's ability to handle multiple types of work at once.

I was just thinking of something: There should be a way to report LLRnet and now PRPnet as software used in a prover code at the top-5000 site!

Since this essentially just calls LLR automatically, and lets LLR do the actual work, I question whether this should really be necessary...LLRnet is slightly more integrated, but it's still essentially just a small shell around LLR. If they do get listed, I think it should be reported along with LLR to give Jean Penne proper credit for her software (both will get full credit).

Quote:

Originally Posted by gd_barnes

Max, do you suppose this will drive David nuts integrating this new server software into his process? After we get all the kinks worked out, I hope he can make an easy transition.

I wonder if it would be too hard to make it output the same as, or very close to, LLRnet server's output. (would it, rogue?)

p.s. When I got the modified LLRnet that could run non-Riesel numbers I called it prpnet.

Last fiddled with by Mini-Geek on 2008-12-30 at 13:19
Reason: finishing the p.s....those gerbils must've cut me off or something ;)

Since this essentially just calls LLR automatically, and lets LLR do the actual work, I question whether this should really be necessary...LLRnet is slightly more integrated, but it's still essentially just a small shell around LLR. If they do get listed, I think it should be reported along with LLR to give Jean Penne proper credit for her software (both will get full credit).

I wonder if it would be too hard to make it output the same as, or very close to, LLRnet server's output. (would it, rogue?)

p.s. When I got the modified LLRnet that could run non-Riesel numbers I called it prpnet.

Someone could set up a project on the Prime Pages and indicate that the project uses PRPNet, but I don't think that PRPNet should have a prover code.

I have no idea what LLRNet's output looks like. If you have a specific request for logging information, I can add it, but I have little desire to make it look like LLRNet.

Since this essentially just calls LLR automatically, and lets LLR do the actual work, I question whether this should really be necessary...LLRnet is slightly more integrated, but it's still essentially just a small shell around LLR. If they do get listed, I think it should be reported along with LLR to give Jean Penne proper credit for her software (both will get full credit).

Yes, since it's only running LLR and Phrot to do the back-end work, LLR and Phrot should be the ones listed for their respective primes found. That is, Phrot for PRPnet work done on non-power-of-2 bases, and LLR for power-of-2 bases.

Quote:

I wonder if it would be too hard to make it output the same as, or very close to, LLRnet server's output. (would it, rogue?)

My thoughts exactly. However, I was thinking something more along the lines of a quick little Perl script that would convert a prpserver.log file to an LLRnet format results file...that shouldn't be too hard, and would allow PRPnet servers to easily fit into our existing CRUS/NPLB server setup.

I'll probably get all the scripts ready to do the aforementioned results conversion, and generate status pages for PRPnet like we already do for LLRnet, sometime later today.

Quote:

Originally Posted by nuggetprime

Great work rogue!
Max,can we please keep one server for "small" candidates(sierp base 3,the new NPLB Drive #8)? That would be perfect for my P4.

Okay, that sounds good. Over at NPLB I suggested setting up a PRPnet server for Drive #9, which is the top-5000 range for Drive #8; however, its candidates are still going to be quite small, so that should be great for your P4.

As for loading Drive #8 work in a PRPnet server--it's worth a try, though I personally would like to see more data on the scalability of a PRPnet server before loading candidates quite that small into one. LLRnet servers tend to get flaky if you load anything < 200K into them and hit them with a whole project's worth of clients. Though, admittedly, LLRnet servers *have* always tended to be a little on the flaky side anyway--hopefully PRPnet will prove to be much more hardy.

Can you please give me a piece of server output file? I can try to make a bash script,if that also works.

Okay, here's the G3000 prpserver.log file from the time I started it up until 12/30/2008, 13:24:51 EST.

The main hangup, however, with converting PRPnet results to LLRnet results is that whereas LLRnet uses a screen name to identify users, PRPnet uses email addresses, and then computer ID's within that. However, I had an idea about how we can work around that: how about we set our computer ID's to our mersenneforum.org usernames, like we would with usernames in LLRnet? That way, when we integrate PRPnet results into our existing stats systems, they should merge in perfectly.

As for already-sent-in results that have individual computer names in that field, that can be fixed easily with a few search/replace commands. Nugget, I presume that the results from email address "hugoplatzer at aon dot at" represent you?

Last fiddled with by mdettweiler on 2008-12-30 at 19:19
Reason: removed attachment

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.A copy of the license is included in the FAQ.