PRPNet 5.5 Released
 

PRPNet is a client/server application that you can use to search for primes of various popular types including:
[list][*]Sierpinski/Riesel[*]Generalized Cullen/Woodall[*]Carol/Kynea[*]Primorial[*]Factorial[/list]
and many others. This application targets projects that are not supported by BOINC. It works great for those who have their own "farm" of CPUs and want to manage work for that farm from a single computer.

You can d/l 5.5 from [URL="https://sourceforge.net/projects/prpnet/"]here[/URL].

[QUOTE=rogue;288680]These:

[url]www.psp-project.de:8100[/url]
[url]www.psp-project.de:8101[/url]

are still 4.0.6 and still appear to be active.[/QUOTE]
Uh...right, those are PSP (not hosted by us)? :huh:

[QUOTE=mdettweiler;288715]Uh...right, those are PSP (not hosted by us)? :huh:[/QUOTE]

Hmm. Who should I talk to? I don't think that Citrix is still around.

PRPNet 5.0.6 Released
 

I fixed the issue reported here that 5.0 clients could not talk to 4.0.x servers.

You can d/l 5.0.6 from [URL="http://home.roadrunner.com/~mrodenkirch/prpnet_5.0.6.zip"]here[/URL].

[QUOTE=rogue;288745]Hmm. Who should I talk to? I don't think that Citrix is still around.[/QUOTE]

I've notified ltd (PSP admin) about this thread. :)

PS: The PSP forum is here: [URL]http://mersenneforum.org/forumdisplay.php?f=48[/URL]

Edit: Oh, and thank you for fixing the issue so quickly!

Sorry for any inconvenience. Apparently the zip file was uploaded with 0 bytes. It is now fixed.

Maybe I should get around to upgrading from 3.2.5 :smile:

I made two changes:

1) Since primality tests take a long time for primorials/factorials, and as the pfgw doesn't checkpoint primality tests, the client will no longer do them for numbers of those forms.
2) If the ini file was modified to remove all servers and the client has completed all tests and returned them, then shut down.

You can d/l 5.0.7 from [URL="http://home.roadrunner.com/~mrodenkirch/prpnet_5.0.7.zip"]here[/URL].

[QUOTE=rogue;292102]
2) If the ini file was modified to remove all servers and the client has completed all tests and returned them, then shut down.

[/QUOTE]

Its working now as I wish, thx!

PRPNet 5.0.8
 

I've posted PRPNet 5.0.8. It has the following changes:

prpserver: Added support for wwwwcl helper program (an OpenCL implementation of the wwww program).
prpserver: Use coalesce() for PostgreSQL support and ifnull() for MySQL support.
prpclient: Added support for wwwwcl helper program (an OpenCL implementation of the wwww program).

You can d/l 5.0.8 from [URL="http://home.roadrunner.com/~mrodenkirch/prpnet_5.0.8.zip"]here[/URL].

prpclient for gpu
 

I have prpclient-4.3.0beta-windows-gpu version to play around with. Is that the latest gpu-version for windows?

[QUOTE=japelprime;306676]I have prpclient-4.3.0beta-windows-gpu version to play around with. Is that the latest gpu-version for windows?[/QUOTE]

PRPNet is not a GPU application, but it can run geneferCUDA and wwwwcl, which are GPU applications. PrimeGrid has PRPNet servers that accept clients that can run these programs.

I am having trouble getting my new server to start. I installed mysql and the odbc connector. I created the database and ran the script on it.
Whatever I do I can't get the server to connect to the database. Is there a way I can work out at which point it is failing to connect so I can sort it?

[QUOTE=henryzz;311847]I am having trouble getting my new server to start. I installed mysql and the odbc connector. I created the database and ran the script on it.
Whatever I do I can't get the server to connect to the database. Is there a way I can work out at which point it is failing to connect so I can sort it?[/QUOTE]

Set debuglevel=1 in the server. It is most likely an issue with your database.ini file. What OS is this on?

[QUOTE=rogue;311852]Set debuglevel=1 in the server. It is most likely an issue with your database.ini file. What OS is this on?[/QUOTE]

