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

[MooMoo2]

The current record for both twin primes and Sophie Germain primes is 388,342 digits, found by PrimeGrid at n=1.29M. PG is planning on continuing with n=1.29M until the end of the file, which is at k=10^13 (10T) and should take several more years to complete.

PG's n=1.29M was triple-sieved instead of quad-sieved, which meant that if k*2^1290000-1 were prime, only two other numbers would be checked - k*2^1290000+1 (for twins) and k*2^1290001-1 (for sophies). k*2^1289999-1 would not be checked for sophies by PG but would be checked by a quad-sieve, so PG could potentially have found two sophies by now instead of just one.

Based on the reported 14,362 tasks per prime (https://www.primegrid.com/forum_thread.php?id=9837), the n=1.29M file was sieved to around p=1500T. Their odds of finding a significant prime pair is approximately 1 in 103 million per candidate (14362*14362/2). However, if they did a quad sieve instead, they could have had better odds even if they only sieved to p=3T (17480*17480/3 = 1 in 102 million per candidate).

What's past is past, but moving forward, I was wondering whether there's any interest in going for a new record at n=1.7M with quad-sieved candidates. This is just below the FFT length change at n=1.709M and is a bit over half a million digits, so it would be a good place to start. Those who're feeling really ambitious (and lucky!) can search for candidates at n=3.322M, which would potentially produce million-digit twins and sophies. The good news is that primes that aren't twin or SG would still make the top 5000 list. The FFT length changeover is close to n=3.373M, so n=3.322M would be a great fit.

I've done some quad sieving on both n=1700000 and n=3322000 and run a few sample tests. On a Core i7 7700K, an n=1.7M test takes about 15 minutes to complete on one core, while an n=3.322M test takes about an hour to finish. Quad sieves do require large k values to get enough candidates, but this isn't a major concern since the LLR testing slowdown occurs at over 750T for n=1.7M and n=3.322M. 7,358,505*2^1700000-1 and 750,000,097,517,855*2^1700000-1 both take roughly the same amount of time to test, though 760,000,097,517,875*2^1700000-1 takes much longer.

For n=1.7M, we should statistically expect either a twin or a sophie before hitting the k=750T slowdown limit. While this wouldn't be the case for n=3.322M, we can always move to n=3322001, n=3322002, etc. after finishing n=3322000 to k=750T. This wouldn't be a huge range like TPS's current n=480K-500K search; a dozen or so n's should be enough.

Thoughts and feedback are greatly appreciated If there's enough interest, I'll send the files to Gary and see if he can post them on http://www.noprimeleftbehind.net/tps/ on two different ports, one for n=1.7M and one for n=3.322M. I'm also open to collaborating with PrimeGrid on those tests once they're done with n=1.29M.

[gd_barnes]

Originally Posted by MooMoo2

Thoughts and feedback are greatly appreciated If there's enough interest, I'll send the files to Gary and see if he can post them on http://www.noprimeleftbehind.net/tps/ on two different ports, one for n=1.7M and one for n=3.322M. I'm also open to collaborating with PrimeGrid on those tests once they're done with n=1.29M.

There are no more public servers available on my end.

There has been little interest in the n=480K-500K TPS here.

I think this is best left for BOINC efforts.

[MooMoo2]

Originally Posted by gd_barnes

There are no more public servers available on my end.

There has been little interest in the n=480K-500K TPS here.

I think this is best left for BOINC efforts.

Thanks for the info. Is there any possibility that either port 12050 or port 13000 could be revived and loaded with those candidates? IIRC, we've previously used them for other TPS efforts, so I'm not sure whether they'd be counted as new servers.

I do agree that there hasn't been much interest in n=480K-500K (even so, 10 primes in that range have been found this month), but I think that's because of the following:
- no possibility of finding a record-breaking twin
- primes that are not twin are too small for the top 5000 list
- no possibility of finding any sophies
- incompatibility with new PRPNet versions (see https://www.mersenneforum.org/showpo...&postcount=234)
- much of the initial appeal of that range was that the low-k values would be faster to test. However, the really low-k values (k<200K) where this effect was most dramatic have all been tested many years ago.

Aside from the PRPNet version incompatibility, most of those issues wouldn't really apply to the quad-sieved n=1.7M and n=3.322M candidates. If it's not possible to revive port 12050 or 13000, a possible option would be to suspend the less-popular n=480K-500K range on port 12000 and replace it with either n=1.7M or n=3.322M on that same port.

I also agree that the bulk of the effort is best left to BOINC, but in the meantime, I don't see any harm in getting started with n=1.7M and/or n=3.322M now since it'll still be several years until PrimeGrid's n=1.29M file is complete. By that time, n=3.322M primes may not be large enough to be on the top 5000 list.

[gd_barnes]

The server machine is mostly maxed out on its capacity. I dropped port 13000 for the n=1M twin effort a while back after an extended period of no activity. I don't wish to add it back or any more servers at this point.

If you would like to finish the n=480K-500K twin effort on port 12000 up to k=920K, I will then save off the residues and primes and clear out that server. I can then load a sieve file into it for the n=1.7M twin effort.

The old PRPnet server that is being used for this is somewhat of a disservice to the community forcing people to run a slightly slower LLR. This is better hosted by others or BOINC.

Note that n=1.7M will not make it into top-5000 now.

[The Carnivore]

Originally Posted by gd_barnes

If you would like to finish the n=480K-500K twin effort on port 12000 up to k=920K, I will then save off the residues and primes and clear out that server. I can then load a sieve file into it for the n=1.7M twin effort.

Note that n=1.7M will not make it into top-5000 now.

I'm busy with other projects and probably won't be contributing, but if I had the spare cycles, I'd prefer to work on n=3.322M than on n=1.7M.

[gd_barnes]

I have good news and bad news.

Bad news: When I attempted to add a new PRPnet server to the server machine, I inadvertently wiped out the SQL tables for prpnet port 12000. That means the server stats are lost.

Good news: Due to the corruption, I dropped the database and created a new one with newer PRPnet version 5.3.2. This means that everyone can now use later versions of LLR for TPS likely resulting in a 10% speedup or greater in testing.

No results/residues/primes files were lost as those are automatically saved off in flat files every 15 mins. This means that I could easily see exactly where we left off at (k=909219) and so it was easy to reload the server with candidates up to k=920000 like we had before.

I ran two tests myself on the new server and it worked fine.

You will need to use a more up-to-date prpclient.ini file than what was used for PRPnet version 4.1.4. I have attached one. You'll need to update the email, userid, machineid, instanceid, and teamid. Instanceid is a change after version 4.1.4. It allows for identification of a specific core/thread on a single machine.

This came about because I am looking into adding 2 additional PRPnet servers: One here for TPS and one for NPLB in the future. The server machine appears to be more robust than I had previously thought when I said it was mostly maxed out.

With a better PRPnet server allowing for the execution of more modern LLR, perhaps it will increase interest here.

[MooMoo2]

Originally Posted by gd_barnes

I have good news and bad news.

Bad news: When I attempted to add a new PRPnet server to the server machine, I inadvertently wiped out the SQL tables for prpnet port 12000. That means the server stats are lost.

Good news: Due to the corruption, I dropped the database and created a new one with newer PRPnet version 5.3.2. This means that everyone can now use later versions of LLR for TPS likely resulting in a 10% speedup or greater in testing.

No results/residues/primes files were lost as those are automatically saved off in flat files every 15 mins. This means that I could easily see exactly where we left off at (k=909219) and so it was easy to reload the server with candidates up to k=920000 like we had before.

I ran two tests myself on the new server and it worked fine.

You will need to use a more up-to-date prpclient.ini file than what was used for PRPnet version 4.1.4. I have attached one. You'll need to update the email, userid, machineid, instanceid, and teamid. Instanceid is a change after version 4.1.4. It allows for identification of a specific core/thread on a single machine.

This came about because I am looking into adding 2 additional PRPnet servers: One here for TPS and one for NPLB in the future. The server machine appears to be more robust than I had previously thought when I said it was mostly maxed out.

With a better PRPnet server allowing for the execution of more modern LLR, perhaps it will increase interest here.

Thanks, Gary! I've created a poll to determine which candidates we should test once we finish the n=480K-500K candidates to k=920000:
https://www.mersenneforum.org/showthread.php?t=28373

[whengryphonsfly]

Originally Posted by gd_barnes

Bad news: When I attempted to add a new PRPnet server to the server machine, I inadvertently wiped out the SQL tables for prpnet port 12000. That means the server stats are lost.

If there's any desire to rebuild the tables, archive.org has a copy of the server stats page from only a week ago: https://web.archive.org/web/20221227...12000/all.html

[MooMoo2]

Originally Posted by gd_barnes

I ran two tests myself on the new server and it worked fine.

I also tested it and confirmed that it works

[Bottom Quark]

Originally Posted by MooMoo2

I do agree that there hasn't been much interest in n=480K-500K

- much of the initial appeal of that range was that the low-k values would be faster to test. However, the really low-k values (k<200K) where this effect was most dramatic have all been tested many years ago.

At this point, there is zero advantage to testing low k values in terms of speed:

909225*2^481051-1 is not prime. LLR Res64: 15FBDA81DBD509AD Time : 74.216 sec.
10000000112535*2^481051-1 is not prime. LLR Res64: C6EB4655D7C4B8FF Time : 73.988 sec.

[MooMoo2]

Originally Posted by whengryphonsfly

If there's any desire to rebuild the tables, archive.org has a copy of the server stats page from only a week ago: https://web.archive.org/web/20221227...12000/all.html

It appears that when the page was archived, the only outstanding candidate was 906063*2^490562-1:

Candidate		User		Client	Team	Date Assigned			Age (hh:mm)
906063*2^490562-1	whengryphonsfly	alpha05		Tue Dec 27 01:52:27 2022	9:35

Based on the 9 hour, 35 minute age of that test, the page was likely archived on Tue December 27 11:27:27 (server time)
The 906063*2^490562-1 test was returned on December 27, 20:18:02:

user=whengryphonsfly
[2022-12-27 20:18:02]
906063*2^490562-1 is not prime.  Res64: FB745BD8E481399A  Time : 0.0 sec.

I looked up the files at: http://www.noprimeleftbehind.net/tps/results/llrnet/ and saw that you submitted 17,870 tests and found 3 primes between 2022-12-27 20:18:02 and when the stats page went down early on 2023-01-03. There were no tests completed by any other users. If we were to use 2022-12-27 11:27:28 instead of 2022-12-27 20:18:02, the number goes up by 1,954 to 19,824 (all completed by you).

The 19,824 additional tests with 3 additional primes is a reasonable assumption. Your totals would then be 89,134 tests with 21 primes found, and all other users would stay the same.