PRPNet 5.4.3 Released

[rogue]

As some of you already know, PrimeGrid is running PRPNet 5 for the new Wieferich and Wall-Sun-Sun searches. This thread will keep you up to date with the latest PRPNet 5 developments. Here is a summary of changes:

For PRPNet 5.0.0:

all: Added support for Wieferich, Wolstenholme, Wilson and Wall-Sun-Sun searches (note that wwww client only handles Wieferich and Wall-Sun-Sun at this time).
prpclient: For GFN searches, do not do primality test for n >= 262144 because
prpclient: PFGW requires many days to do the test and it doesn't checkpoint.
prpserver: Added localtimehtml= to prpserver.ini
prpserver: Renamed localtime= to localtimelog= in prpserver.ini
prpserver: On server_stats.html page, groups with no remaining candidates to be tested will have a background color of aqua.
prpserver: On Sierpinski/Riesel server stats, display a summary table if multiple conjectures are loaded into the server.

Note: There is no database upgrade script from 4.3.x to 5.0. New tables and columns are only referenced by servers configured for wwww searches.


For PRPNet 5.0.1:

prpserver: Fix bug that prevented some clients from returning completed workunits.
prpserver: Use same e value for all numbers on stats pages for a given project.


For PRPNet 5.0.2:

prpadmin: Added option 10, which allows admins to expire workunits manually.
prpclient: When connecting to a 5.0.2 server and above, don't send acknowledgement that workunit has been received.
prpserver: When connected to a 5.0.2 client and above, don't expect acknowledgement.
prpserver: Added support or admin expire option.
prpserver: When logging SQL statements, substitute bound values for '?' in logs.

Note: In this release I reverted the change from 4.3.0 that required the server to get an acknowledgement from the client before reserving the workunit. Although this prevented the server from having workunits that no client was working on, it caused a worse problem where clients would work on something, then report back to the server only to have the server reject the work because it hadn't received the initial acknowledgement. By adding the "expire" option to prpadmin, this alleviates the problem of lost workunits on the server that have to wait for the time to expire them. Obviously manual intervention is still required, but it is an improvement over how it was handled previously.


For PRPNet 5.0.3:
all: Fix potential crashes found thanks to gcc compiler warnings.
prpclient: Log wwww results and near misses to test_results.log.
prpclient: Added startoption/stopoption 7, to complete all work then shut down without reporting completed work.
prpclient: Normalize work percentage for each configured server if total percentage != 100.
prpserver: Order by descending total score on Team and User stats HTML pages.
prpserver: Add ability to sort by clicking on a column on user and team stats pages. This is done through prpserver.ini configuration.


PRPNet 5.x and PRPNet 4.x servers and clients are fully compatible with one another.

You can d/l 5.0.3 from here.

[rogue]

For PRPNet 5.0.4:
Fix crash in client when wwww near miss is found.

For PRPNet 5.0.5:
Fix bug (introduced in 5.0) that causes client to send Twin and SG workunits back to the server even though the client didn't have to do the test for them.
Fix bug that allows users to not specify any servers in prpclient.ini file.
Change "genefercuda-boinc" to "genefercuda" as they are technically the same program and the server doesn't recognize "genefercuda-boinc".

These changes are only in the client.

You can d/l 5.0.5 from here.

[shauge]

I do work for the PSP project on various machines. One machine stopped getting new work and closed down without any message in the log files so I ran it from a command window (win7). This is a rather long story and I and several team mates have tried a number of ways to get this machine to work normally again, without success. Can you explain what this error message really mean?
I am fairly sure that it is client side and not server side. I run 5.0.4.
Here it the command window output when it finish a work unit and tries to get new work.

[2012-02-08 11:31:09 WEST] Total Time: 10:01:57  Total Work Units: 1  Special Re
sults Found: 0
[2012-02-08 11:31:10 WEST] PSPdc: Returning work to server www.psp-project.de at
 port 8101
[2012-02-08 11:31:10 WEST] PSPdc: INFO: Test for 237019*2^8328778+1 was accepted

[2012-02-08 11:31:10 WEST] PSPdc: INFO: All 1 test results were accepted
Servertype [1551066476] is unknown.  Exiting

I can also get this "Servertype [xxx] is unknown" error message when I download the SW, unpack it in a new folder, do the install and do the update. The xxx number seems to vary with the content of the prpclient.ini file.
A team mate also get this error message, however it behaves somewhat different.

[rogue]

Originally Posted by shauge

I do work for the PSP project on various machines. One machine stopped getting new work and closed down without any message in the log files so I ran it from a command window (win7). This is a rather long story and I and several team mates have tried a number of ways to get this machine to work normally again, without success. Can you explain what this error message really mean?
I am fairly sure that it is client side and not server side. I run 5.0.4.
Here it the command window output when it finish a work unit and tries to get new work.

[2012-02-08 11:31:09 WEST] Total Time: 10:01:57  Total Work Units: 1  Special Re
sults Found: 0
[2012-02-08 11:31:10 WEST] PSPdc: Returning work to server www.psp-project.de at
 port 8101
[2012-02-08 11:31:10 WEST] PSPdc: INFO: Test for 237019*2^8328778+1 was accepted

[2012-02-08 11:31:10 WEST] PSPdc: INFO: All 1 test results were accepted
Servertype [1551066476] is unknown.  Exiting