It is windows 7 64-bit. The database.ini is the same as it was when it worked on my old windows installation except that I changed the database name from prpnet5 to prpnet.
[code][2012-09-16 16:49:51 GDT] 2: ODBC Connection via a driver: <Driver={MySQL ODBC 5.1 Driver};Server=localhost;Port=3306;Database=prpnet;User=root;UID=root;Password=nopw;PWD=nopw;Option=3;>
[2012-09-16 16:49:51 GDT] Connect to database failed: [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified, native code=0
[/code]

[QUOTE=henryzz;311853]It is windows 7 64-bit. The database.ini is the same as it was when it worked on my old windows installation except that I changed the database name from prpnet5 to prpnet.
[code][2012-09-16 16:49:51 GDT] 2: ODBC Connection via a driver: <Driver={MySQL ODBC 5.1 Driver};Server=localhost;Port=3306;Database=prpnet;User=root;UID=root;Password=nopw;PWD=nopw;Option=3;>
[2012-09-16 16:49:51 GDT] Connect to database failed: [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified, native code=0
[/code][/QUOTE]

Is the driver name correct? Maybe you have a different driver version of MySQL. The name should match the ODBC driver name you see in ODBC administrator. Also, make sure that you are using the 32-bit driver, not the 64-bit driver as the server is a 32-bit app (unless you rebuild it).

[QUOTE=rogue;311861]Is the driver name correct? Maybe you have a different driver version of MySQL. The name should match the ODBC driver name you see in ODBC administrator. Also, make sure that you are using the 32-bit driver, not the 64-bit driver as the server is a 32-bit app (unless you rebuild it).[/QUOTE]
I am using the 64-bit driver. Can I suggest adding that to the readme.txt for future versions?

edit: installing the 32-bit driver solved it

[QUOTE=henryzz;311863]I am using the 64-bit driver. Can I suggest adding that to the readme.txt for future versions?

edit: installing the 32-bit driver solved it[/QUOTE]

Certainly. When I originally released the Windows builds most people were still on 32-bit Windows. I think that has changed, which is a good thing as Window 7 is far superior to any previous version of Windows. Now if M$ could only rid themselves of the registry.

Discovered a slightly odd bug/feature today. I loaded a lot of fast work(280k candidates) into a riesel/sierp server. While I was loading the work clients were able to get candidates and return primes. The problem is that while it was still loading candidates(sorted by n) it continued testing a k after finding a prime(once all candidates were loaded the riesel/sierp code came into play). On several occassions it found a second prime for a k before the candidates finished loading. Both primes were put in the logs which is fine. However the larger of the 2 primes would be in the smallest prime column(on the webpage stats) rather than the smaller one. Next time I will shut down the clients. This couldn't be done for something like a CRUS public server though.

In addition to this I have a feature request:
Could there be a way(quite possible started by the prpadmin) to make the server output all the ks with no prime? Currently I put 200 ks into prpnet and get ~40 out. Unless I used lots of regex's and command line trickery I would have to manually make a list of the remaining ks.

[QUOTE=henryzz;312981]Discovered a slightly odd bug/feature today. I loaded a lot of fast work(280k candidates) into a riesel/sierp server. While I was loading the work clients were able to get candidates and return primes. The problem is that while it was still loading candidates(sorted by n) it continued testing a k after finding a prime(once all candidates were loaded the riesel/sierp code came into play). On several occassions it found a second prime for a k before the candidates finished loading. Both primes were put in the logs which is fine. However the larger of the 2 primes would be in the smallest prime column(on the webpage stats) rather than the smaller one. Next time I will shut down the clients. This couldn't be done for something like a CRUS public server though.

In addition to this I have a feature request:
Could there be a way(quite possible started by the prpadmin) to make the server output all the ks with no prime? Currently I put 200 ks into prpnet and get ~40 out. Unless I used lots of regex's and command line trickery I would have to manually make a list of the remaining ks.[/QUOTE]

I could fix the first issue you mention, but it would hurt performance when loading the server.

You can get that data via mysql by looking at the CandidateGroupStats table.

[QUOTE=rogue;312997]I could fix the first issue you mention, but it would hurt performance when loading the server.

You can get that data via mysql by looking at the CandidateGroupStats table.[/QUOTE]
I will investigate this once my machine with a server on it has internet after the 10th.

I've posted PRPNet 5.1.0. It has the following changes from 5.0.9:

prpserver: Fixed debug message.
prpclient: Allow only one instance of a client to run at a time from the directory.

You can d/l 5.1.0 from [URL="http://home.roadrunner.com/~mrodenkirch/prpnet_5.1.0.zip"]here[/URL].

[QUOTE=rogue;314005]I've posted PRPNet 5.1.0. It has the following changes from 5.0.9:

prpserver: Fixed debug message.
prpclient: Allow only one instance of a client to run at a time from the directory.

You can d/l 5.1.0 from [URL="http://home.roadrunner.com/~mrodenkirch/prpnet_5.1.0.zip"]here[/URL].[/QUOTE]

From the last change I have seen. The client doesnt starting if:

main dir
|_dir core1
|_dir core2
|_dir core3
|_dir core4

Only one client starting. The fix should be active if 2x the same client starting from any of the sub directories not main.

[QUOTE=rebirther;315398]From the last change I have seen. The client doesnt starting if:

main dir
|_dir core1
|_dir core2
|_dir core3
|_dir core4

Only one client starting. The fix should be active if 2x the same client starting from any of the sub directories not main.[/QUOTE]

I don't fully understand. In which directory(is) is the client and the ini file for the client? What is your current directory when you start the client, main or core1/2/3/4?

[QUOTE=rogue;315400]I don't fully understand. In which directory(is) is the client and the ini file for the client? What is your current directory when you start the client, main or core1/2/3/4?[/QUOTE]

I have f:/maindir with 4 sub dirs for all 4 cores, every single client start in sub dir 1, 2, 3, 4

[QUOTE=rebirther;315401]I have f:/maindir with 4 sub dirs for all 4 cores, every single client start in sub dir 1, 2, 3, 4[/QUOTE]

You probably have the same clientid specified in the prpclient.ini file for each client. On Windows the code uses that id to create a lock to prevent other clients with the same id from running at the same time.

Ehh.. I am doing it the same way.
All my clients on the same machine use the same clientid, so that doublechecks at the server works:

// doublechecker= indicates who can double-check the number
// 1 - a different person and client machine than the first (default)
// 2 - a different person than the first tester
// 3 - a different client machine than the first client machine
// 4 - anybody
doublechecker=3

or how is "different client machine" identified, when not using the clientid?

[QUOTE=Xentar;315405]Ehh.. I am doing it the same way.
All my clients on the same machine use the same clientid, so that doublechecks at the server works:

// doublechecker= indicates who can double-check the number
// 1 - a different person and client machine than the first (default)
// 2 - a different person than the first tester
// 3 - a different client machine than the first client machine
// 4 - anybody
doublechecker=3

or how is "different client machine" identified, when not using the clientid?[/QUOTE]

I see your problem. Double-checking hasn't been used heavily, so this went unnoticed. If your clients only connected to your server, then I suggest changing the client userid and using option 2. I'll need to address this discrepancy in a future release.

You should be safe using option 3 and changing the client id. It is extremely unlikely for two failed tests to return the same incorrect residue, barring a bug in gwnum.

[QUOTE=rogue;315404]You probably have the same clientid specified in the prpclient.ini file for each client. On Windows the code uses that id to create a lock to prevent other clients with the same id from running at the same time.[/QUOTE]

Correct, can you change that? If I change the clientid in any of the directory and run the master.ini update all is back again. clientid check is the wrong way. dir/subdir check if one client is running should be fine.

[QUOTE=rebirther;315504]Correct, can you change that? If I change the clientid in any of the directory and run the master.ini update all is back again. clientid check is the wrong way. dir/subdir check if one client is running should be fine.[/QUOTE]

I know. Windows uses different code than *nix. It isn't quite as easy as one would think. I have an idea, so we'll see what I come up with.

[QUOTE=henryzz;313097]I will investigate this once my machine with a server on it has internet after the 10th.[/QUOTE]

How does the server work out what to put in the smallest prime field? When it finds a prime does it update the field with that value? If so does it check whether there is a smaller prime there already?

[QUOTE=henryzz;315663]How does the server work out what to put in the smallest prime field? When it finds a prime does it update the field with that value? If so does it check whether there is a smaller prime there already?[/QUOTE]

For Sierpinski/Riesel servers, I believe that it puts the first prime found for the k/b/c into the CandidateGroupStats table (what you see on server_stats.html). If a smaller one happens to be found, I believe that it does not update that table.

[QUOTE=rogue;315672]For Sierpinski/Riesel servers, I believe that it puts the first prime found for the k/b/c into the CandidateGroupStats table (what you see on server_stats.html). If a smaller one happens to be found, I believe that it does not update that table.[/QUOTE]

Going back to the problem case. When the server finishes loading the pairs from admin how does it go through the tests already done to check if there is a prime. I suspect it will be the same code that would be run when changing server type from non-seirp/riesel to seirp/riesel.
It seems like whatever it is checks from the larger tests down(assuming no replacement if smaller found). Would it be possible to switch the order?

[QUOTE=henryzz;315845]Going back to the problem case. When the server finishes loading the pairs from admin how does it go through the tests already done to check if there is a prime. I suspect it will be the same code that would be run when changing server type from non-seirp/riesel to seirp/riesel.
It seems like whatever it is checks from the larger tests down(assuming no replacement if smaller found). Would it be possible to switch the order?[/QUOTE]

When a prime is returned by a client, the server will mark all n for that k,b,c for that prime in such a way that no more candidates for higher n are sent out.

When server stats are recomputed every 20 minutes (or however you have the server configured), it selects the min(CandidateName) with a prime for that k,b,c. Obviously that code is wrong as it should choose from the candidate with the smallest decimal length.

I'm working on PRPNet 5.2.0 as I write this. It will include the following changes:
[list][*]Replace clientid with machineid and instanceid which allows for both unique identification of a machine and unique identification of an instance of the PRPNet client on the machine.[*]Modify doublechecker flag to use machineid (was using clientid).[*]Modify Sierpinski/Riesel stats collection to select the smallest n with a prime for a given k/b/c rather than the candidate with the first alphabetical name.[*]Modify code to set HasSierpinskiRieselPrime to 1 if higher n are added to a k/b/c with a found prime.[*]Remove support for clients older than 4.3.[*]Add brieftestlog flag to prpserver.ini so that output to console and testlog is shorter.[*]Fix a bug when client runs wwww helper program as it sometimes doesn't recognize it.[/list]
This should include the changes that have been requested earlier in this thread. If I'm forgetting something or if you have idea for new mods or found other bugs, please let me know. I hope to release the code early next week.

I've posted PRPNet 5.2.0. It has the following changes from 5.1.0:

[code] prpclient: Replace clientid in ini with machineid and instanceid.
prpclient: Fix bug for wwww projects where client couldn't extract program name.
prpserver: Rename column ClientID in database to MachineID. Add InstanceID.
prpserver: Modify doublechecker to use machine id instead of clientid.
prpserver: Fix bug in Sierpinski/Riesel stats to ensure prime listed in table has the smallest n.
prpserver: Modify Sierpinski/Riesel stats updater to set HasSierpinskiRieselPrime flag on new Candidates that are inserted if a prime was already found for the k, b, c.
prpserver: Removed support for clients older than 4.3.
prpserver: Added brieftestlog to prpserver.ini. This flag can be used to shorten the output on consoles.
prpserver: Added estimate of days left to Wieferich/WallSunSun server_stats.html.[/code]

If upgrading a server, please read the history.txt file to find the SQL statements you need to run to do the upgrade.

Clients as old as 4.3 compatible with the 5.2 server. 5.2 clients should be compatible with servers as old as 4.3, but I have not tested that.

I highly recommend that projects upgrade to 5.2.0 at their earliest convenience. I cannot guarantee that future releases of the server will support 4.x clients. If you need assistance in upgrading a server from 4.x to 5.x, feel free to contact me via PM or e-mail. There is little risk to make that upgrade.

You can d/l 5.2.0 from [URL="http://home.roadrunner.com/~mrodenkirch/prpnet_5.2.0.zip"]here[/URL].

I've posted PRPNet 5.2.1. This version fixes a bug with strcpy() where the source and target are within the same string buffer. Apparently this isn't a issue on most OSes, but it is a big no-no on some flavors of Linux.

You can d/l 5.2.1 from [URL="http://home.roadrunner.com/~mrodenkirch/prpnet_5.2.1.zip"]here[/URL].

I've posted PRPNet 5.2.2. In this version I changed onekperclient in the server to onekperinstance and fixed a bug I introduced in 5.2.0. I fixed a logging issue where timezone would show as '???'. I also added a 64-bit build option to the Windows solution.

You can d/l 5.2.2 from [URL="http://home.roadrunner.com/~mrodenkirch/prpnet_5.2.2.zip"]here[/URL].

[QUOTE=rogue;322195]I've posted PRPNet 5.2.2. In this version I changed onekperclient in the server to onekperinstance and fixed a bug I introduced in 5.2.0. I fixed a logging issue where timezone would show as '???'. I also added a 64-bit build option to the Windows solution.

You can d/l 5.2.2 from [URL="http://home.roadrunner.com/~mrodenkirch/prpnet_5.2.2.zip"]here[/URL].[/QUOTE]

...any hopes to have a check at DoubleMersennes?... :smile:

Luigi

[QUOTE=ET_;322219]...any hopes to have a check at DoubleMersennes?... :smile:
Luigi[/QUOTE]

It's not clear to me what you are looking for. Are you referring to me fixing gmp-fermat and the double-mersenne logic it has? If so, then I don't know when I'll get to it. If I'm lucky, next week, but I can't make any promises. If you are referring to modify PRPNet to support a search, I've never thought about it.

[QUOTE=rogue;322242]It's not clear to me what you are looking for. Are you referring to me fixing gmp-fermat and the double-mersenne logic it has? If so, then I don't know when I'll get to it. If I'm lucky, next week, but I can't make any promises. If you are referring to modify PRPNet to support a search, I've never thought about it.[/QUOTE]

I hope you will be lucky... :smile:

Luigi

Yesterday I updated from version 4.3.7 to version 5.2.2. (Windows 7 x64)
But the new version seems to be more unstable than the old one :(
I just came home and saw, the the prpserver.exe crashed (Windows message: Stopped working, application needs to be closed).
In the log file there is nothing.. last message was a correctly accepted tests.

The only thing I noticed is, I got many of the following messages on different clients, although the server was running:
[CODE][2013-01-13 01:56:22 MZ] s19: Returning work to server localhost at port 7119
[2013-01-13 01:56:32 MZ] s19: nothing was received on socket after 10 seconds
[2013-01-13 01:56:34 MZ] s19: nothing was received on socket after 2 seconds
[2013-01-13 01:56:34 MZ] Could not connect to any servers and no work is pending. Pausing 10 minutes
[2013-01-13 02:06:35 MZ] s19: Returning work to server localhost at port 7119
[2013-01-13 02:06:45 MZ] s19: nothing was received on socket after 10 seconds
[2013-01-13 02:06:47 MZ] s19: nothing was received on socket after 2 seconds
[2013-01-13 02:06:47 MZ] Could not connect to any servers and no work is pending. Pausing 10 minutes
[2013-01-13 02:16:48 MZ] s19: Returning work to server localhost at port 7119[/CODE]

Could it have something to do with the amount of tests in the database?
I am testing s19, there are about 2M tests in the mysql database.
Using MySQL server version 5.1.43.

[QUOTE=Xentar;324557]Yesterday I updated from version 4.3.7 to version 5.2.2. (Windows 7 x64)
But the new version seems to be more unstable than the old one :(
I just came home and saw, the the prpserver.exe crashed (Windows message: Stopped working, application needs to be closed).
In the log file there is nothing.. last message was a correctly accepted tests.

The only thing I noticed is, I got many of the following messages on different clients, although the server was running:
[CODE][2013-01-13 01:56:22 MZ] s19: Returning work to server localhost at port 7119
[2013-01-13 01:56:32 MZ] s19: nothing was received on socket after 10 seconds
[2013-01-13 01:56:34 MZ] s19: nothing was received on socket after 2 seconds
[2013-01-13 01:56:34 MZ] Could not connect to any servers and no work is pending. Pausing 10 minutes
[2013-01-13 02:06:35 MZ] s19: Returning work to server localhost at port 7119
[2013-01-13 02:06:45 MZ] s19: nothing was received on socket after 10 seconds
[2013-01-13 02:06:47 MZ] s19: nothing was received on socket after 2 seconds
[2013-01-13 02:06:47 MZ] Could not connect to any servers and no work is pending. Pausing 10 minutes
[2013-01-13 02:16:48 MZ] s19: Returning work to server localhost at port 7119[/CODE]

Could it have something to do with the amount of tests in the database?
I am testing s19, there are about 2M tests in the mysql database.
Using MySQL server version 5.1.43.[/QUOTE]

There are two possibilities. First, I know there is a memory leak in the Windows MySQL ODBC driver. I've reported it, but it has not been fixed. It is possible that this is causing the problem. When a 32-bit build of the server hits 2 GB it will crash. When that happens you will see various MySQL errors on the prpserver console. This is a addressed by shutting down and restarting the server every few days. Second, I have seen other intermittent crashes in the server, but they occur rarely and of course never occur with debug builds. I probably need to do a "clean" then a "build", but I can't claim that it is a compile or linkage issue.

The problem appeared after updating the prpserver only. I didnt touch the MySQL server (or ODBC driver). The old version ran for months without restarting. Maybe I just should update them? The newest MySQL version is 5.5.* :smile:

A few minutes ago, I saw this lines in the log:
[CODE][2013-01-13 16:32:03 MZ] 524: ODBC Information: SQL_ERROR: [MySQL][ODBC 5.1 Driver][mysqld-5.1.43-community]Lock wait timeout exceeded; try restarting transaction
[2013-01-13 16:32:03 MZ] 524: ODBC Information: SQL Statement: update Candidate set HasPendingTest = 1 where CandidateName = 1446*19^100146+1 and HasPendingTest = 0
[/CODE]

I will try debuglevel=1 and see if it crashes again.

[QUOTE=Xentar;324580]The problem appeared after updating the prpserver only. I didnt touch the MySQL server (or ODBC driver). The old version ran for months without restarting. Maybe I just should update them? The newest MySQL version is 5.5.* :smile:

A few minutes ago, I saw this lines in the log:
[CODE][2013-01-13 16:32:03 MZ] 524: ODBC Information: SQL_ERROR: [MySQL][ODBC 5.1 Driver][mysqld-5.1.43-community]Lock wait timeout exceeded; try restarting transaction
[2013-01-13 16:32:03 MZ] 524: ODBC Information: SQL Statement: update Candidate set HasPendingTest = 1 where CandidateName = 1446*19^100146+1 and HasPendingTest = 0
[/CODE]

I will try debuglevel=1 and see if it crashes again.[/QUOTE]

In post 46 rouge mentioned that there were sql statements needed to upgrade a server from 4 to 5. I can't see you mentioning them.

I executed the following SQL script while updating:

[CODE] alter table UserPrimes change column ClientID MachineID varchar(200) collate latin1_bin;
alter table UserPrimes add column InstanceID varchar(200) collate latin1_bin;
alter table CandidateTest change column ClientID MachineID varchar(200) collate latin1_bin;
alter table CandidateTest add column InstanceID varchar(200) collate latin1_bin;
alter table CandidateGFNDivisor change column ClientID MachineID varchar(200) collate latin1_bin;
alter table CandidateGFNDivisor add column InstanceID varchar(200) collate latin1_bin;

update UserPrimes set InstanceID = MachineID;
update CandidateTest set InstanceID = MachineID;
update CandidateGFNDivisor set InstanceID = MachineID;
[/CODE]

All tables *WWWW* are still missing. Could this cause a problem?
I didn't think so, because there was no update script from version 4.* to version 5.*
The new tables just exist, when you use the newest "create_tables_mysql.sql", but not when upgrading.

Sounds like the problem to me. Hopefully rouge can tell you how to fix it.

Upgrading from 4.3 to 5.0 requires the creation of the WWWW* tables only which are only needed for WWWW projects, i.e. those run by PrimeGrid. Additional modifications for the minor releases are in the history.txt file.

As for timeouts, they occur, but aren't serious as the application can recover from them.

I will be releasing an update this coming week. I'll make sure to do a clean before the build hoping that it will resolve the problem.

I updated my MySQL server on monday from version 5.1.43 to 5.5.29.
Since then, no crash of PRPNetServer.

I still have debug output enabled, and I think that the SQL commands are executed much faster after the update.
So maybe the crash had something to do with table locking / slow SQL commands. I'm running 6 clients, so maybe it is a deadlock, when two clients request new data at the same time.

Will tell you, if it happens again.

[QUOTE=Xentar;325070]I updated my MySQL server on monday from version 5.1.43 to 5.5.29.
Since then, no crash of PRPNetServer.

I still have debug output enabled, and I think that the SQL commands are executed much faster after the update.
So maybe the crash had something to do with table locking / slow SQL commands. I'm running 6 clients, so maybe it is a deadlock, when two clients request new data at the same time.[/QUOTE]

Deadlocks are possible, but not likely. If one occurs, you will see it in the log, even if debug is turned off.

I think I found the bug in the server code. I was able to reproduce easily on my Mac, but reproducing on Windows is difficult. In DBInterface::Disconnect, I have these lines of code:

SQLDisconnect(ip_SQLConnectionHandle);
SQLFreeHandle(SQL_HANDLE_STMT, ip_SQLStatementHandle);

They should be in this order:

SQLFreeHandle(SQL_HANDLE_STMT, ip_SQLStatementHandle);
SQLDisconnect(ip_SQLConnectionHandle);

Closing the connection first frees the statement handle, which makes sense as the statement can only exist with a connection.

I'll release 5.2.3 on Monday.

I've posted 5.2.3. It has the following changes:

[code]
client: If client detects an error when starting up, show the error, then
sleep for 10 seconds so that user can see the error. This addresses
an issue for users who double-click on the application but the window
closes immediately due to a configuration error.

server: Fixed *nix compile bug with the server.
server: Added serverstatssummaryonly= option to prpserver.ini. When set to 1
the server will only show the summary line on server_stats.html.
server: Add sorting capability to a number of html tables.
server: Refactored much of the HTML generation code.
server: Fix crash when database connection is closed.
[/code]

You can d/l 5.2.4 from [URL="http://home.roadrunner.com/~mrodenkirch/prpnet_5.2.4.zip"]here[/URL].

[QUOTE=rogue;325360]You can d/l 5.2.4 from [URL="http://home.roadrunner.com/~mrodenkirch/prpnet_5.2.4.zip"]here[/URL].[/QUOTE]

The link is wrong, must be [URL="http://home.roadrunner.com/~mrodenkirch/prpnet_5.2.3.zip"]here[/URL] ;)

[QUOTE=rebirther;325485]The link is wrong, must be [URL="http://home.roadrunner.com/~mrodenkirch/prpnet_5.2.3.zip"]here[/URL] ;)[/QUOTE]

Sorry, getting ahead of myself. :-)

I've posted PRPNet 5.2.4. In this version I updated SharedMemoryItem to simplify the use of mutexes in the server. I fixed ^C on the server so that it waits or connected clients to close their connections before shutting down. I also fixed a computation error affecting the calculation of the number of days left on the server_stats.html page. Finally, I fixed a problem with the loading of candidates that would give erroneous messages.

One more thing I forgot. If localtimelog is set to 2, then the server will not print the timezone in the log.

You can d/l 5.2.4 from [URL="http://home.roadrunner.com/~mrodenkirch/prpnet_5.2.4.zip"]here[/URL].

There are two % missing in WWWWMail.cpp, lines 91-96:
[CODE]
if (ii_ServerType == ST_WALLSUNSUN)
success = NewMessage(toEmailID, "%s special instance [B][COLOR=red]%[/COLOR][/B]lld (0 %+d) p was found by PRPNet!",
searchType, prime, quotient);
else
success = NewMessage(toEmailID, "%s special instance [B][COLOR=red]%[/COLOR][/B]lld (%+d %+d) p was found by PRPNet!",
searchType, prime, remainder, quotient);
[/CODE]

[QUOTE=pschoefer;344391]There are two % missing in WWWWMail.cpp, lines 91-96:
[CODE]
if (ii_ServerType == ST_WALLSUNSUN)
success = NewMessage(toEmailID, "%s special instance [B][COLOR=red]%[/COLOR][/B]lld (0 %+d) p was found by PRPNet!",
searchType, prime, quotient);
else
success = NewMessage(toEmailID, "%s special instance [B][COLOR=red]%[/COLOR][/B]lld (%+d %+d) p was found by PRPNet!",
searchType, prime, remainder, quotient);
[/CODE][/QUOTE]

Thanks

I've posted PRPNet 5.2.6. 5.2.5 was modified by PrimeGrid to address an issue with a bad helper program. Here is a summary of changes for both. Except where noted all changes were in the server.
[list][*]If client returns a residue with '.', remove it.[*]Add localtimezone=2 setting to disable appending timestamp in the log with a timezone.[*]Fixed issue where '.' wasn't removed from residue when using llr. (client)[*]For Wall-Sun-Sun, reject results from wwwwcl prior to version 2.2.5.[*]Add noexpire=1 option to inhibit task expiration.[*]Add nonewwork=1 option to disable new work from be sent to clients.[*]Add keys to tables to improve efficiency with larger databases.[*]Multiple WWWW bug fixes.[/list]
You can d/l 5.2.6 from [URL="http://home.roadrunner.com/~mrodenkirch/prpnet_5.2.6.zip"]here[/URL].

I fixed a bug in the server that I introduced in 5.2.6.

You can d/l 5.2.7 from [URL="http://home.roadrunner.com/~mrodenkirch/prpnet_5.2.7.zip"]here[/URL].

Hey Mark--I have a question about how the PRPnet client launches LLR on Linux. I have a somewhat "nontraditional" setup for my PRPnet clients on a few of my boxes: instead of duplicating all the worker executables (LLR, PFGW, Genefer, and WWWW) in the client directory for each core, I keep just one copy of each binary in the parent directory, with each prpclient.ini pointing to "../llr64", "../pfgw64", etc. I've used this setup on Windows for the last couple of years, and it's worked fine for all the worker programs. However, I just recently discovered that on Linux, this works for PFGW (possibly Genefer and WWWW as well, I haven't checked) but not for LLR.

Basically, my folder structure is as follows:
[code]
prpnet [directory]
llr64
pfgw64
genefer
genefx64
genefer80
wwww
start-clients.sh (a simple shell script that cd's to each client's directory and runs it with nohup)
1 [directory]
prpclient
prpclient.ini
{other files created at runtime by prpclient #1}
2 [directory]
prpclient
prpclient.ini
{other files created at runtime by prpclient #2}
[/code]
On Windows, I had successfully used this setup for both LLR and PFGW jobs. In both cases, the server log registered the worker program as "..\pfgw64.exe" or "..\cllr64.exe".

I've also been using this setup on Linux, but all my Linux clients had just been running CRUS port 1400 so I only ever saw them using PFGW. In this case, the server registered the worker program as "\pfgw64" - note the truncated "..", which may or may not be significant. As expected, PFGW ran out of the respective client directory and created all its temporary files there.

When the CRUS port 1400 server ran out of work today, those clients fell back to NPLB port 2000, which is of course loaded with LLR jobs. I noticed that right at that time, those clients stopped producing any work, and when I logged in to check them I found that they had exited, thinking that LLR had been Ctrl-C'd. There were no llr.ini's or other temporary files in the "1" and "2" client directories, but there was an llr.ini out in the main "prpnet" directory.

Does prpclient do anything special when it's launching LLR on Linux? It appears as though LLR is being run from the directory in which the binary is located, rather than the current directory from which the prpclient was started. Since I hadn't run into any issues with this on Windows, I wondered if perhaps this was a particularity of prpclient (rather than LLR).

In the meantime, I copied the llr64 binaries into the "1" and "2" folders and adjusted the prpclient.ini's to point to "./llr64" instead of "../llr64". That's been working fine, as expected.

FYI, the Linux clients in question are running 5.0.8, and I believe the Windows clients I didn't have any issues with earlier were running 5.0.6.

Thanks! :smile:

Max

The only thing the client can do is delete the temp files in the client directory that are created by llr, pfgw, etc.

It is NOT recommended to run multiple copies of the exes from the same directory as those exes will create some files with static names, thus overwriting copies written by another instance of the same exe.

I'm not actually running the two clients from the same directory--what I'm doing is using one copy of the worker binaries, and running each client from within its own directory. That is, I do this (see the folder structure above):
[code]
cd prpnet/1
nohup ./prpclient
cd ../2
nohup ./prpclient
[/code]So, all the working files created by each instance of prpclient are localized to the 1 and 2 folders. The only "nonstandard" thing that's happening is that the LLR, PFGW, etc. binaries are stored elsewhere--in this case, in "../[I]binary-name[/I]" relative to each client. Looking in our server logs, I've noticed others have done something similar, putting, say, PFGW in "/usr/bin/pfgw", and pointing to that in prpclient.ini.

[QUOTE=mdettweiler;348214]I'm not actually running the two clients from the same directory--what I'm doing is using one copy of the worker binaries, and running each client from within its own directory. That is, I do this (see the folder structure above):
[code]
cd prpnet/1
nohup ./prpclient
cd ../2
nohup ./prpclient
[/code]So, all the working files created by each instance of prpclient are localized to the 1 and 2 folders. The only "nonstandard" thing that's happening is that the LLR, PFGW, etc. binaries are stored elsewhere--in this case, in "../[I]binary-name[/I]" relative to each client. Looking in our server logs, I've noticed others have done something similar, putting, say, PFGW in "/usr/bin/pfgw", and pointing to that in prpclient.ini.[/QUOTE]

By "exes" I meant both the client and the helper programs. The intention was to always put a copy of lld, pfgw, etc. in the same directory that the client is in.

[QUOTE=rogue;348223]By "exes" I meant both the client and the helper programs. The intention was to always put a copy of lld, pfgw, etc. in the same directory that the client is in.[/QUOTE]
Right, yes. I guess what I was trying to say, though, is that while there is only one copy of the binaries (well, I have prpclient itself stored individually in the 1 and 2 directories), the clients are being [I]run[/I] from inside the 1 and 2 directories, that is, their context is in those directories. The OS considers the "working directory" for a running program to be the directory it was [I]started[/I] from, not the directory the binary resides in, so that's where any files created by the program will be placed unless it directly specifies a full hard path.

Sorry if this is a little confusing--I realize it's kind of nonstandard, but I figured, hey, it should work in theory (and it does on Windows). :smile: It's not too big a deal--I was able to work around the issue easily enough by copying the LLR binary to the respective client directories (though PFGW is still happy running from the one copy in the parent directory).

Okay, so out of curiosity, I read through some of the relevant PRPnet source code files to figure out why this behavior is occurring on Linux but not on Windows. I think I've figured out what's going on--it's not an issue with PRPnet at all, but rather a "bug" in LLR that only manifests itself under Linux.

Whenever PRPnet opens any files for reading or writing, it does so by simply passing the file name to fopen(), without appending any other path information. That is, it uses relative paths to indicate files in the current working directory (the directory last cd'd to before prpclient was run - typically the same directory as the program itself since it's run as ./prpclient, but this could in theory be anywhere if you specify an alternate path to prpclient on the command line). Thus, PRPnet keeps its own working set of files that it can modify at will since they're not shared with any other clients (unless of course someone runs prpclient twice from the same directory, which is a big no-no that you fixed in 5.1.0).

In theory, LLR, PFGW and other such programs should behave similarly - all their input and output files should be in the current directory unless otherwise specified on the command line or in their respective INI files. However, it would appear that LLR does this slightly wrong on Linux - it looks for llr.ini, and saves its output files, in the [I]directory where the LLR binary is located[/I]. In most typical usage cases, this is one and the same with the current working directory, so this is no big deal; but, in cases like mine, there is a difference, and it breaks LLR's interaction with PRPnet, since PRPnet is (properly) writing its llr.ini and input file to the working directory (in my case, "1" or "2" respectively) - but LLR is looking for them one directory up where it's itself located.

I'm wondering if this is a bug in how LLR handles its -w ("run from a different working directory") command line option. When that option is not specified, it should be defaulting to the current directory in which it was launched, "./". However, it's instead defaulting to the location of the LLR binary. In light of how this problem appears under Linux but not with cllr on Windows, my guess is that it is likely rooted in some subtle aspect of a piece of Linux-specific LLR code.

I'm going to try specify the LLR program location as [I]../llr64 -w"./"[/I] in prpclient.ini and see if that does the trick. In theory, it should effectively work around the issue in LLR (assuming that it parses correctly in prpclient.ini, which it may not since I'm totally abusing that parameter's intended function here :rolleyes:). Sure, I could just stick a copy of LLR in each of my client directories...but I'd kind of like to make this work if I can, since it's handy when a new LLR version comes out and I need to go around upgrading all my clients.

Well, that went well...as I'd suspected, passing "../llr64 -w./", or any of various escaped variants, confused the heck out of the prpclient.ini parsing code. :smile:
[code]
[2013-08-04 20:41:00 EDT] A required PRP testing program is missing. Unable to test 124125*6^700656+1
[2013-08-04 20:41:00 EDT] The client will now shut down due to this error
[2013-08-04 20:41:00 EDT] Huh? The test did not complete, yet you didn't terminate it. Exiting
[/code]
I guess that's what I get for trying to pass arguments directly to LLR via the llrexe= option. :rolleyes: Oh well--I guess I'll just need to keep a copy of llr64 in each client directory on my Linux boxes.

This would explain why I've seen "/usr/local/bin/pfgw" show up in our server logs, but never "/usr/local/bin/llr"...

I've considered modifying pfgw so that you could run one copy of the exe, but specify a directory where it would perform all other I/O. For example, "pfgw64 -D c1" would run pfgw64 from the current directory, but put pfgw.ini, pfgw.log, etc into the subdirectory c1. I don't think that would be too hard. Is that how the -w option works for llr?

Yes, that is how -w works on LLR. Actually, PFGW already can be run quite well as-is in a similar manner to that - you can do something similar to what I've been doing with my PRPnet clients, where you have one copy of PFGW, but cd into another directory and launch PFGW with an appropriate path (either an absolute path, such as "/usr/local/bin/pfgw", or a relative path such as "../pfgw"). That will keep all the files for [I]this run[/I] in the directory your terminal window is in when you start it, and you can do this simultaneously for multiple instances (started from separate directories of course) from one exe. It's basically the same way you can run multiple copies of, say, Firefox on a multi-user system - everyone's accessing the same binary in Program Files or wherever, but each of their instances are reading and writing to a separate profile record somewhere under their home directory.

Interestingly enough, it's LLR that has a problem with this on Linux due to the issue I've been describing in the last few posts--it does this fine on Windows, but on Linux it always reads/writes to the directory where the LLR binary is stored (unless overridden with -w), instead of the current working directory where it should. PFGW has worked fine when I've done this on both Windows and Linux, and I seem to recall Genefer and WWWW handling it as well on Windows (I haven't tried it with them on Linux). In general, most programs that read-write from the "current directory" can do this without any problems; LLR seems to be the exception in this regard.

Edit: I was just thinking, a good example of this is when you go into the right-click Properties menu for a shortcut in Windows. There's two boxes with properties you can edit: one for the path to the program you want to run (with command line arguments), and another for the working directory to run the program from. On Windows, the default is for this to be the directory the executable is in, which is why Windows programs traditionally saved log files and such under C:\Program Files\ProgramName\; this was the cause of a lot of troubles for legacy programs when Microsoft introduced UAC with Vista and made Program Files a "privileged-only write" folder. On Linux and Mac, which had a stricter user/superuser model from the start, programs traditionally started in the context of the user's home folder, and this is usually the default when you create a desktop shortcut in one of those operating systems. This is also why many Linux/Unix programs ported to Windows (such as GIMP) tend to junk up your C:\Users\[I]me[/I] folder with random files, since it's seen as the home folder on Windows.

You could try putting a symlink to llr64's real location into the 1 and 2 dirs. That avoids having multiple copies of llr64 on the system (sooner or later one will be forgotten when you upgrade llr64). Or a hard link if that does not work. See the man page for ln for details.

I've not tested either option though.

Chris

[QUOTE=chris2be8;348320]You could try putting a symlink to llr64's real location into the 1 and 2 dirs. That avoids having multiple copies of llr64 on the system (sooner or later one will be forgotten when you upgrade llr64). Or a hard link if that does not work. See the man page for ln for details.

I've not tested either option though.

Chris[/QUOTE]
Hmm, right...I hadn't thought of that, though it should work. I think I'll try that...

I have released 5.2.8.

Changes include:
all: Fixed a logging issue that prevented debug logging from working as intended.
client: Add support for OpenCL based genefer. It will be treated as an equivalent to the CUDA version of genefer.
server: Fix log issue where prpserver.log would sometimes duplicate a line written to it.
server: Ensure database transaction is using REPEATABLE READ option.
server: Check return codes when setting connection attributes in database.
server: Add support for OpenCL based genefer. It will be treated as if it is equivalent to the CUDA version of genefer.
server: Fixed an issue with loading Cullen-Woodall candidates that prevented loading of multiple bases.

The Cullen/Woodall change was supplied by one of my faithful users. I have not tested the OpenCL genefer change, but the other items have been tested.

You can d/l 5.2.8 from [URL="http://home.roadrunner.com/~mrodenkirch/prpnet_5.2.8.zip"]here[/URL].

Just as a heads-up - Avast antivirus is currently flagging the 5.2.8 release package as a virus. I've reported it to them as a false positive (with a brief description of the program's purpose and source - seeing as how the source code is included it should be pretty obvious that it's benign). :mellow:

It seems that it's catching on the prpadmin.exe program - it's identifying it as "Threat: Win32:Evo-gen [Susp]". Given the "Suspicious" labeling, it's likely the heuristic detector being overly aggressive. The rest of the package (including both prpclient.exe and prpserver.exe) didn't cause any problems, so this shouldn't cause any trouble with the main distribution packages at PrimeGrid.

I have put PRPNet into [URL="http://http://sourceforge.net/projects/prpnet/"]sourceforge[/URL]. What is in sourceforge is version 5.3.0, which is stable, but I'm still testing. The following changes are in 5.3.0:
[list][*]Cleaned up compiler warnings with sockets.[*]Use PRId64/PRIu64 where needed.[*]Convert to using the string datatype for most function parameters.[*]Added notifylowwork= option to the prpserver.ini. When set to a non-zero value, the server will send an e-mail once a day notifying the distribution list that the server is running low on work. This change triggered the refactoring of some server code, specifically the moving of logic from prpserver.cpp to helper classes specific to the server type.[/list]
When it is ready to release I will build executables and post them, but those of you with Visual Studio have the option to d/l and build on your own.

Is there a chance to post here 5.3.0 executables? :tu:

[QUOTE=Cruelty;369331]Is there a chance to post here 5.3.0 executables? :tu:[/QUOTE]

[url]http://www.bc-team.org/downloads.php?cat=7[/url]

I have updated PRPNet to 5.3.1. Here are the changes:

prpclient:
Fix crash when processing wwww work units.
Fix issue where last character of LLR residue was truncated before it was reported.
Fix uninitialized variable in the client.

prpserver:
Fix an issue with length calculation of candidates.

[QUOTE=rogue;372507]I have updated PRPNet to 5.3.1. Here are the changes:

prpclient:
Fix crash when processing wwww work units.
Fix issue where last character of LLR residue was truncated before it was reported.
Fix uninitialized variable in the client.

prpserver:
Fix an issue with length calculation of candidates.[/QUOTE]

Where are the official downloads for Linux 64-bit clients? I downloaded 5.3.0 from [url]http://uwin.mine.nu/PRPNet/[/url], but I don't see 5.3.1 available. I also looked at [url]http://www.bc-team.org/downloads.php?cat=7[/url].

Thanks for helping a newbie. :)

[QUOTE=brilong;373470]Where are the official downloads for Linux 64-bit clients? I downloaded 5.3.0 from [url]http://uwin.mine.nu/PRPNet/[/url], but I don't see 5.3.1 available. I also looked at [url]http://www.bc-team.org/downloads.php?cat=7[/url].

Thanks for helping a newbie. :)[/QUOTE]

I believe(?) that 5.3.1 is PRPNet, not PRPClient.

[QUOTE=brilong;373470]Where are the official downloads for Linux 64-bit clients? I downloaded 5.3.0 from [url]http://uwin.mine.nu/PRPNet/[/url], but I don't see 5.3.1 available. I also looked at [url]http://www.bc-team.org/downloads.php?cat=7[/url].

Thanks for helping a newbie. :)[/QUOTE]

