LLR 3.8.2: more flexible stop-on-prime option

[rogue]

Originally Posted by KEP

Well I didn't know that. But since I've no 64-bit machines, there really is no difference. However what seems to be a timesaving feature in LLR, is that a PRP is automatically verified as prime, if the GCD's end up stating that the PRP is in fact co-prime to something (something makes out for the part of the proof that I can not remember currently). Anyway, since LLR automatically verifies a PRP as prime in a few seconds, then no verification is later needed, hence in most cases 1 test or more is saved. On S58, it appears that the speed advantage is about 15-20+ % on my Q6600. So unless another alternativ that makes PFGW or other programs more effective and userfriendly than LLR, I'll most likely use LLR for next months until S58 completes to n=125K.

15-20%? On each test? PFGW 3.4 vs LLR 3.8.2?

Since you split up your work across multiple CPUs, PRPNet could save you a lot of time. In PRPNet 4.0, you will able to tell it to force clients to use LLR for non-base 2 work (if LLR is available).

Actually I forgot to mention that the next release of PRPNet will be 4.0, not 3.4 as I had stated elsewhere. The changes are significant to both client and server. 3.3 clients can communicate with 4.0 servers and 4.0 clients can communicate with 3.3 servers.

[KEP]

Originally Posted by rogue

15-20%? On each test? PFGW 3.4 vs LLR 3.8.2?

Since you split up your work across multiple CPUs, PRPNet could save you a lot of time. In PRPNet 4.0, you will able to tell it to force clients to use LLR for non-base 2 work (if LLR is available).

Actually I forgot to mention that the next release of PRPNet will be 4.0, not 3.4 as I had stated elsewhere. The changes are significant to both client and server. 3.3 clients can communicate with 4.0 servers and 4.0 clients can communicate with 3.3 servers.

The speeddifference would be for version 3.3.6 and prior, compared to LLR 3.8.2, I actually never got the PRPnet setup to work, and since I'm only using 4 cores to test S58 and 2 cores to test S60, there will most likely not be saved much time, if any at all, since I now have made all 4 input files for LLR to run on the Quad and both input files for LLR to run on the Dual core. If/when a Top5000 prime is found, I'll remember to mention PFGW in the provercode, since most of the n<=65K for S58 and for 12 k's on S58 n<=125K work was done using PFGW. So it is only fair, even if LLR is going to do the remaining work.

Hope I got it all mentioned, else ask again

Take care

Kenneth!

[rogue]

Originally Posted by KEP

The speeddifference would be for version 3.3.6 and prior, compared to LLR 3.8.2, I actually never got the PRPnet setup to work, and since I'm only using 4 cores to test S58 and 2 cores to test S60.

You can only save yourself time if splitting by k instead of n.

Anyways, PRPNet is really easy to set up, so if you have problems, let me know and I'll walk you through getting it going. Trust me that it is easier to monitor the PRPNet server via the web (and to have e-mails notify you of primes) than to monitor multiple copies of LLR/PFGW, especially if they are on multiple machines. The great thing is that if you fear running dry, you can dump more candidates into the server without touching any of the clients. Any hassling you do to start/stop LLR/PFGW while changing input files would go away.

[mdettweiler]

Originally Posted by rogue

You can only save yourself time if splitting by k instead of n.

Anyways, PRPNet is really easy to set up, so if you have problems, let me know and I'll walk you through getting it going. Trust me that it is easier to monitor the PRPNet server via the web (and to have e-mails notify you of primes) than to monitor multiple copies of LLR/PFGW, especially if they are on multiple machines. The great thing is that if you fear running dry, you can dump more candidates into the server without touching any of the clients. Any hassling you do to start/stop LLR/PFGW while changing input files would go away.

@KEP: Also, as you may recall I have an open offer to host a private PRPnet server on the noprimeleftbehind.net equipment for anyone who's interested. If your machines are internet-connected, this may be somewhat simpler than setting up your own PRPnet server.

[KEP]

Originally Posted by mdettweiler

@KEP: Also, as you may recall I have an open offer to host a private PRPnet server on the noprimeleftbehind.net equipment for anyone who's interested. If your machines are internet-connected, this may be somewhat simpler than setting up your own PRPnet server.

It is simpler, but only problem is that my Quad core is not internetconnected, and as soon as the Dual core completes the S60 work, I'll most likely retire the Dual core, since it is getting more and more outdated, so your offer regarding a PRPnet server, can not be taken up by me, even though its a nice offer from you. In case you all wonder why, my Quad is not internetconnected, it is a matter of finances. If I decide to put my Quad behind an internet connection, I have to pay a sort of tv fee to the public national tv station, plus I has to pay for cable and internet in addition to that. That would total around 200 USD each month or the same as it would cost to have at least 1 extra quad running.

@ Rogue: In case you havent understood what I meant, there is sometimes a timesaving when a prime is found, because LLR can with the use of GCD's tell if the prime is a strong PRP (however N is divided by a) therefor PRP can only be determined, but in most cases, LLR in less than a second determines weather or not a PRP is in fact prime. In the cases where a divide N-/+1, LLR typically do a second test. It is my experience (and that may have changed) that PFGW in most cases has to do a PRP test, and then at least 1 Full N-1 or N+1 test. When tests are growing bigger and bigger, more and more time will have to be used per test, and since LLR typically in short time tells weather or not the PRP in fact is prime, only a little more time than 1 full test has to be needed, to verify the k*b^n+c test as prime. Hence at least 1 test is saved. That was what I meant by timesaving.

