n=1.7M and n=3.322M Twin-Sophie record attempts

[gd_barnes]

Originally Posted by MooMoo2

The poll is tied at 5 votes for n=1.7M and 5 votes for n=3.322M. Assuming current trends hold, I'll upload the quad-sieved candidates in early February.

At that time, would you be able to load n=3.322M into port 12000 and n=1.7M into the new server? However, if only port 12000 will be available, please let me know, and I'll try and make a decision as to which n-value we should work on.

Tied? We can't have that. I voted and broke the tie. I'm not a fan of such large tests for twin efforts so n=1.7M is now in the lead. :-) Regardless clearly there's enough interest in both that it makes sense to have two efforts going.

The new server will be on our old port 13000. I dropped it like I did port 12000 and have since upgraded it to the newer PRPnet server. You can actually see the page for it although nothing is loaded right now. Here is the page: http://noprimeleftbehind.net:13000/all.html

Over the next few days, I will also update our main status page to show info for port 13000 here: http://www.noprimeleftbehind.net/tps/ . I had previously removed the info for port 13000 on it after the n=1M effort became defunct so it will be fairly easy to add the server and the new related info back to it.

I had in mind that port 12000 would have the n=1.7M candidates with port 13000 the n=3.322M candidates just for numerical consistency; higher server, higher candidates. Also older server smaller candidates. Is that OK or did you have a specific reason you'd like it to be the other way?

Should I blank out all the previously found primes and the individual/team stats from port 12000 before we begin the new efforts? I feel like we should. Perhaps you could copy them off or otherwise save them in some way before I do that.

A couple of weeks ago, I asked for and received admin access to this project although I haven't done anything admin-like so far since I've only had sporadic involvement in it. If you need me to edit or move or delete any posts, let me know. I'm sure Mike (Xyzzy) would also give you admin access also since you've been the guy running things here for quite a while. That would make sense if you would like to edit stats and primes posts instead of making new postings. Previously there were no admins for the project.

[MooMoo2]

Originally Posted by gd_barnes

Tied? We can't have that. I voted and broke the tie. I'm not a fan of such large tests for twin efforts so n=1.7M is now in the lead. :-) Regardless clearly there's enough interest in both that it makes sense to have two efforts going.

Hmmm....interesting. I have a very slight preference for testing n=3.322M since non-twin and non-sophie primes of that size will still be large enough to get onto the top 5000 list for the next few years. I guess I could make it a tie again by only voting for n=3.322M, but I also like n=1.7M since the odds of finding a twin or Sophie for that n are far more realistic. So I went ahead and voted for both options and let your tiebreaking vote stand

The new server will be on our old port 13000. I dropped it like I did port 12000 and have since upgraded it to the newer PRPnet server. You can actually see the page for it although nothing is loaded right now. Here is the page: http://noprimeleftbehind.net:13000/all.html

Over the next few days, I will also update our main status page to show info for port 13000 here: http://www.noprimeleftbehind.net/tps/ . I had previously removed the info for port 13000 on it after the n=1M effort became defunct so it will be fairly easy to add the server and the new related info back to it.

I had in mind that port 12000 would have the n=1.7M candidates with port 13000 the n=3.322M candidates just for numerical consistency; higher server, higher candidates. Also older server smaller candidates. Is that OK or did you have a specific reason you'd like it to be the other way?

Thanks! I originally thought that we'd use port 12000 for n=3.322M because port 12000 was the longest-used port, and we'll be testing n=3.322M for quite some time (decades?). But your reasons for loading n=1.7M into port 12000 and n=3.322M into port 13000 make more sense, so I'm fine with it.

Should I blank out all the previously found primes and the individual/team stats from port 12000 before we begin the new efforts? I feel like we should. Perhaps you could copy them off or otherwise save them in some way before I do that.

Agreed. Once we reach k=999999, I'll save a copy on the Wayback Machine and create a post here showing the stats and primes found.

A couple of weeks ago, I asked for and received admin access to this project although I haven't done anything admin-like so far since I've only had sporadic involvement in it. If you need me to edit or move or delete any posts, let me know. I'm sure Mike (Xyzzy) would also give you admin access also since you've been the guy running things here for quite a while. That would make sense if you would like to edit stats and primes posts instead of making new postings. Previously there were no admins for the project.

Good idea; I've just sent a PM to Mike requesting admin access. For now, the only admin actions I have in mind are to unstick (but not delete) the "Operation Megabit Twin" thread and the "List of megabit primes found" thread since the n=1M effort is no longer active. I'm not planning on editing any posts but will probably do so once the n=480K-500K range is complete.

[gd_barnes]

Originally Posted by MooMoo2

<snip>
Thanks! I originally thought that we'd use port 12000 for n=3.322M because port 12000 was the longest-used port, and we'll be testing n=3.322M for quite some time (decades?). But your reasons for loading n=1.7M into port 12000 and n=3.322M into port 13000 make more sense, so I'm fine with it.
<snip>