I haven't posted binaries. It's on my to-do list, but I haven't do it. Unfortunately though I cannot build linux binaries.

[QUOTE=rogue;373489]I haven't posted binaries. It's on my to-do list, but I haven't do it. Unfortunately though I cannot build linux binaries.[/QUOTE]

Is there a makefile? I can help.

Luigi

[QUOTE=ET_;373490]Is there a makefile? I can help.[/QUOTE]

Yes.

[QUOTE=rogue;373553]Yes.[/QUOTE]

Ok, then. If you like you can PM me a link or send the code to my old email address, and I will try to build the code for Linux 64 bits and send it back to you.

Luigi

The code is in [URL="http://sourceforge.net/projects/prpnet/"]sourceforge[/URL].

[QUOTE=rogue;373588]The code is in [URL="http://sourceforge.net/projects/prpnet/"]sourceforge[/URL].[/QUOTE]

Hmm,
[code]
makefile:15: *** missing separator. Stop.
[/code]

[QUOTE=kracker;373589]Hmm,
[code]
makefile:15: *** missing separator. Stop.
[/code][/QUOTE]

Hmm. I wonder if a hardtab was changed to spaces. I'll take a look.

Trivial spelling error when you change the prpclient.ini while its running:
"Due to changes int the prpclient.ini file, work classes have been reloaded".