But thanks for your offer to help me, however for now I think that I'll stick to the solution that I has for now, in stead of hazzeling with setting up a PRPnet system. Btw. LLR remembers the primed k's even if it has to be stopped during testing, is it not possible to add the same feature to PFGW? It would really save a lot of changing of input files, and then loose a lot of time on doing manual editing of the workfiles.

Kenneth

[rogue]

Originally Posted by KEP

It is simpler, but only problem is that my Quad core is not internetconnected, and as soon as the Dual core completes the S60 work, I'll most likely retire the Dual core, since it is getting more and more outdated, so your offer regarding a PRPnet server, can not be taken up by me, even though its a nice offer from you. In case you all wonder why, my Quad is not internetconnected, it is a matter of finances. If I decide to put my Quad behind an internet connection, I have to pay a sort of tv fee to the public national tv station, plus I has to pay for cable and internet in addition to that. That would total around 200 USD each month or the same as it would cost to have at least 1 extra quad running.

You don't need internet for PRPNet. You can use a cross-over cable to connect two computers. For a single computer with multiple cores, the server is just another process that takes very little CPU. The clients connect by specifying "localhost" as the server name in their respective ini files.

Originally Posted by KEP

@ Rogue: In case you havent understood what I meant, there is sometimes a timesaving when a prime is found, because LLR can with the use of GCD's tell if the prime is a strong PRP (however N is divided by a) therefor PRP can only be determined, but in most cases, LLR in less than a second determines weather or not a PRP is in fact prime. In the cases where a divide N-/+1, LLR typically do a second test. It is my experience (and that may have changed) that PFGW in most cases has to do a PRP test, and then at least 1 Full N-1 or N+1 test. When tests are growing bigger and bigger, more and more time will have to be used per test, and since LLR typically in short time tells weather or not the PRP in fact is prime, only a little more time than 1 full test has to be needed, to verify the k*b^n+c test as prime. Hence at least 1 test is saved. That was what I meant by timesaving.

I understood what you meant, which is why PRPNet 4.0 can tell the client (via the server) to use LLR instead of PFGW. If LLR returns "PRIME" on a PRP test, then no additional test will be done by the client.

Originally Posted by KEP

Btw. LLR remembers the primed k's even if it has to be stopped during testing, is it not possible to add the same feature to PFGW? It would really save a lot of changing of input files, and then loose a lot of time on doing manual editing of the workfiles.

I have considered such a change, but haven't thought very much about how to do it. I could either do it like LLR or I could have PFGW read the pfgw.log file for PRPs and then eliminate values that way. I think I like the LLR method better.

[KEP]

Originally Posted by rogue

You don't need internet for PRPNet. You can use a cross-over cable to connect two computers. For a single computer with multiple cores, the server is just another process that takes very little CPU. The clients connect by specifying "localhost" as the server name in their respective ini files.

OK, that answer at least solved one of my problems, but I still might need some help on the building of the database. However I'm not going to be able to look further into it untill maybe sunday, but I think that I'll give it a retry and then ask you or Max, for a solution whenever a problem occurs. Thanks for your reply.

Take care

Kenneth

[rogue]

Originally Posted by KEP

OK, that answer at least solved one of my problems, but I still might need some help on the building of the database. However I'm not going to be able to look further into it untill maybe sunday, but I think that I'll give it a retry and then ask you or Max, for a solution whenever a problem occurs. Thanks for your reply.

server/readme.txt tells you how to set it up, which is this:

• If necessary d/l MySQL from http://www.mysql.com and install it.
• Create a new database using the mysqladmin tool.
• Connect to your new database.
• Create the PRPNet tables using the create_tables.sql script found in the source directory.
• Load the database with an ABC file via the prpadmin tool.

On the client side you will need the MySQL ODBC driver, which is easy to install.

[mdettweiler]

Originally Posted by rogue

On the client side you will need the MySQL ODBC driver, which is easy to install.

To clarify further: this is for the PRPnet server to connect to MySQL as a client. You do not need the ODBC driver on machines running only the PRPnet client.

[rogue]

Originally Posted by mdettweiler

To clarify further: this is for the PRPnet server to connect to MySQL as a client. You do not need the ODBC driver on machines running only the PRPnet client.

Oops. Yes, you are correct. I've installed PRPNet on Windows and Mac OS X without problems. PrimeGrid runs PRPNet on Linux without problems.

[KEP]

Thanks for the info Rogue and Max, I'll download the nescessary files in just a short while, and then I'll give it another try. Even though it is not something I am very experienced with, this might actually offer me an opportunity to learn and get experienced about something that is new to me . If I meet any problems, I'll send you a PM. But with the latest posting in mind, and the clarification of the hostpointing, I'm convinced that I should be able to get somehow a bit further than last i tried to make my Quad work as both a server aswell as a client using PRPnet.

Take care

Kenneth