PRP discussion thread

[philmoore]

Use this thread for issues concerning probable prime testing. The other thread is for information and reservations only.

[em99010pepe]

How do I run PRP with LLR?

[TimSorbet]

Originally Posted by em99010pepe

How do I run PRP with LLR?

The exact same way as an LLR test, but with a base that's not 2 (or a power of 2).

[em99010pepe]

Originally Posted by Mini-Geek

The exact same way as an LLR test, but with a base that's not 2 (or a power of 2).

What changes do I have to make on the input file (just curious)?
(Meanwhile I already managed to test Prime95)

[TimSorbet]

Originally Posted by em99010pepe

What changes do I have to make on the input file (just curious)?
(Meanwhile I already managed to test Prime95)

No specific changes, just that a base has to be specified besides 2.
e.g. (base bold)

175000000000:P:1:3:257
31001156 86001
39809884 86001
44249222 86001
8603464 86002
31881438 86003
33666398 86003
40499588 86003
47214478 86003
20305126 86004
21497746 86004
7111766 86005
30440162 86005
25521872 86006

[mdettweiler]

Originally Posted by em99010pepe

How do I run PRP with LLR?

Since these candidates aren't in a traditional k*b^n+-1 format, you'd need to use ABC format in an LLR input file instead of NewPGen format. Like this:

ABC 1*2^$a-$b
1400008 40291
1400087 28433
1400104 40291

(generated using the Prime95 worktodo.txt lines from the PRP Testing thread as a basis--somebody correct me if my above example is in error)

Probably an easier way, though, would be to just run them with Prime95/mprime v25 as Phil suggests. As far as I know, Prime95/mprime v25 uses the same underlying PRP code as LLR, so the speed should be the same. Unfortunately, there's probably no way to run these through LLRnet at this time, since LLRnet only deals in traditional pairs of k/n values as used in NewPGen format files.

Max

[philmoore]

Prime95 uses base 3 for PRP tests, so if you use LLR, be sure to use the same base. You could try testing 2^1399919+75353 just to check that LLR and Prime95 are reporting the same residues.

[mdettweiler]

Originally Posted by philmoore

Prime95 uses base 3 for PRP tests, so if you use LLR, be sure to use the same base. You could try testing 2^1399919+75353 just to check that LLR and Prime95 are reporting the same residues.

I think what Mini-Geek meant by base was the value of b in k*b^n+-c; not to be confused with PRP base (and as for that, I know for a fact that LLR uses PRP base 3, and in fact that can't even be changed in the settings). As far as I know, there is no difference in the core PRP code of LLR versus that of Prime95 v25, so they should produce compatible residuals (albeit in slightly differently-formatted output files; however, a simple Perl or bash script would probably be able to convert one to the other quite easily).

[mdettweiler]

Originally Posted by philmoore

... and at that value of n, I am finding that each PRP test takes about 2 hours on one processor of my 3000 MHz Pentium D machine. I will split the range from 1.4 million to 2.1 million up into ranges of 10,000. Each range has about 160 candidates, so it would take about 2 weeks on a single processor of my Pentium D, or 1 week if I split it between two processors. I assume that a Core 2 Duo would of course be a little faster.

Hi all,

I've noticed that in my 1.41M-1.42M range, the tests are taking almost exactly 2 hours apiece, on one core a Core 2 Duo E4500 (2.2Ghz). Does anyone have any ideas why they're taking this long, despite the fact that numbers of about that size took exactly that same amount of time on Phil's Pentium D (a definitely slower CPU than mine)? Was there a massive FFT length change right before my range, or something like that?

Thanks,
Max

P.S.: Would this go better in the PRP Discussion thread? If so, please feel free to move it.

[philmoore]

I think that my last tests were at 160k FFT size, is that what your tests are at?

[mdettweiler]

Originally Posted by philmoore

I think that my last tests were at 160k FFT size, is that what your tests are at?

Yep, 160K. That rules out the possibility of an FFT jump--any other ideas as to what could be causing this?

Maybe my CPU's just getting clogged with dust and it's running slowly because of that? (Then again, I have a little gadget on my taskbar that reads out the current CPU frequency for each core, and they're both already manually set to 2.20Ghz, which is confirmed by the gadget's readout.)