I figured that n=1.7M will be finished at some point and we will add something even bigger to port 12000 like n=5M, which will take even more decades. So port 12000 will be the last remaining server when I die. :-)

http://www.noprimeleftbehind.net/tps/ has been updated to include the new port/server. I ran some short tests through the new server to verify that both the port and that page were working correctly. I subsequently deleted all of the related results and stats.

[whengryphonsfly]

Question: how do we plan to test for twin primes and Sophie Germain primes at the same time? My understanding is that upon finding a prime, PRPNet can have the client automatically test for either a twin prime or both Sophie Germain primes, but not all three.

[The Carnivore]

Originally Posted by whengryphonsfly

Question: how do we plan to test for twin primes and Sophie Germain primes at the same time? My understanding is that upon finding a prime, PRPNet can have the client automatically test for either a twin prime or both Sophie Germain primes, but not all three.

You'll probably have to test it manually, just like the earlier n=1M search:
https://www.mersenneforum.org/showthread.php?t=16243

Originally Posted by odicin

66708604185*2^1000000-1 is prime!

Twin check:
66708604185*2^1000000+1 is not prime. LLR Res64: 94BB98BED224D61C Time: 3322 seconds

Manuel SG check:
66708604185*2^1000001-1 is not prime. LLR Res64: 566F61223CA0F769 Time: 2109.128 sec.
66708604185*2^999999-1 is not prime. LLR Res64: 2405E98D475668A3 Time: 1969.096 sec.

[Bottom Quark]

Originally Posted by whengryphonsfly

Question: how do we plan to test for twin primes and Sophie Germain primes at the same time? My understanding is that upon finding a prime, PRPNet can have the client automatically test for either a twin prime or both Sophie Germain primes, but not all three.

Originally Posted by The Carnivore

You'll probably have to test it manually, just like the earlier n=1M search:
https://www.mersenneforum.org/showthread.php?t=16243

If that is the case, it would be preferable to manually test the twins and let PRPNet automatically test the Sophie Germains. So if k*2^1700000-1 were prime, we'd only have to manually test one number (k*2^1700000+1) instead of two (k*2^1699999-1 and k*2^1700001-1).

[whengryphonsfly]

Originally Posted by The Carnivore

You'll probably have to test it manually, just like the earlier n=1M search:

So after this message I wondered how easy it would be to add a new server type that can do all three tests. I've spent some time with the source code, and I have something that compiles. Now, I don't know how to run a server*, so I can't test it, nor can I confirm that I actually found everything I needed to change (I may have missed some GFN stuff, for instance, and I still don't know what Candidate.cpp and PRPNetUpgrader.cpp need). What I can say is that it seemed quite easy to implement everything I knew needed to be changed, even as someone with minimal C++ experience. (AFAICT the client can already handle an arbitrary number of additional tests per work unit, while the server can handle up to 9 additional tests, and it could easily handle more just by editing a header file.)

So,

1. Is there interest in using a new combined twin / Sophie Germain prime server type over manual testing? (Given sufficient testing of course)
2. Is there interest from the maintainer (I believe it is rogue?) in implementing this?
3. There's about a week's worth of work left on the current search. If the answer to the above questions is "yes, there's interest on both fronts, but it would take more than a week to implement and test", how would we want to handle that?

I feel like maybe I'm being a little presumptuous, especially as I am a newcomer to the project, but I at least wanted to bring up that this seems feasible.

