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

[kruoli]

Thanks, I must have missed that.

[kar_bon]

There's also a page at the PrimeWiki which will be updated if all results available.
There's a table with users and date (downloadable as CSV) and a graph of found primes.
Over 200 entries for Riesel k-values are also available for more information about that k-val.

[MooMoo2]

Originally Posted by kruoli

It looks like all 480k-500k candidates are now done. (Only two are reserved by one of my machines, but they are already done and are waiting for being submitted). The new candidates are being handed out successfully.

Does someone create a Web Archive of the found primes on some way or another?

Yes, there were a total of 1227 primes found for n=480K-500K.
1,188 of them were on PRPNet:
https://web.archive.org/web/20230206...imes_12000.txt
and 39 of them were on LLRNet:
https://web.archive.org/web/20220108...imes_12050.txt

13,561 tests for n=480K-500K were done since the last stats archive (https://web.archive.org/web/20230205...12000/all.html) on 2023-02-05 18:13:30 GMT / 12:13:30 server time. They're attached for reference, and the distribution of those tests is as follows:

kruoli 		7602 tests
odicin 		4909 tests
MooMoo2 	746 tests
whengryphonsfly	303 tests
gd_barnes 	1 test

I'll doublecheck all of the primes, will verify that they aren't twin, and will post a final combined version of the 480K-500K stats within a few days for individuals and teams. There were a total of 6,337,433 tests completed:
- 6,161,082 on PRPNet (6147521 tests at the time of the Wayback Machine archive and 13561 tests afterwards)
- 173,299 on LLRNet (https://www.mersenneforum.org/showpo...7&postcount=13)
- 3,052 as manual reservations (https://www.mersenneforum.org/showthread.php?t=13387)

[The Carnivore]

Originally Posted by gd_barnes

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 again, but this recent news is a bit concerning:
https://www.mersenneforum.org/showpo...&postcount=307
https://www.mersenneforum.org/showpo...&postcount=310

Is that something that affects TPS, or is the issue only limited to CRUS?

[Happy5214]

Originally Posted by The Carnivore

Thanks again, but this recent news is a bit concerning:
https://www.mersenneforum.org/showpo...&postcount=307
https://www.mersenneforum.org/showpo...&postcount=310

Is that something that affects TPS, or is the issue only limited to CRUS?

This issue doesn't affect LLR when it's used with PRPNet, as PRPNet generates the input files used by the LLR executable in ABC format, while this issue only affects the NewPGen input format. Furthermore, PRPNet directly parses the lresults.txt log file, not the output primes text file. The bigger concern, at least for any future double-checking, is that LLR versions starting with 3.8.24 generate Fermat PRP residues by default for non-prime Riesel candidates (instead of LLR residues), which are incompatible with previous versions.