PRPNet 3.0.0 Released

[rogue]

Originally Posted by MyDogBuster

146226*105^18627+1 and 71816*105^21594+1 are both PRP but NOT prime.

Why did PRPNET 2.4.5 server and client remove remaining tests for those k's from the candidates file?

CLLR and PFGW BOTH test those expressions out as PRP but not prime.

PRPNet assumes that if a number is PRP that it is also prime. If PFGW wasn't configured with the client, then the client is unable to prove primality. If you used an older version of PFGW (pre-3.3.3), then you run the risk that PFGW cannot prove primality.

Since the server is configured as Sierpinski/Riesel, then it will remove other candidates with matching k/b/c.

I STRONGLY recommend that you upgrade to 3.2.4. 2.4.5 is fairly old and I no longer maintain it. It does not take advantage of many of the new features of PFGW and it also has a few changes to handle Sierpinski/Riesel differently.

[rogue]

For anyone still using PRPNet 2.x, I recommend upgrading to 3.2.5 as soon as you can. I will be removing support for the -u option in the 3.3.0 release. There are a number of changes in 3.3.0. Many of them are infrastructure related, but I have also removed some code for supporting older releases. I hope to start my testing of 3.3.0 this weekend and hope to release by the end of May.

If anyone is still using a version prior to 3.2.5, please let me know via PM or e-mail. I will assist anyone who needs help upgrading.

Note that this also applies to clients running 2.x releases. I don't support 2.x clients with 3.x servers. There are many enhancements to the client since 2.x that are of benefit to everyone.

[mdettweiler]

Originally Posted by rogue

For anyone still using PRPNet 2.x, I recommend upgrading to 3.2.5 as soon as you can. I will be removing support for the -u option in the 3.3.0 release. There are a number of changes in 3.3.0. Many of them are infrastructure related, but I have also removed some code for supporting older releases. I hope to start my testing of 3.3.0 this weekend and hope to release by the end of May.

If anyone is still using a version prior to 3.2.5, please let me know via PM or e-mail. I will assist anyone who needs help upgrading.

We've still got 2.4.6 on our lone CRUS server, port 1300, but plan to upgrade it to 3.2.5 soon. It should quite likely be done before your planned release date for 3.3.0. (And if not, we can just upgrade to 3.2.5 first, and from there go to 3.3.0.)

[Xentar]

On my server, I am still using 3.2.0 because I was not sure, if an update was "safe" (means the new version is stable enough).

I think I will update the server and clients this weekend. With this, I think I will update the PFGW version, too.

Do I have to mind something, when upgrading PRPNet? Some database changes?

[rogue]

Originally Posted by Xentar

On my server, I am still using 3.2.0 because I was not sure, if an update was "safe" (means the new version is stable enough).

I think I will update the server and clients this weekend. With this, I think I will update the PFGW version, too.

Do I have to mind something, when upgrading PRPNet? Some database changes?

3.2.5 has been very stable. PrimeGrid has upgraded all servers to that release and the guys over there are quite happy with it. I've had only on report of a crash and I think it was due to too many clients connecting concurrently (> 1000). AFAICT, that was triggered by a client side script that went haywire.

There have been some database changes from 3.2.0. You can find the specific alter statements you need to run in the release notes.

[rogue]

Unless anyone here objects, I want to label 3.2.5 as a beta.

[gd_barnes]

Originally Posted by rogue

Unless anyone here objects, I want to label 3.2.5 as a beta.

From everything I've heard and observed, I would concur with that. It appears to be a nice piece of work.

[rogue]

Originally Posted by gd_barnes

From everything I've heard and observed, I would concur with that. It appears to be a nice piece of work.

Thank you. I will re-release it as 3.2.6 tomorrow with one code change to address tie-breaking when sorting candidates by age

[rogue]

I have put a release for 3.2.6 here:

http://home.roadrunner.com/~mrodenki...pnet_3.2.6.zip

This is a beta. The only change from 3.2.5 is that decimal length has been added as a tie breaker when choosing work that is sorted by age.

[mdettweiler]

Originally Posted by rogue

I have put a release for 3.2.6 here:

http://home.roadrunner.com/~mrodenki...pnet_3.2.6.zip

This is a beta. The only change from 3.2.5 is that decimal length has been added as a tie breaker when choosing work that is sorted by age.

Note to all: the NPLB and personal servers, despite reporting themselves as 3.2.5, are effectively already upgraded to 3.2.6 since Mark provided me with the code for this fix prior to officially releasing 3.2.6. Since there's therefore no code change between my copy of 3.2.5 and the released 3.2.6, upgrading to 3.2.6 is a somewhat low priority.

[Xentar]

Server version 3.2.6
Just found this in the log file:

[2010-05-23 19:58:25 GMT] 183872: 59214*19^40721+1 received by Email: <> User: xentar Client: 01 Program: pfgw.exe Residue: AF5784AB47D21AC9
[2010-05-23 19:58:26 GMT] 184164: 650116*19^40720+1 sent to Email: <> User: xentar Client: 01
[2010-05-23 19:58:29 GMT] 7: ODBC Information: SQL_INVALID_HANDLE:
[2010-05-23 19:58:29 GMT] 7: ODBC Information: SQL_INVALID_HANDLE:
[2010-05-23 19:58:29 GMT] 7: ODBC Information: SQL_INVALID_HANDLE:
[2010-05-23 19:58:29 GMT] 7: ODBC Information: SQL_INVALID_HANDLE:
[2010-05-23 19:58:29 GMT] 7: ODBC Information: SQL_INVALID_HANDLE:
[2010-05-23 19:58:29 GMT] 7: ODBC Information: SQL_INVALID_HANDLE:
[2010-05-23 19:58:29 GMT] 7: ODBC Information: SQL_INVALID_HANDLE:
[2010-05-23 19:58:29 GMT] 7: ODBC Information: SQL_INVALID_HANDLE:
[2010-05-23 19:58:29 GMT] 7: ODBC Information: SQL_INVALID_HANDLE:
[2010-05-23 19:58:29 GMT] 7: ODBC Information: SQL_INVALID_HANDLE:
[2010-05-23 19:58:29 GMT] 7: ODBC Information: SQL_INVALID_HANDLE:
[2010-05-23 19:58:29 GMT] 7: ODBC Information: SQL_INVALID_HANDLE:
[2010-05-23 19:58:29 GMT] 7: ODBC Information: SQL_INVALID_HANDLE:
[2010-05-23 19:58:29 GMT] 7: ODBC Information: SQL_INVALID_HANDLE:

and so on, a few hundred times.

Then:

[2010-05-23 19:59:34 GMT] 183328: ODBC Information: SQL_INVALID_HANDLE:
[2010-05-23 19:59:34 GMT] <EMail> (01): Test 1274644706 for candidate 650116*19^40720+1 was not found
[2010-05-23 19:59:34 GMT] 183328: ODBC Information: SQL_INVALID_HANDLE:
[2010-05-23 19:59:35 GMT] Connect to database failed: [Microsoft][ODBC Driver Manager] Fehler beim SQLAllocHandle-Aufruf für Treiber auf SQL_HANDLE_ENV, native code=0
[2010-05-23 19:59:35 GMT] Not connected to database. Rejecting client connection.

Then I restarted the server. But I saw, that it used about 160MB RAM before restarting. Another memory leak?