[QUOTE=TheCount;376415]Trivial spelling error when you change the prpclient.ini while its running:
"Due to changes int the prpclient.ini file, work classes have been reloaded".[/QUOTE]

It will be fixed in the next build

Are there server binaries for PRPNet floating around somewhere?

[QUOTE=kracker;389231]Are there server binaries for PRPNet floating around somewhere?[/QUOTE]

Check if you have the latest LLR and other binaries.

[URL]http://www.bc-team.org/downloads.php?cat=7[/URL]

[QUOTE=pinhodecarlos;389268]Check if you have the latest LLR and other binaries.

[URL]http://www.bc-team.org/downloads.php?cat=7[/URL][/QUOTE]

I do. :smile:
But I was wondering if there were any [I]server [/I]binaries somewhere... I have the client already.

[QUOTE=kracker;389231]Are there server binaries for PRPNet floating around somewhere?[/QUOTE]

I happened to have [URL="https://drive.google.com/file/d/0B72y7-pdB73bUGxvR0RqX3RiSWs/view?usp=sharing"]version 5.2.2 (with Windows binaries)[/URL]. Or, if you can build it, you can get the latest source from [URL="http://sourceforge.net/projects/prpnet/"]sourceforge[/URL].

[QUOTE=kracker;389302]I do. :smile:
But I was wondering if there were any [I]server [/I]binaries somewhere... I have the client already.[/QUOTE]