I can also get this "Servertype [xxx] is unknown" error message when I download the SW, unpack it in a new folder, do the install and do the update. The xxx number seems to vary with the content of the prpclient.ini file.
A team mate also get this error message, however it behaves somewhat different.

I believe that server is running a 4.1 server. You probably need to use an older version of the client.

I'll try to debug this later today to see if my assumption is correct. Even if my assumption is correct, there is the potential that the client has a bug in it.

[shauge]

Originally Posted by rogue

I believe that server is running a 4.1 server. You probably need to use an older version of the client.

I'll try to debug this later today to see if my assumption is correct. Even if my assumption is correct, there is the potential that the client has a bug in it.

The server is ver. 4.0.6, but the reason I think it is client side, is because a lot of other machines seems to work great and because I used Wireshark to moitor the ethernet commuincation. It didn't look like the problem came from the server, even though the text in the error message indicates that.
I would be grateful if you could check what this error message really means. Which might help me get this machine to work again.

(Not sure where to download the old client? The links in the prpnet 4.0.0 thread don't work anymore)

[mdettweiler]

Originally Posted by shauge

The server is ver. 4.0.6, but the reason I think it is client side, is because a lot of other machines seems to work great and because I used Wireshark to moitor the ethernet commuincation. It didn't look like the problem came from the server, even though the text in the error message indicates that.
I would be grateful if you could check what this error message really means. Which might help me get this machine to work again.

(Not sure where to download the old client? The links in the prpnet 4.0.0 thread don't work anymore)

FYI, in case it helps: at NPLB we still have a number of servers (mostly private ones, but one public) on 4.1.4 and they've all worked fine, so far as I can tell, with 5.0.x clients. I'm not sure how 4.0.6 would behave; we do have one remaining private server on 4.0.6 (my own, ironically enough) but I haven't used it since before 5.0.x was released.

BTW: I do have copies on hand of most previous PRPnet versions, if you (or anyone else) need one. I've uploaded 4.0.6 here: http://www.sendspace.com/file/gnq1wm

[rogue]

Originally Posted by shauge

The server is ver. 4.0.6, but the reason I think it is client side, is because a lot of other machines seems to work great and because I used Wireshark to moitor the ethernet commuincation. It didn't look like the problem came from the server, even though the text in the error message indicates that.
I would be grateful if you could check what this error message really means. Which might help me get this machine to work again.

(Not sure where to download the old client? The links in the prpnet 4.0.0 thread don't work anymore)

Is that a private or public server? If it is a private server, then I strongly recommend that you upgrade to at least 4.3.7 or 5.0.5. If it is a public server, set debuglevel=1 and send me the log in an e-mail (not a PM) when this error occurs.

[rogue]

Originally Posted by mdettweiler

FYI, in case it helps: at NPLB we still have a number of servers (mostly private ones, but one public) on 4.1.4 and they've all worked fine, so far as I can tell, with 5.0.x clients. I'm not sure how 4.0.6 would behave; we do have one remaining private server on 4.0.6 (my own, ironically enough) but I haven't used it since before 5.0.x was released.

Although things might be working well on 4.1.4, I hope that you are considering upgrading to 4.3.7 (or 5.0.5). Although you haven't reported any issues with that version, 4.3.7 has bug fixes and much prettier HTML.

[rogue]

I got the log and will fix the problem tomorrow. In the interim using a 4.x client is a valid workaround.

Note that the two servers in question are both 4.0.6. Since both servers are almost out of work, I recommend upgrading them before loading new work into them.

[mdettweiler]

Originally Posted by rogue

Although things might be working well on 4.1.4, I hope that you are considering upgrading to 4.3.7 (or 5.0.5). Although you haven't reported any issues with that version, 4.3.7 has bug fixes and much prettier HTML.

Indeed, upgrading ports 9000 and 12000 to 5.0.5 is high on my to-do list. While they have been working stably with 4.1.4, it is rapidly aging (and does have that annoying cosmetic bug where team and client are reversed on the web pages). The rest of the public servers are already on 4.3.6, though it should be straightforward to upgrade them all to 5.0.5 as well while I'm at it. (The private servers, of course, are scattered across various versions, depending on when they were set up and how recently they've been used...the oldest is 4.0.6, with a few on 4.1.4 and one on 4.3.6. Only two are in active use at the moment, running 4.1.4 and 4.3.6 respectively. They're somewhat of a lower priority but upgrading them is nonetheless on the list long term. )

[rogue]

Originally Posted by mdettweiler

Indeed, upgrading ports 9000 and 12000 to 5.0.5 is high on my to-do list. While they have been working stably with 4.1.4, it is rapidly aging (and does have that annoying cosmetic bug where team and client are reversed on the web pages). The rest of the public servers are already on 4.3.6, though it should be straightforward to upgrade them all to 5.0.5 as well while I'm at it. (The private servers, of course, are scattered across various versions, depending on when they were set up and how recently they've been used...the oldest is 4.0.6, with a few on 4.1.4 and one on 4.3.6. Only two are in active use at the moment, running 4.1.4 and 4.3.6 respectively. They're somewhat of a lower priority but upgrading them is nonetheless on the list long term. )

These:

www.psp-project.de:8100
www.psp-project.de:8101

are still 4.0.6 and still appear to be active.