[QUOTE=VictordeHolland;474450]So once everybody upgrades their software will the (new) PRP test be the standard for checking primality of mersenne candidates (instead of LL?).[/quote]

Undecided.

[quote] Or will they coexist?[/QUOTE]

Definitely coexist. Upgrading takes a long, long time. There are still decade old installs of version 24 reporting in.

[QUOTE=Prime95;474456]Undecided.
[/QUOTE]

Why undecided? is there some advantage of LL over PRP, or some drawback of PRP?

[QUOTE=preda;474602]Why undecided? is there some advantage of LL over PRP, or some drawback of PRP?[/QUOTE]

No good reason, haven't even thought about it (other than recommending those doing 100M digit tests do PRP).

I'll wait a good long while to see how well the server handles managing PRP and LL assignments before I ponder changing the default behavior to PRP. It will take a good long while for a significant percentage of clients to upgrade to version 29.4 or later.

The good news is that if and when we make the decision to change to PRP, then it is a simple server side change for all v29.4 and later clients to start PRPing with their next assignment.

George, are you going to get enough double-checked PRP results in the next few months to constitute a statistically meaningful sample for comparing final-result error rates between the following 3 options?

1. LL only
2. LL with Jacobi check
3. PRP with Gerbicz check

If that is not being done already, I suggest organizing a bunch of 1st-time-test PRP work accompanied by early PRP-based DCing. The error rate is the key metric as to whether switching to [3] is desirable going forward.

[QUOTE=ewmayer;474627]George, are you going to get enough double-checked PRP results in the next few months to constitute a statistically meaningful sample for comparing final-result error rates between the following 3 options?

1. LL only
2. LL with Jacobi check
3. PRP with Gerbicz check

If that is not being done already, I suggest organizing a bunch of 1st-time-test PRP work accompanied by early PRP-based DCing. The error rate is the key metric as to whether switching to [3] is desirable going forward.[/QUOTE]

There are a few double-checked PRP results already. I think the reliability so far is perfect (no errors). But the problem with PRP is not accidental errors, but intentional false results, and a statistical analysis is not very helpful there.

"Manual assignments" web page now has a full set of PRP choice. (thanks!)

[QUOTE=preda;476340]"Manual assignments" web page now has a full set of PRP choice. (thanks!)[/QUOTE]

Now waiting for this: [url]https://www.mersenne.org/report_top_500_custom/[/url] :rolleyes:

[QUOTE=ET_;476362]Now waiting for this: [url]https://www.mersenne.org/report_top_500_custom/[/url] :rolleyes:[/QUOTE]

Ugh... that page is so hard to work with.

By the way, I do have a mocked up version of that page that uses an HTML table instead of the funky pre-formatted text (that never seems to line up quite right):
[URL="https://www.mersenne.org/report_top_500_custom/default.mock.php"]https://www.mersenne.org/report_top_500_custom/default.mock.php[/URL]

At least with that, if I add PRP info it's just another table column and doesn't involve a much more complicated (by far) dive into how it generates that preformatted text.

[QUOTE=Madpoo;476404]Ugh... that page is so hard to work with.

By the way, I do have a mocked up version of that page that uses an HTML table instead of the funky pre-formatted text (that never seems to line up quite right):
[URL="https://www.mersenne.org/report_top_500_custom/default.mock.php"]https://www.mersenne.org/report_top_500_custom/default.mock.php[/URL]

At least with that, if I add PRP info it's just another table column and doesn't involve a much more complicated (by far) dive into how it generates that preformatted text.[/QUOTE]

That would work fine for me, if the width of the table are suffices...
I would live without it, but as you are reworking the project... :smile:

[QUOTE=Siegmund;474404]If we're talking about adding it to the publicly-visible portion of the website...

Job #1 is going to be explaining to the world what the PRP test is and how it works and why it should be part of GIMPS.

It's not clear to me that PRP is ever going to move into the spotlight - in much the same way that the whole GPU factoring effort goes on behind the scenes. Pages like [URL]https://www.mersenne.org/manual_gpu_assignment/[/URL] exist and aren't hidden behind a password, but are not linked to any of the public-facing pages.

Heck, I am not sure *I* understand how PRP fits into the bigger picture, despite trying to keep tabs on this forum.[/QUOTE]

GPU assignment page returns
Error code: 40 Error text: No assignment available for GPU trial factoring

cpu yes, but consider gpu
 

[QUOTE=Prime95;474616]No good reason, haven't even thought about it (other than recommending those doing 100M digit tests do PRP).

I'll wait a good long while to see how well the server handles managing PRP and LL assignments before I ponder changing the default behavior to PRP. It will take a good long while for a significant percentage of clients to upgrade to version 29.4 or later.

The good news is that if and when we make the decision to change to PRP, then it is a simple server side change for all v29.4 and later clients to start PRPing with their next assignment.[/QUOTE]

On the gpu side, changing from LL to PRP means a different application with a different way of doing things.

I'm expecting gpuOwLPRP to replace cllLucas LL for AMD gpu primality testing. My admittedly limited testing thus far indicates a sizable speed advantage; ETA <11 days for 78M PRP on gpuOwL V1.9, vs. over 13.5 days for a 62.8M DC with clLucas 1.04, which scales to about 2:1 speed advantage, on the same GPU model.

I wonder what the cpu-gpu throughput mix is for the GIMPS project overall.

If Mihai were to port GpuOwL to CUDA, I'd like to be among the first to test it.