PRPnet 1st drive-R/S base 2 even-k/even-n/odd-n
 

Hi all,

For quite a while now, Conjectures 'R Us has been making use of the PRPnet software to automate testing. With the recent release of PRPnet 2.2.3 and PFGW 3.2.0, PRPnet can test numbers at the same optimal speed as manual testing. Users can download the latest version of the client. If users are using an earlier version, we suggest performing a clean install of the latest version of PRPnet because a number of things have changed.

Update (2/7/11): The server is now running PRPnet version 4.1.4.

Instructions and download links can be found [URL="http://www.mersenneforum.org/showthread.php?t=12223"]here[/URL]. Though these instructions were written for the NPLB project, the procedures for CRUS are so similar that I figured it would be much simpler to only have to keep up this information in one thread. :smile: The only difference is that instead of plugging in NPLB's servers, you can use the CRUS servers, listed below. Note that one very cool advantage of PRPnet, as described in that thread, is the ability to mix work from multiple servers; you may even want to use it to mix work from NPLB and CRUS servers.

Server info.:

[B]CRUS PRPnet server #1 (updated 2011-08-09 21:00 GMT):[/B]
maintained by mdettweiler on gd_barnes machine
Short identification: G1300
server: noprimeleftbehind.net
port: 1300
base: Riesel/Sierpinski base 2 even-k/even-n/odd-n k's (16 k's)
n-range: 1M-2M
currently processing at n= [COLOR=#0000ff]2M (complete)[/COLOR]
Server summary: [URL]http://noprimeleftbehind.net:1300/all.html[/URL]

[B]The server has dried out pending more sieving.[/B]

Hey guys.

I thought I'd try setting up a PRPNET Server on my machine and run some Riesel Base 27 tests as a test.

I'm using PRPNET 2.2.3, PRP Server 2.0.4. I set up the Client config to use the PFGW provided with the 2.2.3 d/l. The client and server are on the same machine.

I start the server and the client and I get the first candidate to test. The client runs the PRP test (29 minutes) and tries sending it back to the server. I know it runs PFGW because it is the only application I pointed to in the client config file.

This is what I see on the server.

[2009-08-04 08:31:41 GMT] PRPNet Server application v2.0.4 started.
[2009-08-04 08:31:41 GMT] Please contact Mark Rodenkirch at [EMAIL="rogue@wi.rr.com"]rogue@wi.rr.com[/EMAIL] for support
[2009-08-04 08:31:41 GMT] Waiting for connections on port 7101
[2009-08-04 08:32:16 GMT] [EMAIL="IMGunn1654@gmail.com"]IMGunn1654@gmail.com[/EMAIL] (MyDog) at 192.168.2.7: Sent 706*27^200038-1
[2009-08-04 09:01:43 GMT] [EMAIL="IMGunn1654@gmail.com"]IMGunn1654@gmail.com[/EMAIL] (MyDog) at 192.168.2.7: Received 706*27^200038-1 : Residue
[2009-08-04 09:01:43 GMT] Error sending <<INFO: All 1 test results were accepted>> to localhost:7101
[2009-08-04 09:01:54 GMT] [EMAIL="IMGunn1654@gmail.com"]IMGunn1654@gmail.com[/EMAIL] (MyDog) at 192.168.2.7: Received 706*27^200038-1 : Residue
[2009-08-04 09:02:05 GMT] [EMAIL="IMGunn1654@gmail.com"]IMGunn1654@gmail.com[/EMAIL] (MyDog) at 192.168.2.7: Received 706*27^200038-1 : Residue
[2009-08-04 09:02:16 GMT] [EMAIL="IMGunn1654@gmail.com"]IMGunn1654@gmail.com[/EMAIL] (MyDog) at 192.168.2.7: Received 706*27^200038-1 : Residue
[2009-08-04 09:02:27 GMT] [EMAIL="IMGunn1654@gmail.com"]IMGunn1654@gmail.com[/EMAIL] (MyDog) at 192.168.2.7: Received 706*27^200038-1 : Residue
[2009-08-04 09:02:38 GMT] [EMAIL="IMGunn1654@gmail.com"]IMGunn1654@gmail.com[/EMAIL] (MyDog) at 192.168.2.7: Received 706*27^200038-1 : Residue
[2009-08-04 09:02:49 GMT] [EMAIL="IMGunn1654@gmail.com"]IMGunn1654@gmail.com[/EMAIL] (MyDog) at 192.168.2.7: Received 706*27^200038-1 : Residue
[2009-08-04 09:03:00 GMT] [EMAIL="IMGunn1654@gmail.com"]IMGunn1654@gmail.com[/EMAIL] (MyDog) at 192.168.2.7: Received 706*27^200038-1 : Residue
[2009-08-04 09:03:11 GMT] [EMAIL="IMGunn1654@gmail.com"]IMGunn1654@gmail.com[/EMAIL] (MyDog) at 192.168.2.7: Received 706*27^200038-1 : Residue
[2009-08-04 09:03:22 GMT] [EMAIL="IMGunn1654@gmail.com"]IMGunn1654@gmail.com[/EMAIL] (MyDog) at 192.168.2.7: Received 706*27^200038-1 : Residue
[2009-08-04 09:03:33 GMT] [EMAIL="IMGunn1654@gmail.com"]IMGunn1654@gmail.com[/EMAIL] (MyDog) at 192.168.2.7: Received 706*27^200038-1 : Residue
[2009-08-04 09:03:33 GMT] Error sending <<INFO: Test for candidate 706*27^200038-1 accepted>> to localhost:7101
[2009-08-04 09:03:33 GMT] [EMAIL="IMGunn1654@gmail.com"]IMGunn1654@gmail.com[/EMAIL] (MyDog) at 192.168.2.7: Received 706*27^200038-1 : Residue
[2009-08-04 09:03:33 GMT] Error sending <<INFO: All 1 test results were accepted>> to localhost:7101
[2009-08-04 09:04:59 GMT] Accepted force quit. Waiting to close sockets before exiting


This is what I see on the client:

[2009-08-04 08:32:12 GMT] PRPNet Client application v2.2.3 started
[2009-08-04 08:32:12 GMT] User name MyDogBuster at email address is [EMAIL="IMGunn1654@gmail.com"]IMGunn1654@gmail.com[/EMAIL]
[2009-08-04 08:32:12 GMT] Base27: Getting work from server 192.168.2.7 at port 7101
[2009-08-04 08:32:16 GMT] Base27: INFO: Server has a limit of 1 work units.
[2009-08-04 09:01:21 GMT] Base27: 706*27^200038-1 is not prime. Residue F7341739D1DAC792
[2009-08-04 09:01:21 GMT] Total Time: 0:29:09 Total Tests: 1 Total PRPs Found: 0
[2009-08-04 09:01:21 GMT] Base27: Returning work to server 192.168.2.7 at port 7101
[2009-08-04 09:01:43 GMT] Total Time: 0:29:31 Total Tests: 1 Total PRPs Found: 0
[2009-08-04 09:01:43 GMT] Base27: Returning work to server 192.168.2.7 at port 7101
[2009-08-04 09:01:54 GMT] Base27: INFO: Test for candidate 706*27^200038-1 accepted
[2009-08-04 09:01:54 GMT] Total Time: 0:29:42 Total Tests: 1 Total PRPs Found: 0
[2009-08-04 09:01:54 GMT] Base27: Returning work to server 192.168.2.7 at port 7101
[2009-08-04 09:02:05 GMT] Base27: INFO: Test for candidate 706*27^200038-1 accepted
[2009-08-04 09:02:05 GMT] Total Time: 0:29:53 Total Tests: 1 Total PRPs Found: 0
[2009-08-04 09:02:05 GMT] Base27: Returning work to server 192.168.2.7 at port 7101
[2009-08-04 09:02:16 GMT] Base27: INFO: Test for candidate 706*27^200038-1 accepted
[2009-08-04 09:02:16 GMT] Total Time: 0:30:04 Total Tests: 1 Total PRPs Found: 0
[2009-08-04 09:02:16 GMT] Base27: Returning work to server 192.168.2.7 at port 7101
[2009-08-04 09:02:27 GMT] Base27: INFO: Test for candidate 706*27^200038-1 accepted
[2009-08-04 09:02:27 GMT] Total Time: 0:30:15 Total Tests: 1 Total PRPs Found: 0
[2009-08-04 09:02:27 GMT] Base27: Returning work to server 192.168.2.7 at port 7101
[2009-08-04 09:02:38 GMT] Base27: INFO: Test for candidate 706*27^200038-1 accepted
[2009-08-04 09:02:38 GMT] Total Time: 0:30:26 Total Tests: 1 Total PRPs Found: 0
[2009-08-04 09:02:38 GMT] Base27: Returning work to server 192.168.2.7 at port 7101
[2009-08-04 09:02:49 GMT] Base27: INFO: Test for candidate 706*27^200038-1 accepted
[2009-08-04 09:02:49 GMT] Total Time: 0:30:37 Total Tests: 1 Total PRPs Found: 0
[2009-08-04 09:02:49 GMT] Base27: Returning work to server 192.168.2.7 at port 7101
[2009-08-04 09:03:00 GMT] Base27: INFO: Test for candidate 706*27^200038-1 accepted
[2009-08-04 09:03:00 GMT] Total Time: 0:30:48 Total Tests: 1 Total PRPs Found: 0
[2009-08-04 09:03:00 GMT] Base27: Returning work to server 192.168.2.7 at port 7101
[2009-08-04 09:03:11 GMT] Base27: INFO: Test for candidate 706*27^200038-1 accepted
[2009-08-04 09:03:11 GMT] Total Time: 0:30:59 Total Tests: 1 Total PRPs Found: 0
[2009-08-04 09:03:11 GMT] Base27: Returning work to server 192.168.2.7 at port 7101
[2009-08-04 09:03:22 GMT] Base27: INFO: Test for candidate 706*27^200038-1 accepted
[2009-08-04 09:03:22 GMT] Total Time: 0:31:10 Total Tests: 1 Total PRPs Found: 0
[2009-08-04 09:03:22 GMT] Base27: Returning work to server 192.168.2.7 at port 7101
[2009-08-04 09:03:33 GMT] Base27: INFO: Test for candidate 706*27^200038-1 accepted
[2009-08-04 09:03:33 GMT] Total Time: 0:31:21 Total Tests: 1 Total PRPs Found: 0
[2009-08-04 09:03:33 GMT] Base27: Returning work to server 192.168.2.7 at port 7101
[2009-08-04 09:03:33 GMT] Accepted force quit. Waiting to close sockets before exiting.

This is what my candidates file looks like AFTER the test:

706*27^200038-1 N 1249376613 active
706*27^200038-1 T 1249374736 [EMAIL="IMGunn1654@gmail.com"]IMGunn1654@gmail.com[/EMAIL] MyDogBuster MyDog na
706*27^200118-1 N 0 active
706*27^200214-1 N 0 active
706*27^200222-1 N 0 active
706*27^200254-1 N 0 active
706*27^200270-1 N 0 active
706*27^200342-1 N 0 active


Any help would be appreciated. Looks like something is amiss.

[QUOTE=MyDogBuster;183973]Hey guys.

I thought I'd try setting up a PRPNET Server on my machine and run some Riesel Base 27 tests as a test.

I'm using PRPNET 2.2.3, PRP Server 2.0.4. I set up the Client config to use the PFGW provided with the 2.2.3 d/l. The client and server are on the same machine.

I start the server and the client and I get the first candidate to test. The client runs the PRP test (29 minutes) and tries sending it back to the server. I know it runs PFGW because it is the only application I pointed to in the client config file.

Any help would be appreciated. Looks like something is amiss.[/QUOTE]

You must use the 2.2.x server with a 2.2.x client. The documentation doesn't state that, but that is the case.

[QUOTE]You must use the 2.2.x server with a 2.2.x client. The documentation doesn't state that, but that is the case. [/QUOTE]

Okay thanks. Anyone have a spare 2.2.x server Windows download hanging around?

[quote=MyDogBuster;184026]Okay thanks. Anyone have a spare 2.2.x server Windows download hanging around?[/quote]
The PRPnet downloads that rogue posts in [URL="http://www.mersenneforum.org/showthread.php?t=11220&page=4"]his thread[/URL] include the server.
[url]http://home.roadrunner.com/~mrodenkirch/prpnet_2.2.3.zip[/url]

Thanks Tim. I was toooooo lazy to look myself. LOL

I've split off all the stuff regarding the barfing problems and other such 2.2.3 server bugs to a [URL="http://www.mersenneforum.org/showthread.php?t=12256"]separate thread[/URL]. It was really starting to clutter up this thread quite a bit. :smile:

Due to the inherent difficulties with running PRPnet with a large # of cores, in discussion with the other admins, it has been decided to delay the implementation of PRPnet servers for project level drives by at least 3-6 months. The same applies at NPLB. PRPnet servers are still highly recommended for personal use for use on up to about 10 cores depending on the length of tests. The servers should not be used for very short tests or for huge # of k's such as would be the case for bases 3/7/15.

In the near future, we will be loading Sierp base 22 into port 3000. The tests will take longer than base 6 and there are only 4 k's remaining. Likely we'll still have a few issues with PRPnet if more than 20 cores are running it but the issues will not affect the primality tests themselves. We may just have to test some pairs manually or feed them back through the server a second time.

Sierp base 6 will be continued with manually reserved files. Riesel base 6 still needs some more sieving so we will start a sieving drive on that over the next few days before rolling out a new drive for it. Both sides are complete to n=150K. Karsten tested most of the Riesel side to that limit.

I have changed the 1st posting in this thread to reflect this change in project direction.


Gary

Max,

The status (1st) link looks garbled and the simiplied status (2nd) link is blank.

The users stats link looks OK.

Is this because the server has dried?

Regardless, when we do roll this out at the project level at NPLB and CRUS, we'll still want to make sure that all links work, even if the server has dried out.


Gary

[quote=gd_barnes;185360]Max,

The status (1st) link looks garbled and the simiplied status (2nd) link is blank.

The users stats link looks OK.

Is this because the server has dried?

Regardless, when we do roll this out at the project level at NPLB and CRUS, we'll still want to make sure that all links work, even if the server has dried out.


Gary[/quote]
The status page looks like that because the server's dried; it's a known bug, though relatively lower on the list of importance due to bigger issues with barfing, etc.

The simplified status page is a mystery of a different kind. Based on what we've been seeing a bit of lately, it's possible that accessing it prompts the server to drop some candidates from the prpserver.candidates file as Ian encountered earlier. However, we don't have enough data as of yet to confirm that this is the true cause of this problem. (At any rate, I'll take the link off the first post so that nobody messes up the server when it's got the new Sierp. base 22 stuff in it, if that is indeed the trigger for the test-dropping problem.)

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=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

Sierp base 22 is now unofficially complete to n=200K and the server has dried. It will be considered officially complete once Max has processed the results to me and I verify that all are there.

The drive will be paused for about a day while additional sieving is being done. When sieving is complete, n=200K-250K will be loaded into the PRPnet server.

For this higher n-range, I'm going to suggest that we try putting more cores on it if people have them available. Current tests are running 30-40 mins. and will likely run up to ~50 mins. as we approach n=250K.


Gary

Gary has completed sieving for base 22 up to p=7T and I've now loaded 200K-250K for Sierpinski base 22 into the port 1300 server. This is a rather interesting base due to its proving being well in sight, with only 4 k's remaining at n=200K. It will nonetheless be a somewhat big job, as at this point each test takes about 45 minutes on a fast machine. If anyone wants to throw a core or two (or more :smile:) on this, it would be greatly appreciated.

Another thing about this base is that it has the potential to turn up some very big primes--as Gary said earlier, they would be more than 260,000 digits! This means that they'd rank within the top 500 biggest primes of all time.

Max,

When you get back, can you look and see why the server doesn't appear to have handed out pairs for 1611*22^207280+1 and 4233*22^207262+1? None of my 4 clients shows them as having been received and I don't see where anyone else would have grabbed them.

Other than those, it appears, that we're at n=~210K on this drive at this moment.


Thanks,
Gary

[quote=gd_barnes;193134]Max,

When you get back, can you look and see why the server doesn't appear to have handed out pairs for 1611*22^207280+1 and 4233*22^207262+1? None of my 4 clients shows them as having been received and I don't see where anyone else would have grabbed them.

Other than those, it appears, that we're at n=~210K on this drive at this moment.


Thanks,
Gary[/quote]

Max,

This is odd...those were handed back out a couple of days ago and processed. I looked back in the logs and it appears that it just skipped them for some reason. It's like the server "thought" someone took them but never processed them, waited some "JobMaxTime" interval, and then handed them back out again.

Any ideas?

At this moment, we've now at n>217K.


Gary

I think the PRPnet server is down. I can't connect to it with my 2.4.1 client, and the web page links for it aren't working. (first noticed it 2009-10-21 09:15:43 GMT, i.e. 4:15 AM CDT, and checked again just before I posted this)
Edit: I just tried a few other PRPnet servers, (some hosted at prpnet.primegrid.com, [URL="http://www.psp-project.de"]www.psp-project.de[/URL], and pgllr.mine.nu) and I can't connect to any. Has nobody except me switched to 2.4.1 or something? (2.4 clients can't communicate with older servers, but 2.4 servers will still talk to 2.3 clients) Perhaps the problem is on my end, but I can't think what that'd be...(unless it's the version)
Either way, the fact that I can't load the status pages for this server is indicative of a problem.

Yeah. There seems to be a problem. It's been working great for several weeks now and you came over just as it went down. lol

I know little about PRPnet servers and everything is quite cryptic. I'll check to see if I can easily restart it. I'm kind of wondering if it is doing its barfing thing.

OK, I killed the server and restarted it. I just checked my clients and it seems to be working fine now. The links in the 1st post are also working.

Sorry about the problem.

Max, can you check the log on port G1300 when you get back to see if you can tell what caused this? As an FYI, I tried doing a "warm" kill of the server by doing Ctl-C but it kept saying that it was waiting for socket 5 to close. So I went into the system monitor and did a "cold" kill on it. I then waited about a minute and restarted it with the command that you've given me.


Gary

My client still can't communicate. Is the server 2.3 or 2.4?

[quote=Mini-Geek;193451]My client still can't communicate. Is the server 2.3 or 2.4?[/quote]

Neither. It's 2.2.3 according to the greeting.txt file. (I have to assume that is correct.) I think Max upgraded his personal PRPnet server to 2.4 but hadn't had time to upgrade this one or the one that I'm going to use for Riesel base 22.

Can you read the links in the 1st post here?

Max,

There seems to be some blank residues for some tests right around the time that the server went down. Can you look into that?

I think we really need to upgrade the server to a more recent version.


Gary

[quote=gd_barnes;193461]Neither. It's 2.2.3 according to the greeting.txt file. (I have to assume that is correct.) I think Max upgraded his personal PRPnet server to 2.4 but hadn't had time to upgrade this one or the one that I'm going to use for Riesel base 22.[/quote]
Well, that would certainly explain it, but who knows if greeting.txt is right. If you can see the screen output from prpserver.exe (i.e. what appears in the command line window) it should tell you what version it is as it starts up (so it'll be in the top couple lines of text).
[quote=gd_barnes;193461] Can you read the links in the 1st post here?[/quote]
Partially. (seems to just be PRPnet being weird, possibly because it's an older version; but the fact that I get anything is a good sign) The /user_stats.html page looks correct, the /server_stats.html (same as /) page looks garbled, (e.g. first line is "+ADw-style type+AD0AIg-Text/css+ACIAPgA8-/style+AD4APA-/head+AD4-") and /server_status.html is blank.

[QUOTE=Mini-Geek;193463]Well, that would certainly explain it, but who knows if greeting.txt is right. If you can see the screen output from prpserver.exe (i.e. what appears in the command line window) it should tell you what version it is as it starts up (so it'll be in the top couple lines of text).

Partially. (seems to just be PRPnet being weird, possibly because it's an older version; but the fact that I get anything is a good sign) The /user_stats.html page looks correct, the /server_stats.html (same as /) page looks garbled, (e.g. first line is "+ADw-style type+AD0AIg-Text/css+ACIAPgA8-/style+AD4APA-/head+AD4-") and /server_status.html is blank.[/QUOTE]

Definitely not 2.4.1.

The links in the 1st post display perfectly to me. I'm trying to figure out why they'd be any different for you. We're now at n=~219K.

Max, not to be too dictatorial here but the first priority after you get back and after you load up the NPLB server and my private PRPnet server should probably be to upgrade this CRUS server to 2.4.1. It stinks when someone who wants to do work on it can't. Let me know if I can do anything to help. I assume you'll have to update my clients also. If I can just copy some client files over to speed the process along, I will.

Edit: I just checked and the screen output from pairs being sent and received definitely shows version 2.2.3. I also see that Max shows that in the 1st post of this thread.


Thanks,
Gary

Oh, yowch. Just what I was afraid of coming back from my trip to find. :rolleyes:

First of all, to answer a question that seems to have popped up a few times, all the servers except my personal server are running 2.3.0, which includes G1300. The greeting.txt entry (which includes what Gary was seeing in his client logs as well) was just my laziness in not updating that file when I upgraded the server. Sometime or other I'll just take the version number out of there so I don't have to bother. :wink:

I'll take a look at it as soon as I get the chance. As of now, I didn't get the chance to read the latest action here in detail. I may be able to do something tonight, but it may have to wait until tomorrow.

Ergh, I figured it out now. *bangs head*

Okay, first of all, regarding those two 207K pairs that are behaving strangely: that's due to some fallout from a little bug which I explained earlier regarding the time the server takes to sort candidates by decimal length when they're first loaded. Gary, if I explained the full intricacies of this bug here it would probably just end up confusing you more, so I'll suffice to say just that I'm aware of the problem and will take any action necessary. :wink:

Mini-Geek, the reason why you're having problems using your spanking new 2.4.1 client is that while the 2.4 server is backwards-compatible with earlier clients, the reverse is not true. That is, you have to have a 2.4 server to run a 2.4 client.

As of now, the only "live" server I know of running 2.4.1 is my personal PRPnet server, on which I planned to test the new version in action before putting it out on the other servers. My original goal was to have that testing go on while I was away, but since my quad was off the whole time, that didn't happen. I'll give it another day or two and assuming everything checks out, I'll upgrade everything else to 2.4.1. That way, people will be able to connect with either 2.3 or 2.4 clients (or even 2.2 clients like Gary's--yes, that reminds me, when we get everything upgraded to 2.4 I'll send him new client packages for his setup :smile:), and we should be finally free of blank results ("barfs"). :grin:

Ah, makes sense. No need to explain details. I remember before when we started (or restarted) a server that the first few pairs would sometimes go off into la-la land for days before being handed out. That isn't a "really bad" problem in my mind since they eventually get properly tested. It's just like someone cached them and never tested them.

How will we get the pairs with blank residues retested? Will we need to do that manually?

Sorry to hear about your quad not being on. I noticed it too. That is, I saw that your personal server on my machine was not handing anything out. Too bad I couldn't remotely turn it on for you. lol

Quick update: I just took a look at all the PRPnet servers and have verified a couple of things.[LIST][*]The little issue with those 207K pairs on G1300 acting strangely seems to have resolved itself, as I would have expected it to.[*]PRPnet 2.4.1 seems to be working OK on my personal server, and I'll continue testing it over the next couple of days. I did encounter a strange segfault on the server end that seemed like it might have had something to do with some rejected/expired tests from some of my clients that had sat for a week with work in queue. I'll wait and see if it turns up again.[/LIST]Everything seems A-OK now. :smile:

Tim,

For the next couple of days until Max is comfy with version 2.4.1, you might try running this effort with version 2.3 clients since we know it is 2.3 now.


Gary

[quote=gd_barnes;193636]How will we get the pairs with blank residues retested? Will we need to do that manually?[/quote]
For personal servers (mine, yours, and results I've processed for anyone else like Sven or Lennart), I usually just fill them in myself, since there usually isn't too many of them. Actually, interestingly enough, there seem to be two types of barfed results that occur: one where only one blank result is recorded, and the other where two results are recorded, one blank and one correct. Quite often they're the latter, so the easiest way to clean up all barfs with one process is find and delete any lines with blank results, then fill in any k/n pairs that shouldn't be there but aren't.

Though I haven't actually yet had to do any results processing for CRUS PRPnet servers (the first will be for the 150K-200K range of Sierp. base 22 which is waiting for me as soon as I get the chance), I'll be using the same process outlined above to clean out barfs. Of course, as always, everything will be verified against the original sieve file to make sure there is one and only one result in the end for each sieve file entry.

For NPLB, the situation will be a bit more complex. The G2000 server we've got running over there is doublechecking work we've already done the first time around, which means that I won't, in fact, have to "process" the results, per se. Instead, we'll just have both the first-pass and doublecheck results loaded into the DB, and let the DB compare the two runs and notify us of any mismatches or holes in either set. To handle barfs in this setting, Dave's going to set it up so that any blank results are automatically ditched. In the case of the Type II barf described above, we'll be left with one good result, or with a Type I barf, we'll be left with a hole, which can then be easily spotted and filled in when we're checking the two datasets against each other.
[quote]Sorry to hear about your quad not being on. I noticed it too. That is, I saw that your personal server on my machine was not handing anything out. Too bad I couldn't remotely turn it on for you. lol[/quote]
Yeah, I was hoping to get on and send you an email so you wouldn't be wondering about what had happened, but didn't get the chance since I was quite busy pretty much the whole time. Speaking of turning things on remotely, though, that's something I'd been pondering for a while that could be quite useful for my quad. Most motherboards today are supposed to support "Wake On LAN", which allows a computer to be turned on via a network signal. Theoretically, this would be exactly what I need. However, in practice, I have never, ever gotten this to work on any computer, regardless of how modern, even when I try to make it easier on the computer by only putting it in standby instead of shutting it down. :smile: If anyone else around here has used Wake on LAN successfully, please send me a PM or email about how you did it! :smile:

[quote=gd_barnes;193638]I wrote a response at about the same time as yours. Just one more question there.[/quote]
Yep, saw that and included it in my next note. :smile:
[quote=gd_barnes;193639]Tim,

For the next couple of days until Max is comfy with version 2.4.1, you might try running this effort with version 2.3 clients since we know it is 2.3 now.


Gary[/quote]
Actually, in fact, I was going to write a note to Tim saying that he's welcome to use my personal server if he wants to play around with a 2.4.1 client, if he doesn't mind doing my work. :wink: Tim, you can expect a PM about this in a few minutes.

With PRPnet 2.4.3 seeming to be quite stable on both the server and client ends, I've upgraded all the NPLB and CRUS servers to the latest version. Note that while the 2.4.3 server is backwards-compatible with older clients, a 2.4 client will only work with a 2.4 server.

Since PRPnet 2.4's largely revamped communications protocol should make it immune to the blank-residue problem that plagued earlier versions, we are no longer bound by the limitation of minimizing server load drastically. Discussion is welcome on what which bases and drives we should put on PRPnet besides Sierp. base 22 which we already have in G1300.

The server has now dried and the drive is complete.

[quote=gd_barnes;198167]The server has now dried and the drive is complete.[/quote]
Gary, were we planning to continue this one up to 300K?

[quote=mdettweiler;198204]Gary, were we planning to continue this one up to 300K?[/quote]

Oh, I'm not sure. Is the sieving sufficient for that high? I sieved it to P=7T but can't remember if I anticipated breaking off n=200K-300K when computing the optimum depth.

Regardless, for the time being, I'll move my machines to another effort. I can only stomach the real long tests for a few weeks. :smile:


Gary

[quote=gd_barnes;198270]Oh, I'm not sure. Is the sieving sufficient for that high? I sieved it to P=7T but can't remember if I anticipated breaking off n=200K-300K when computing the optimum depth.

Regardless, for the time being, I'll move my machines to another effort. I can only stomach the real long tests for a few weeks. :smile:


Gary[/quote]
Hmm...I didn't do any calculations regarding optimal depth, so I don't know. I just sort of assumed that we'd keep going for a while before doing any more sieiving.

Max,

After a quick check, I determined that we had sieved this far enough for testing to n=300K. We'll need more sieving after that. At your leisure, please load up n=250K-300K and update the first post accordingly.


Thanks,
Gary

[quote=gd_barnes;198846]Max,

After a quick check, I determined that we had sieved this far enough for testing to n=300K. We'll need more sieving after that. At your leisure, please load up n=250K-300K and update the first post accordingly.


Thanks,
Gary[/quote]
Okay, all loaded up. :smile:

Just to give everyone a heads-up:

At this time, I am getting ready to upgrade the port 1300 PRPnet server to version 3.2.6; at this time, it is the only one of our servers that's still on 2.4.6. Since Mathew Steine has been the only regular contributor on that server of late, I've sent him a PM informing him of the pending upgrade; I'll wait until I've received word from him that he's all set with the new client to upgrade the server.

[quote=mdettweiler;216744]Just to give everyone a heads-up:

At this time, I am getting ready to upgrade the port 1300 PRPnet server to version 3.2.6; at this time, it is the only one of our servers that's still on 2.4.6. Since Mathew Steine has been the only regular contributor on that server of late, I've sent him a PM informing him of the pending upgrade; I'll wait until I've received word from him that he's all set with the new client to upgrade the server.[/quote]
The upgrade is now complete and appears to have gone smoothly. Hey, if anyone else out there wants to give a hand on this server, it would be greatly appreciated! :wink:

The server is almost at n=300K, so I'm going to go ahead and load in 300K-350K. I was going to wait until Gary got back from his trip, but he's two days overdue and the server's about to dry.

Note that this new sieve file is sieved to the much more optimal depth of p=5T (rather than 700G as the old one was), so this should go at least a little faster. :smile:

What? The last time I checked (about 5 hours ago) there were still ~50 tests left and that should take me about 2 days to complete. That should be plenty until Gary returns. Unless of course other people grab some tasks.

I thought after it reached 300k we would switch to a new base (my suggestion is R24 110's at 50K with a decent sieve file to 100K)

[quote=Mathew Steine;222883]What? The last time I checked (about 5 hours ago) there were still ~50 tests left and that should take me about 2 days to complete. That should be plenty until Gary returns. Unless of course other people grab some tasks.

I thought after it reached 300k we would switch to a new base (my suggestion is R24 110's at 50K with a decent sieve file to 100K)[/quote]
Hmm, I guess you're right...I hadn't done any hard calculations on how long it would take you to polish off n<300K so that was just a rough guess.

Gary and I had discussed the possibility of switching to S26 (3 k's at 300K) when S22 was finished up to 300K. However, in his absense I figured the safest bet was to just load in the next S22 range. Note that until we actually cross the 300K boundary, I can remove n>300K from the server with a minimum of hassle. Hmm...okay, let's do that. I've removed all n>300K from the server now, so it's back to the way it was before I loaded any more work in.

Assuming Gary comes back before the server actually dries, we can discuss with him what to load in there next. If not, then we can possibly load in a small amount of R24 (50K-60K, maybe) to hold it over until he does.

Sorry. I'm just now getting back on after a lot of organization and clean up between my 2 planned out-of-town trips. I'm leaving Weds. again and will be gone until the following Thurs. For the upcoming trip, I will be on every day for about an hour or so. I had no access on my last trip.

My preference is to load in S26 for n=250K-300K. The idea behind this drive has been to "catch up" some bases with their neighbor bases that have similar #'s of k's remaining. Looked at in that way, S26 with only 3 k's remaining is a higher priority than S22 for n>300K.

I had actually observered this server not long after I got back early Saturday and figured that it would dry sometime late Tuesday. I'm glad that Max decided to subsequently delete n>300K.

Max and Matthew, are you OK with S26 for n=250K-300K? Matthew, I do not recommend smaller tests such as R24 for a PRPnet server because the overhead time associated with the sending and returning of pairs is not worth it for shorter tests. Mark had mentioned that previously.

Max, since Matthew has been the only one on here for a while, if he would really like to do S22 for n>300K, then go ahead and load it for n=300K-350K instead of S26. BUT...do you actually have an S22 file for n=300K-500K sieved to P=50T? I do not remember sending that to you and we definitely don't want a file only sieved to P=7T loaded in there.

I'll check for a response to this in a few hours. If I need to send the next S22 file to Max, I will at that time. But other than this, this is all that I will have time to respond to until very late today including PMs and Emails. I'll have time for a full-fledged response to everything on Tuesday.


Gary

[quote=mdettweiler;222857]The server is almost at n=300K, so I'm going to go ahead and load in 300K-350K. I was going to wait until Gary got back from his trip, but he's two days overdue and the server's about to dry.

Note that this new sieve file is sieved to the much more optimal depth of p=5T (rather than 700G as the old one was), so this should go at least a little faster. :smile:[/quote]

That is incorrect. The new file is sieved to P=50T and the old one to P=7T. You're off a digit.

So, can I assume that you have the newest sieve file for S22?

Gary,

I have no problem with S26 to 300K (Also on your recommended bases list). Hopefully more will connect else it may be ~6 months to complete. I understand you were trying to even the sides out. I was thinking R24 because S24 was already to 100K and it was the lowest base on the recommended misc section. I did not know about the overhead issues though. Now that makes sense.

Mathew

[QUOTE=gd_barnes;222903]Max and Matthew, are you OK with S26 for n=250K-300K? Matthew, I do not recommend smaller tests such as R24 for a PRPnet server because the overhead time associated with the sending and returning of pairs is not worth it for shorter tests. Mark had mentioned that previously.[/QUOTE]

For public PRPNet servers, PRP tests should take at least 60 seconds before being loaded. For private PRPNet servers, the time can be shorter (20 seconds or so) because you won't have the internet overhead. For servers with smaller workunits, I would recommend bumping the max number of work units high enough so that clients can grab two hours or more of work at a time.

Note that these are personal opinions.

[quote=gd_barnes;222903]Sorry. I'm just now getting back on after a lot of organization and clean up between my 2 planned out-of-town trips. I'm leaving Weds. again and will be gone until the following Thurs. For the upcoming trip, I will be on every day for about an hour or so. I had no access on my last trip.

My preference is to load in S26 for n=250K-300K. The idea behind this drive has been to "catch up" some bases with their neighbor bases that have similar #'s of k's remaining. Looked at in that way, S26 with only 3 k's remaining is a higher priority than S22 for n>300K.

I had actually observered this server not long after I got back early Saturday and figured that it would dry sometime late Tuesday. I'm glad that Max decided to subsequently delete n>300K.

Max and Matthew, are you OK with S26 for n=250K-300K? Matthew, I do not recommend smaller tests such as R24 for a PRPnet server because the overhead time associated with the sending and returning of pairs is not worth it for shorter tests. Mark had mentioned that previously.

Max, since Matthew has been the only one on here for a while, if he would really like to do S22 for n>300K, then go ahead and load it for n=300K-350K instead of S26. BUT...do you actually have an S22 file for n=300K-500K sieved to P=50T? I do not remember sending that to you and we definitely don't want a file only sieved to P=7T loaded in there.

I'll check for a response to this in a few hours. If I need to send the next S22 file to Max, I will at that time. But other than this, this is all that I will have time to respond to until very late today including PMs and Emails. I'll have time for a full-fledged response to everything on Tuesday.


Gary[/quote]
Ah, glad to see you're still alive. :smile: Since you'd said earlier that you would be home Saturday afternoon, by Monday morning I was beginning to wonder if something unfortunate had happened. :rolleyes:

Yes, I have the latest sieve file for S22, sieved to 50T. It does seem I miscounted by a digit.

I'll go ahead and load in S26 for n=250K-300K shortly.

BTW, regarding the size of tests to run in a PRPnet server, note that I've been running 1-k bases starting at 25K through my personal server with no problems. (And that's with full internet overhead since it's being hosted on your machine.) Granted, those bases are sufficiently big that 25K is not terribly tiny, but still, n=50K on R24 shouldn't pose a problem for a v3.x PRPnet server. At that level, I'd be more worried about having to process the results with all those k's eliminated partway through than whether the server can handle it. :smile:

S22, n=250K-300K has now been loaded into port 1300.

Hi all,

In case any of you guys aren't following the NPLB forum, we had a hard drive crash on jeepford, the NPLB/CRUS server machine, yesterday. It created a few bad blocks here and there on the disk, but Gary was able to get it fixed pretty well with the Linux fsck utility.

What we didn't know until just now is that there was some data loss from the crash. While NPLB's servers and stats database escaped unscathed, the CRUS port 1300 server's database and those of Gary and I's personal servers went bye-bye.

I should be able to reconstruct the candidate load of each server pretty easily from their results files, so we won't lose more than a day of processing on any of them. However, the user stats and user primes stored in each server will be lost. That's not a big deal for the private servers, but unfortunately it means our only stats for port 1300 will be reset to 0. (We haven't yet found any primes on port 1300 since it's been upgraded to PRPnet 3.x, so there's nothing to lose there.)

Port 1300 will be the first one I reconstruct. I hope to have it up within a few hours.

Max :smile:

Port 1300 is back up and I see one of Mathew's clients has already grabbed two pairs from it.

That wasn't too hard; now I get to tackle the personal servers. Gary's won't be too hard (one of them is empty, the other is is a pretty straightforward job like 1300), but mine will be a bit of a pain since I had a handful of different CRUS bases loaded in there. Ergh.

Oops, it seems that I accidentally loaded the pairs back in as base 2 instead of base 26. :ermm: It's fixed now...sorry Mathew for the wasted CPU-time of the last couple hours.

Max,

I expect port 1300 to dry out in ~1 week at Mathew's current rate of processing. He and I discussed putting R31 for n=120.2K-150K next into the server unless you have a better idea.

Mathew,

Did you say that you determined that R31 is sieved far enough? For such a small n-range at P=3.5T, it is probably far enough. Sieving small n-ranges (that is max-n/min-n < 1.5) very deep is usually inefficient. What is left is the tail-end of a larger sieve file.


Gary

[QUOTE=gd_barnes;231072]Max,

I expect port 1300 to dry out in ~1 week at Mathew's current rate of processing. He and I discussed putting R31 for n=120.2K-150K next into the server unless you have a better idea.

Mathew,

Did you say that you determined that R31 is sieved far enough? For such a small n-range at P=3.5T, it is probably far enough. Sieving small n-ranges (that is max-n/min-n < 1.5) very deep is usually inefficient. What is left is the tail-end of a larger sieve file.


Gary[/QUOTE]
Sounds good. I'll await further confirmation of optimal depth before going ahead and loading it.

Gary,

I did not do any tests. I just came to the same conclusion as you, it is probably sieved far enough.

Max,

Feel free to load R31.

I've added a core to the cause. I would suggest a sort option of A so that bases will complete by oldest loaded first.
I may add more cores when other tests end. Hope you don't mind the company Mathew.

Any suggestions on what to add after R31? I have resources for a sieve.

R31 is now loaded, and the server is on sortoption=A. (It was on N before. I'm not sure why it wasn't on A to begin with; since A sorts by decimal length within a file, it's effectively the same as N most of the time, so I usually always use A except where otherwise necessary.)

Max,

I am confused now. It looks like the server is only doling out the largest k. There is an n difference of over 1600 between the largest k and the next one. The other 2 k's should be smaller in decimal length.

MyDogBuster,

I could always use more company.

[QUOTE=Mathew Steine;231204]Max,

I am confused now. It looks like the server is only doling out the largest k. There is an n difference of over 1600 between the largest k and the next one. The other 2 k's should be smaller in decimal length.[/QUOTE]
Hmm, very strange...looking at the database and sorting by LastUpdateTime, then DecimalLength (that is, the same criteria the server uses on sortoption=A) I see that the pairs are listed in alphabetical order--that is, sorted by k but with k=155 coming before k=32. And LastUpdateTime (a Unix time value) seems to increment by 1 for each k in that order. :huh:

I'm not entirely sure what happened here, but can only suppose it has to do with how I re-loaded the pairs after that big server crash a few weeks back where most of our PRPnet servers got wiped. To do that I processed the incomplete pairs from the server's results files, sorted them by n, ran a diff comparing the result with the original sieve file, and loaded the missing pairs back into the server. What I'm seeing now would almost seem to indicate that I'd sorted them by k, which doesn't seem right.

Anyway, whatever happend, I must have had a good reason for it at the time. :rolleyes: That must have been why the server was set to sortoption=N, so that the pairs would be handed out in the right order despite how I loaded them. So I'm sure it wasn't a PRPnet bug but rather something I did when I was re-loading the pairs.

Now that R31 is loaded into the server, there's not much I can do about it (since changing it back to sortoption=N would make it hand out R31 pairs); no big deal, we're close enough to the end of the range anyway that the effect will hardly be noticeable. :smile: (It will all get done at the same time it originally would have, just in slightly different order.)

Max,

Can you 100% for sure say that the pairs will be handed out in n-value order within each k-value? If so, I suppose that is OK for the few remaining pairs of S22. BUT...It is not OK for the much larger n-range and twice as many k's on R31.

Can you 100% guarantee us that R31 will be handed out entierly in n-value order after finishing S22? We don't want to test one k at a time on R31.

Is there a way you can post a file of the order in which everything should be handed out? If it's too much trouble, don't worry about it.


Gary

[QUOTE=gd_barnes;231206]Max,

Can you 100% for sure say that the pairs will be handed out in n-value order within each k-value? If so, I suppose that is OK for the few remaining pairs of S22. BUT...It is not OK for the much larger n-range and twice as many k's on R31.

Can you 100% guarantee us that R31 will be handed out entierly in n-value order after finishing S22? We don't want to test one k at a time on R31.


Gary[/QUOTE]
Yes, the few pairs remaining on S26 will be handed out in alphabetical k order primary, then n secondary. R31 will then be handed out in standard n-value order (or more precisely, decimal length; but that essentially works out to n-value order anyway).

OK, sounds good.

[QUOTE=mdettweiler;231167]R31 is now loaded, and the server is on sortoption=A. (It was on N before. I'm not sure why it wasn't on A to begin with; since A sorts by decimal length within a file, it's effectively the same as N most of the time, so I usually always use A except where otherwise necessary.)[/QUOTE]

N is slightly better than A. Otherwise:

2*3^n+1

would be handed out before:

8*3^(n-1)+1

because the latter is larger even though the former n-value is larger.

IMHO, it is "slightly" better to have everything in n-value order -or- everything in k-value order...not size order, which is difficult to visualize when looking, especially on large conjectured bases.

It would get even more ridiculous where one k-value is teeny (like k=2) and the other is huge (like k=50G) on Riesel base 3. The teeny k could have an n-value that is > 10 more than the huge k n-value yet the form would still be smaller and so the former k with the much larger n-value would get handed out first.

Sort option A should probably only be used when more than one base is being tested and you happen to want to test them all upwards at about the same length. (Personally I'd still prefer N as long as the range of bases was not too large.) Even when testing both the Riesel and Sierp side of the same base, sort option N is still slightly better IMHO.


Gary

Thinking way ahead here: After we're done with R31, we might consider loading our team drives for R16 and S16 in here; both at the same time and hand them out in n-value order so that one catches up with the other and then they run in concert with each other.

I think they could probably be sieved further. When I sieved them, I wasn't using my speedier sieving I7.

It would be nice to get those moving up towards n=1M base 2 (n=250K base 16).

...Just food for thought right now. No decision needed at this point. The 2 bases are good candidates for a server due to the fair # of k's remaining and the fairly high current search depth. Heck, we could even have a CRUS PRPnet rally on them sometime in the future. :smile:

If we're looking for stuff to do, I'd like to get all the bases < 250 up to at least n=100K, excluding the high ck ones with loads of k's left. Put the cutoff point at something like 20k's remaining. Sieve them, load them and let 'er rip.

JMHO

I'd probably run the base 16 stuff, but it's not my first choice, more like a "If that's all there is "

Any preference Mathew?

[QUOTE=gd_barnes;231211]N is slightly better than A. Otherwise:

2*3^n+1

would be handed out before:

8*3^(n-1)+1

because the latter is larger even though the former n-value is larger.

IMHO, it is "slightly" better to have everything in n-value order -or- everything in k-value order...not size order, which is difficult to visualize when looking, especially on large conjectured bases.

It would get even more ridiculous where one k-value is teeny (like k=2) and the other is huge (like k=50G) on Riesel base 3. The teeny k could have an n-value that is > 10 more than the huge k n-value yet the form would still be smaller and so the former k with the much larger n-value would get handed out first.

Sort option A should probably only be used when more than one base is being tested and you happen to want to test them all upwards at about the same length. (Personally I'd still prefer N as long as the range of bases was not too large.) Even when testing both the Riesel and Sierp side of the same base, sort option N is still slightly better IMHO.


Gary[/QUOTE]
Indeed--hence why I mentioned that decimal length is "effectively the same" as n-value, not exactly the same. :smile: Still, for most purposes it's close enough that it's no big deal. I usually prefer to use sortoption=A instead of N because it allows me more direct control over what order things are handed out in; it's roughly similar to LLRnet's method of handing out pairs as they're encountered in the knpairs file.

For servers that will usually stay on the same kind of work proceeding upward by n (such as NPLB's port 9000), there's not much point in using A. If, as suggesed in your next post, we move port 1300 to the bases 16 after it finishes R31, then sortoption=N would be a good fit for it.

Regarding doing the bases 16 next in port 1300: sounds good to me. We could use some help on those drives. :smile: Though Ian's idea of getting the "non-hard" bases <250 up to 100K first is also a possibility.

Max,

You've royally confused me. I quote you twice:

[quote]
It was on N before. I'm not sure why it wasn't on A to begin with; since A sorts by decimal length within a file, it's effectively the same as N most of the time, so I usually always use A except where otherwise necessary.[/quote]

[quote]
I usually prefer to use sortoption=A instead of N because it allows me more direct control over what order things are handed out in; it's roughly similar to LLRnet's method of handing out pairs as they're encountered in the knpairs file.[/quote]

You have contradicted yourself. You specifically said that sortoption A hands out in decimal size order and then you go on to imply that it hands out pairs as they are encountered.

So which is sortoption A? Entry (oldest to newest) sequence or decimal value sequence? If its decimal value sequence, N is slightly better. If it's entry sequence, then I agree with you that A is usually better because you have more control.

Edit: I just now checked Jeepford. A is sorted by "oldest candidate" or entry sequence. Now you can see why I got mixed up. The "length sequence" that you were originally talking about is sort sequence "L". Therefore I agree that A is best in most situations for our needs.


Gary

[QUOTE=gd_barnes;231219]You have contradicted yourself. You specifically said that sortoption A hands out in decimal size order and then you go on to imply that it hands out pairs as they are encountered.

So which is sortoption A? Entry (oldest to newest) sequence or decimal value sequence? If its decimal value sequence, N is slightly better. If it's entry sequence, then I agree with you that A is usually better because you have more control.[/QUOTE]

When using sortoption A (oldest first), decimal length is used as a tie-breaker. Since the server is loaded using ABC files and since the ABC files have the shortest candidates (presuming the file wasn't edited by hand), this allows one to clear out older bases before newer bases and to clear out the older bases by decimal length.

With PRPNet 4.0.0, which is nearing a release as I write this, you will have more control over sorting. It will allow you to specify multiple sort options (always ascending) instead of one. That will eliminate some of the confusion caused by sortoption A and L.

I have now processed port 1300's completed results for S26, n=250K-300K. No primes were found; the results are attached here. The base is now released.

Hum. It seems that Mathew has found a R31 top-5000 prime! :smile:

Leave it to a heavy weight base not in the twenties to finally score one. The bases in the twenties have been dormant for an eternety including the 10 k's for both sides of base 28, which have been completely dormant for n=105K-190K and have had only one prime for n=66K-190K.

[QUOTE=MyDogBuster;231213]If we're looking for stuff to do, I'd like to get all the bases < 250 up to at least n=100K, excluding the high ck ones with loads of k's left. Put the cutoff point at something like 20k's remaining. Sieve them, load them and let 'er rip.

Any preference Mathew?[/QUOTE]

MyDogBuster, I like the idea.
Gary, is this a possibility?

[QUOTE=Mathew Steine;232254]MyDogBuster, I like the idea.
Gary, is this a possibility?[/QUOTE]

This drive was more intended for high-n searches. My original thought was one or both sides of base 16 but we really need to push R26 to n=500K and/or R31 to n=200K or 250K to bring them more in line with their neighbors that have similar #'s of k's remaining. R26 is fully sieved to optimal depth to n=500K. R31 would need sieving for n=150K-250K.

Also, Mark had suggested sieving all bases < 250 with one k remaining to see how many we can prove. We would probably do that for n=100K-250K.

I think we are going to need to take a poll because we have 3 distinct thoughts about what to do next for a team drive. I'm thinking we should keep this mini-drive intact and continue with high-n searches but we could have a 2nd drive going based on what Ian or Mark suggested.

A 4th possibility is to bring lowish bases with "kind of" a large # of k's remaining (perhaps 25-100 k's) to n=50K or 100K such as base 24. I think you had suggested that before.


Gary

[QUOTE]This drive was more intended for high-n searches. My original thought was one or both sides of base 16 but we really need to push R26 to n=500K and/or R31 to n=200K or 250K to bring them more in line with their neighbors that have similar #'s of k's remaining. R26 is fully sieved to optimal depth to n=500K. R31 would need sieving for n=150K-250K.

Also, Mark had suggested sieving all bases < 250 with one k remaining to see how many we can prove. We would probably do that for n=100K-250K.

I think we are going to need to take a poll because we have 3 distinct thoughts about what to do next for a team drive. I'm thinking we should keep this mini-drive intact and continue with high-n searches but we could have a 2nd drive going based on what Ian or Mark suggested.

A 4th possibility is to bring lowish bases with "kind of" a large # of k's remaining (perhaps 25-100 k's) to n=50K or 100K such as base 24. I think you had suggested that before.
[/QUOTE]I would be in favor of any drive that is working on getting bases to n=100K. I already have 5 cores (not including the 5 I have on R31) doing high-n searches and that is plenty for me. So I guess 1 drive for the high-n searches and 1 for the < n=100K searches. Everyone's covered.

It's also sad that that CUDA sieve doesn't handle bases other than 2. We could use a faster sieve for this stuff.

Would you guys be OK with extending Riesel base 31 to n=200K or 250K in this drive? As a higher-weight base, it has a good chance to attrition like R6 and get down to just 2-3 k's remaining at n=250K. I just started a sieve for n=150K-250K and could be done before the server here dries.

I'd like to leave this drive/server for various high-n searches on low bases, which would generally include those shown in the recommended thread. We can take a poll on the other 3 possibilities talked about earlier, which I'll set up on Mon. or Tues. if that sounds OK with you. We'll then start a sieving drive for it and set up another PRPnet drive/server for it.


Gary

[QUOTE]Would you guys be OK with extending Riesel base 31 to n=200K or 250K in this drive? [/QUOTE] Like I said earlier, 5 cores doing high n tests is enough for me. I'll find something else for the 5 cores on R31 to do.

[QUOTE=gd_barnes;232472]Would you guys be OK with extending Riesel base 31 to n=200K or 250K in this drive? As a higher-weight base, it has a good chance to attrition like R6 and get down to just 2-3 k's remaining at n=250K. I just started a sieve for n=150K-250K and could be done before the server here dries.

I'd like to leave this drive/server for various high-n searches on low bases, which would generally include those shown in the recommended thread. We can take a poll on the other 3 possibilities talked about earlier, which I'll set up on Mon. or Tues. if that sounds OK with you. We'll then start a sieving drive for it and set up another PRPnet drive/server for it.


Gary[/QUOTE]
Since we're planning to set up another server for the lower stuff anyway (the exact load being determined by the outcome of the poll), and will thus be keeping port 1300 on high-n stuff, we may as well keep cranking away with R31 since it's so ripe for more primes. (Besides, the numeric coincidence of R[b]31[/b]/[b]13[/b]00 is just too good to pass up. :wink:)

Actually, what might be a good idea is to set up [i]two[/i] additional servers, for a total of 3. Namely:
port 1100 for 1-k bases <250, n>=100K (Mark's idea)
port 1200 for bases <250 with low(ish) CK, n>=25K (Ian's idea)
port 1300 for high-n, close-to-proof conjectures (like R31)

This would give us some nice variety, at the risk of spreading ourselves a little thin.

[QUOTE=mdettweiler;232488]Since we're planning to set up another server for the lower stuff anyway (the exact load being determined by the outcome of the poll), and will thus be keeping port 1300 on high-n stuff, we may as well keep cranking away with R31 since it's so ripe for more primes. (Besides, the numeric coincidence of R[B]31[/B]/[B]13[/B]00 is just too good to pass up. :wink:)

Actually, what might be a good idea is to set up [I]two[/I] additional servers, for a total of 3. Namely:
port 1100 for 1-k bases <250, n>=100K (Mark's idea)
port 1200 for bases <250 with low(ish) CK, n>=25K (Ian's idea)
port 1300 for high-n, close-to-proof conjectures (like R31)

This would give us some nice variety, at the risk of spreading ourselves a little thin.[/QUOTE]


Not a bad idea but whew; a LOT to administer and yes, it would spread us thin; not only on resources but on admins too! We have [I]so many [/I]drives already. I simply do not want to adminster any more.

There's really a 50-50 split on what the decision for all of this should come down to:
1. What people want to do.
2. What the admins have time to administer.

Ian, since you're now an admin, would you be willing to set up and run a sieving drive for your idea of bases <=250 with ~2k-20k remaining to n=100K?

Max, would you be willing to admin Mark's idea by getting a sieving drive going for it?

I will continue administering this drive (although asking Max to load the server from time to time) and sieve necessary high n bases like I'm doing right now on R31. BTW, n=150K-250K for R31 should be done sieving in ~3 days. I'm estimating Thurs. or early Fri. on 5 cores of my I7 running to the optimum depth in the P=~12T area. I hope that will beat the drying of port 1300.

Both of you would need to commit to keeping the additional drives going. There will be optimal sieve depth calculations involved, which will be very important to get correct on the high n's involved in Mark's idea.

Are you guys up for it? If so, we don't need to take a poll.


Gary

[QUOTE]Ian, since you're now an admin, would you be willing to set up and run a sieving drive for your idea of bases <=250 with ~2k-20k remaining to n=100K?[/QUOTE]

I'm going to back off my idea. I have enough to do with my 1ker's and 2ker's to keep me busy for at least another 8 months. I agree with Max that it would spread us too thin. Let me see where we stand after I finish the 1 and 2ker's. Seems to me the high n searches and Mark's idea are basically the same thing.

[QUOTE=MyDogBuster;232561]I'm going to back off my idea. I have enough to do with my 1ker's and 2ker's to keep me busy for at least another 8 months. I agree with Max that it would spread us too thin. Let me see where we stand after I finish the 1 and 2ker's. Seems to me the high n searches and Mark's idea are basically the same thing.[/QUOTE]

Not exactly. The high n searches are for bases <= 32, although could be extended to slightly higher bases at some point -and- they are for bases with anywhere from 1 to ~10 k's remaining. Mark's idea is only to take 1kers for n=100K to ? so by default only includes bases searched to n=100K (or could include bases already searched to n=150K or 200K later on). Max and I decided on bases <= 250 for n=100K-250K to narrow down such an effort.

In other words, this drive is for "very tough" smallish bases to prove that were really part of the original project that only included bases <=32. They are ones that generally people with few resources would not want to work on because the tests take too long. For instance, after n=150K-250K for R31, I'd really like to push R26 (1k) for n=400K-500K or S30 (2k) for n=300K-400K.

I think it's great that you'll do all the 1kers and 2kers to n=100K yourself. Obviously there are a lot fewer 2kers than 1kers and your effort should make that even more in favor of the 1kers. Max and I (mostly Max) already did all 1k/2k/3k bases <= 250 to n=100K in preparation for Mark's idea. So you'll be solely working on bases > 250 in that effort.

BTW, your 1k effort is part of the reason that I've slowly worked my way up the bases with certain #'s of k's remaining at n=5K. I wanted to make sure you have a full set of bases that have 1k remaining at n=25K. I suspect that you do now because I'm working on the ones with 7 k's remaining at n=5K and no base is likely to prime 6 out of 7 remaining k's for n=5K-25K (although Mark did search one that primed 5 out of 6 k's for n=5K-25K and so now is a 1ker; so you never know).


Gary

[QUOTE=gd_barnes;232560]Max, would you be willing to admin Mark's idea by getting a sieving drive going for it?
...
Both of you would need to commit to keeping the additional drives going. There will be optimal sieve depth calculations involved, which will be very important to get correct on the high n's involved in Mark's idea.
[/QUOTE]
Hmm...I'll probably be kicking myself for this down the road but yeah, I'll do it. We've got to do it sooner or later and my non-prime-related life is probably not going to get any less busy any time soon so now's as good a time as any. :smile:

(It might be a couple of days before I can get the sieving drive thread posted...I'll be needing to compile a list of all the 1k bases <250 at n=100K and calculate optimal depths for at least a few of them to provide some starting material.)

[QUOTE]I think it's great that you'll do all the 1kers and 2kers to n=100K yourself. Obviously there are a lot fewer 2kers than 1kers and your effort should make that even more in favor of the 1kers. [/QUOTE]What's really interesting with the 1 and 2ker's is that the number of 2ker's is almost exactly half of the number of 1ker's. That makes the actual work almost even between the 2.

Max, I learned long ago NEVER to volunteer for anything. LOL

Like I stated earlier, it's too bad that CUDA sieve doesn't handle bases other than 2. Sure would make your chore easier.

Reserving n=150K-200K for port 1300. Max has been sent the file to load into the server. This will now include k=6962, which had previously been searched to n=150K, for a total of 5 k's.

Guys, I've sieved R31 for n=150K-250K to P=11T, the optimum depth for the entire range. If the interest is still there when we reach n=200K, we'll load in n=200K-250K. If there is little interest beyond n=150K, I'll start on it after I finish base 28 to n=250K in about 1-1/2 months.


Gary

Moved discussion about bases 101-250 with 2 to 20 k's remaining to the bases 101-250 thread.

Results have been processed for R31, n=120.2K-150K and are attached here. Two primes were found in this range.

Max,

Please load n=200K-250K into the server. Thanks.

[QUOTE=gd_barnes;242859]Max,

Please load n=200K-250K into the server. Thanks.[/QUOTE]
Done.