I have compiled one for 64bit. Try [URL]http://www.bc-team.org/downloads.php?view=detail&df_id=95[/URL]

PRPNet 5.4.0 Released
 

I've committed changes for PRPNet 5.4.0. Changes are as follows:
[list][*]Add support for generic searches (pfgw only)[*]Add support for cyclotomic searches (cyclo helper program or pfgw for the client)[*]Fix numerous VS2012 warnings[*]The Windows builds are now suffixed with "64" or "32" for 64-bit or 32-bit[*]The client will always use llr instead of pfgw for k*b^n+c tests (if llrexe is configured)[*]Removed support for clients/servers older than 5.1.0[/list]
I have not tested the code for the generic searches yet, but I have done some testing for the cyclotomic searches.

I am investigating a couple of bugs that exist in 5.3.x, one in Windows and one on the Mac, that still exist in 5.4.0. The one in Windows causes it to crash when getting new work. It only happens on some computers. The Mac build crashes between tests. I've been able to reproduce in the debugger, but it doesn't make a lot of sense. I suspect a bug in the llvm compiler.

To use the new server or client you should merge changes from the updated ini files.

There are no database changes in this release.

Unfortunately I think that this could be specific to OS X 10.10 and valgrind does not build on that release of OS X.

For version 5.3.2, how can I force using LLR instead of PFGW? Would commenting out all pfgw possibilities in the prpclient.ini file accomplish that?

Nevermind. Commenting out pfgw worked fine.

i have 2 questions:
first question:
i would like to do prp-tests on wagstaff numbers with llr
is this possible with prp-server ?
second question:
can i use prp-server without a sql database ?