PRPnet 2nd drive-51 bases with <= 5 k's to n=250K

[mdettweiler]

Originally Posted by rogue

I can't access the NPLB PRPNet server from work, so I will investigate when I get home later.

Until then, can someone tell me which were not proven and which program was used to determine that they are PRP?

There are some possibilities, which might account for that.

1) Running LLR only, but LLR can't prove primality due to running an older version of LLR.
2) Running LLR only with current LLR, but PRPNet client is incorrectly parsing the LLR output.
3) Running phrot on non-x86 computer as phrot can't prove primality.
4) Running phrot on x86 computer as pfgw and llr are not available.
5) Running pfgw, but primality test fails (least likely cause).

Interestingly enough, I think #5 may actually be what happened here. The email notifications for all three PRPs indicated that they were found with pfgw64 but for whatever reason not proven. Here's one of them:

This number is approximately 119744 digits long. It was found on machine 15 using the program pfgw64. Since the test performed as only a PRP test, another program, such as PFGW must be used to prove primality. If the number is prime and is large enough for the Prime Pages, please include the program pfgw64 in the credits. If adding to the Prime Pages don't forget to include project "CRUS" in the credits.

[rogue]

Originally Posted by mdettweiler

Interestingly enough, I think #5 may actually be what happened here. The email notifications for all three PRPs indicated that they were found with pfgw64 but for whatever reason not proven. Here's one of them:

Interesting. Can someone produce the PRPNet client output (and log file) to see what happened? Do you know which version of the client the user was running? Did they stop the client during the primality test?

[Lennart]

The problem is PFGW 64

those 2 computer did not have glib 2.7

I did coment out pfgw and I have no problem.


Lennart

[gd_barnes]

Why is PFGW64 unable to prove PRPs?

What is glib 2.7?

Why was PFGW commented out?

[rogue]

Originally Posted by Lennart

The problem is PFGW 64

those 2 computer did not have glib 2.7

I did coment out pfgw and I have no problem.

Lennart

This isn't clear to me. Are you saying that pfgw64 found the PRP, but due to the missing glib 2.7 library that it could not prove primality?

Can you install the latest glib on those computers? If not, I can walk you through the building of pfgw64 on them. It will link with whatever version of glibc that you have installed. In the Linux distribution or 3.4.9 there is both pfgw64 and pfgw64s. pfwg64s is statically linked. Have you tried that version?

[mdettweiler]

Originally Posted by gd_barnes

Why is PFGW64 unable to prove PRPs?

What is glib 2.7?

Why was PFGW commented out?

First of all: the inability to prove PRPs had nothing to do with PFGW64. It apparently, for reasons that are not yet entirely clear, had to do with glib 2.7 being missing on Lennart's two computers.

glib is a standard "library" present on most Linux systems that compiled applications can typically refer to by implication rather than having to duplicate its code within their own binaries. However, sometimes a Linux installation will be missing one or more of these libraries (perhaps it's an older version, or was a "light" installation of the OS with not all the libraries installed to save space), and thus an application that depends on them will fail to run. In this case, the primality-proof function of PFGW apparently depends on glib 2.7. In order for it to work, one must either have glib 2.7 installed, or get a statically linked build of PFGW, which is compiled in a way such that the needed library code is included directly in the binary, instead of included by reference. A statically linked binary can be a rather larger file than a dynamically linked one, so the latter is preferable whenever possible.

You may recall that on Jean Penne's website where you can download LLR, he has both "llr" and "sllr" builds available for Linux; the latter is statically linked.

Also: on Windows, the equivalent of such a "library" is a DLL file (for "Dynamic Link Library"), which usually resides in the C:\Windows\System32 folder. If you've ever gotten a "cannot locate dynamic link library x.dll" error from a program, that's essentially the same kind of error Lennart got, just translated into Windows-speak.

In Lennart's case, he had a working LLR build set up with his PRPnet client (either he had the statically linked build, or his system had all the necessary libraries present to run the dynamic build of LLR), so in the absence of a fully-functional PFGW, he simply commented out the PFGW line in prpclient.ini, forcing the client to use LLR instead for both PRP and primality tests. As Mark explained earlier, both are equally fast on a 32-bit system (actually LLR has a slight advantage since it does not need to do a separate re-test to prove PRPs), but since there is no 64-bit LLR, it is preferable to use PFGW64 whenever possible on a 64-bit system so as to take advantage of the 64-bit speed boost.

[Lennart]

Originally Posted by rogue

This isn't clear to me. Are you saying that pfgw64 found the PRP, but due to the missing glib 2.7 library that it could not prove primality?

Can you install the latest glib on those computers? If not, I can walk you through the building of pfgw64 on them. It will link with whatever version of glibc that you have installed. In the Linux distribution or 3.4.9 there is both pfgw64 and pfgw64s. pfwg64s is statically linked. Have you tried that version?

I did use pfgw64 3.4.5 In all folder I found a PRP there is a pfgw.log with the number in.

But it did the prp but not the primeproof ! I can't see what happend but the client just closed.

I coment out pfgw and restarted the client and I don't realy know how it got back as a prp.

Now I have changed them to pfgw64s 3.4.9



Lennart

EDIT: Client Linux 64 4.3.5

[rogue]

Originally Posted by Lennart

But it did the prp but not the primeproof ! I can't see what happend but the client just closed.

That implies a possible bug in the client or in pfgw64. Keep an eye on it and let us know if the problem is fixed with pfgw 3.4.9.

[gd_barnes]

All n=50K bases for the drive have reached n=100K. Many bases are now being processed at once. There will be many "returns" to n=100K as we continue loading in more bases that are at that search depth.

A large majority of primes will now be in the top 5000 range.

[MyDogBuster]

http://primes.utm.edu/primes/page.php?id=101029

94*107^105926+1 is prime - 3 left in that base

[gd_barnes]

Originally Posted by Lennart

I did use pfgw64 3.4.5 In all folder I found a PRP there is a pfgw.log with the number in.

But it did the prp but not the primeproof ! I can't see what happend but the client just closed.

I coment out pfgw and restarted the client and I don't realy know how it got back as a prp.

Now I have changed them to pfgw64s 3.4.9



Lennart

EDIT: Client Linux 64 4.3.5

Based on your statements here, I just figured out something here that I could not previously figure out: When you said that the clients that found the PRPs just closed, I finally figured out that they just "hung" and did not report anything until you restarted them with PFGW commented out. That is why I saw two tests on client 15 at the top of the pending tests list for hours. Those tests were PRPs waiting to be reported! It caused those k values to continue testing to a far higher n range than the PRPs.

It also explains why it appeared there was only 1 prime on the drive for a very long time and then a whole bunch came in all at once.

The moral of the story is: Everyone please do whatever you can to make sure that your clients prove the primes. Otherwise there is a good chance that a PRP will be found, the client will hang without reporting any results to the server (kind of like not connecting), and others will continue testing that k value long after a prime has actually been found. As long as the PRP is reported to the server, that is OK but if the client just hangs, then nothing will get reported and the test will sit in the queue for 2 days (until handed out again) or until you restart the client.


Gary