* I just discovered this (https://mersenneforum.org/showthread.php?t=26420) right before posting this. I'm about to head to bed, but I'll look into running a simple test tomorrow if I have time.

[gd_barnes]

I've done a lot of loading and configuring of PRPnet servers/clients so I know the general ins and outs of them. I could not change or compile any C, C+, C++, etc. code. I just recently learned how to upgrade the server to a newer version. There is an automated process for that so it did not require much technical knowledge.

Just today, I attempted to set up a test PRPnet server to run only Sophie Germains (SGs) due to the interest here in possibly having the server test for two SGs (instead of a twin) if it finds a prime. I've never attempted to set up a server to run SGs but from everything I could see and have read, it appeared no different than setting one up to run twins.

On the PRPnet server .ini file, I changed the option from 7 (twins) to 9 (SGs). From what I could tell, that is the only thing that needed to change. After that, I did a fairly quick sieve for n=176311 k<1M that has a known SG in the range (607095*2^176311-1). Finally, I used the usual PRPadmin tool to load the server with the file, which had 660 candidates remaining on a quick sieve to P=50G.

It did not work. I was getting duplicate message errors when trying to load the server. It would load one candidate and no others. So I tried a different tack.

I removed the one candidate from the server and attempted to load just the one candidate that is a SG. This appeared to load correctly. Thinking that it could only handle one candidate for some reason, I set a client to run it. That did not work. It could not find a candidate on the server. So something is clearly messed up.

At this point, I contacted Mark (rogue) who created everything related to PRPnet. He said he thought there was a bug in the server code and would need to work on it.

My thinking at this point: No one had ever attempted to run a PRPnet server for SGs before -or- there is something in my process messing things up. I'm leaning towards the former but can't say for sure.

I think we don't want to introduce any new code at this point. Let's see if Mark can get the existing code working correctly for SGs. I'll then do some extensive testing on it.

In the mean time, let's make sure we get off on the right foot and stick to having the server run twins. If Mark gets the code fixed and I'm convinced through extensive testing that it works correctly, then we can consider having it run SGs instead since the files are going to be quad sieved.

[Bottom Quark]

Originally Posted by whengryphonsfly

So after this message I wondered how easy it would be to add a new server type that can do all three tests. I've spent some time with the source code, and I have something that compiles. Now, I don't know how to run a server*, so I can't test it, nor can I confirm that I actually found everything I needed to change (I may have missed some GFN stuff, for instance, and I still don't know what Candidate.cpp and PRPNetUpgrader.cpp need). What I can say is that it seemed quite easy to implement everything I knew needed to be changed, even as someone with minimal C++ experience. (AFAICT the client can already handle an arbitrary number of additional tests per work unit, while the server can handle up to 9 additional tests, and it could easily handle more just by editing a header file.)

So,

1. Is there interest in using a new combined twin / Sophie Germain prime server type over manual testing? (Given sufficient testing of course)
2. Is there interest from the maintainer (I believe it is rogue?) in implementing this?
3. There's about a week's worth of work left on the current search. If the answer to the above questions is "yes, there's interest on both fronts, but it would take more than a week to implement and test", how would we want to handle that?

I feel like maybe I'm being a little presumptuous, especially as I am a newcomer to the project, but I at least wanted to bring up that this seems feasible.

* I just discovered this (https://mersenneforum.org/showthread.php?t=26420) right before posting this. I'm about to head to bed, but I'll look into running a simple test tomorrow if I have time.

I can't answer question 2 since I've never maintained a server, but I feel that creating a new combined twin / Sophie Germain prime server would be overkill for n=3.322M. Over the past few weeks, we've has been averaging a bit under 23,000 tests per day (and even this is a bit of an over-estimation). Since n=3.322M tests take ~46 times as long as n=480K-500K tests, we'd only be doing 500 tests per day. Dividing ~36000 tests/prime (obtained from https://www.primegrid.com/forum_thread.php?id=10092 ) by 500 tests per day yields an average of just five n=3.322M primes a year.

But for n=1.7M, it may make sense. At ~19000 tests/prime and ~2000 tests per day, we could potentially find one n=1.7M prime almost every week. Still somewhat uncommon, but it might be worth it, especially if there's a high interest in testing n=1.7M.

[whengryphonsfly]

Originally Posted by gd_barnes

Let's see if Mark can get the existing code working correctly for SGs. I'll then do some extensive testing on it.

In the mean time, let's make sure we get off on the right foot and stick to having the server run twins. If Mark gets the code fixed and I'm convinced through extensive testing that it works correctly, then we can consider having it run SGs instead since the files are going to be quad sieved.

Yeah, I'll admit I just assumed that both the twin prime server type and the Sophie Germain server type were bug-free, and all that needed to be done was combine the two. At this point I agree with pretty much everything you said.

Originally Posted by Bottom Quark

I can't answer question 2 since I've never maintained a server ... we could potentially find one n=1.7M prime almost every week.

Sorry, I should have specified I meant PRPNet's maintainer for #2. I was thinking gd_barnes's opinion fit under #1. As for one prime every week, I know that I personally may forget to do manual tests if I get a prime, which I suppose is my underlying rationale for this whole thing.

[MooMoo2]

Originally Posted by gd_barnes

I contacted Mark (rogue) who created everything related to PRPnet. He said he thought there was a bug in the server code and would need to work on it.

My thinking at this point: No one had ever attempted to run a PRPnet server for SGs before -or- there is something in my process messing things up. I'm leaning towards the former but can't say for sure.

I think we don't want to introduce any new code at this point. Let's see if Mark can get the existing code working correctly for SGs. I'll then do some extensive testing on it.

In the mean time, let's make sure we get off on the right foot and stick to having the server run twins. If Mark gets the code fixed and I'm convinced through extensive testing that it works correctly, then we can consider having it run SGs instead since the files are going to be quad sieved.

Originally Posted by whengryphonsfly

I personally may forget to do manual tests if I get a prime, which I suppose is my underlying rationale for this whole thing.

Yeah, we'll stick to having the server run twins and not SGs. I'll run the manual tests for SGs if the discoverer doesn't do them within a few days (if an SG is found, the discoverer will get credit for them regardless of who does the manual tests).