PRPNet released!

[mdettweiler]

Hi Mark,

I've set up a PRPnet 2.0.4 server over at NPLB for a beta test. A number of users have reported some bugs and feature requests, some of them minor, others a bit more crucial:

-Could other LLR configuration options be added in the prpclient.ini as is already done with affinity? Specifically, the ones requested were Priority and OutputIterations.

-On the server-generated stats pages it says "PRPs found" whether or not they are actually proven primes. A simple fix for this would be to change it to "PRPs/primes found"; a more advanced solution would be to add another column, and have one for "Unproven PRPs" and another for "primes found". Unproven PRPs would be move to the primes found column when a client reports a successful primality proof with PFGW.

-The menu regarding what to do with the remaining tests in queue after a Ctrl-C works fine on Linux, but not on Windows. On Windows the client behaves like this:

C:\Files\Prime\PRPnet>prpclient
Client will run in idle class.
[2009-04-27 22:11:00 GMT] PRPNet Client application v2.0.4 started
[2009-04-27 22:11:00 GMT] User name Mini-Geek at email address is [removed]
Resuming test of 3021*2^428009-1 at iteration 110610 [25.84%]
 
 Caught signal.  TermiWhat should the client do with untested workunits?
natin  1 = Abort all (including current tests)
g.  2 = Report completed tests to server
 
  3 = Nothing
Choose option: [2009-04-27 22:11:18 GMT] G2000: Could not open file [lresults.txt] for reading.  Ass
uming user stopped with ^C

This has turned out to be a bug of rather higher severity since it doesn't allow a user to clear out their queue without leaving some WU's to expire on the server.

-Could fourth option be added to the Ctrl-C menu, to allow a user to finish the current test in progress, and report it back to the server, and all other tests as cancellations? Alternatively, it could finish all work in queue, report it, and exit without grabbing more.

The only other complaint was in regard to the client's small amount of idle time during server communications, which I understand would be somewhat difficult to fix due to the nature of the PRPnet client's design, and is somewhat negligible besides. Other than that, though, all seems to be well.

Max

[rogue]

Originally Posted by mdettweiler

Hi Mark,

I've set up a PRPnet 2.0.4 server over at NPLB for a beta test. A number of users have reported some bugs and feature requests, some of them minor, others a bit more crucial:

-Could other LLR configuration options be added in the prpclient.ini as is already done with affinity? Specifically, the ones requested were Priority and OutputIterations.

-On the server-generated stats pages it says "PRPs found" whether or not they are actually proven primes. A simple fix for this would be to change it to "PRPs/primes found"; a more advanced solution would be to add another column, and have one for "Unproven PRPs" and another for "primes found". Unproven PRPs would be move to the primes found column when a client reports a successful primality proof with PFGW.

-The menu regarding what to do with the remaining tests in queue after a Ctrl-C works fine on Linux, but not on Windows. On Windows the client behaves like this:

C:\Files\Prime\PRPnet>prpclient
Client will run in idle class.
[2009-04-27 22:11:00 GMT] PRPNet Client application v2.0.4 started
[2009-04-27 22:11:00 GMT] User name Mini-Geek at email address is [removed]
Resuming test of 3021*2^428009-1 at iteration 110610 [25.84%]
 
 Caught signal.  TermiWhat should the client do with untested workunits?
natin  1 = Abort all (including current tests)
g.  2 = Report completed tests to server
 
  3 = Nothing
Choose option: [2009-04-27 22:11:18 GMT] G2000: Could not open file [lresults.txt] for reading.  Ass
uming user stopped with ^C

This has turned out to be a bug of rather higher severity since it doesn't allow a user to clear out their queue without leaving some WU's to expire on the server.

-Could fourth option be added to the Ctrl-C menu, to allow a user to finish the current test in progress, and report it back to the server, and all other tests as cancellations? Alternatively, it could finish all work in queue, report it, and exit without grabbing more.

The only other complaint was in regard to the client's small amount of idle time during server communications, which I understand would be somewhat difficult to fix due to the nature of the PRPnet client's design, and is somewhat negligible besides. Other than that, though, all seems to be well.

Max

Most of these won't be an issue. I don't know if I can fix ^C on Windows, but we'll see. As for idle time, I would have to multi-thread the client, which I am loathe to do. I will ask that all requests be sent to me via e-mail as I keep the e-mail history and can respond more quickly than through the forum.

[rogue]

Originally Posted by rogue

Most of these won't be an issue. I don't know if I can fix ^C on Windows, but we'll see. As for idle time, I would have to multi-thread the client, which I am loathe to do. I will ask that all requests be sent to me via e-mail as I keep the e-mail history and can respond more quickly than through the forum.

The ^C issue is harder to resolve than I had expected. The code seems to be correct, but the process terminates as soon as it tries to prompt the user for an action. I will probably have to resolve this be pulling a value from the ini file. If there are any Windows geeks out there that would like to help me I would appreciate it.

[rogue]

Originally Posted by rogue

The ^C issue is harder to resolve than I had expected. The code seems to be correct, but the process terminates as soon as it tries to prompt the user for an action. I will probably have to resolve this be pulling a value from the ini file. If there are any Windows geeks out there that would like to help me I would appreciate it.

I am working for a fix for ^C in Windows. As for completing the current test, then reporting, that is trickier. I need to think more about it.

[mdettweiler]

Originally Posted by rogue

I am working for a fix for ^C in Windows. As for completing the current test, then reporting, that is trickier. I need to think more about it.

Perhaps it would be simpler to instead have the client just finish up *all* work currently in queue (not just the current test) and then not request any more?

[rogue]

Originally Posted by mdettweiler

Perhaps it would be simpler to instead have the client just finish up *all* work currently in queue (not just the current test) and then not request any more?

As I said, I need to think about it.

[rogue]

I have released PRPNet 2.1.2. Here is a highlight of the changes:

Here is a list of changes to the server:

• Add user element to completed_tests.log.
• Look for correct return codes when sending e-mail using SMTP authentication.
• Replace %T format when calling strftime as Windows doesn't support it and will terminate application when it find it.
• Changed user stats structure hoping to eliminate stats collection issue.
• Send "End of Message" to client after receiving work done as a semaphore to the client to stop reading from the socket.
• Add Primes Found and GFN Divisors found to Fixed k/b/c server user stats HTML.

Here is a list of changes to the client:

• Modify handling of ^C with Visual Studio build used by Windows.
• After returning work, continue to read from socket until getting "End of Message" semaphore.
• Delete all temp files after returning results to the server.
• Capture FFT rounding errors from PFGW and re-issue test using -a option.
• Write servertype to save file so that workunits can be correctly handled upon restart of the client.
• When restarting the client, ask user what to do with workunits that have been saved.

You can d/l the software from here. The zip package includes 32-bit Windows builds (via VIsual Studio) of the client and server.[/QUOTE]

[Svenie25]

Maybe a stupid question, but is it possible to run PRPNet as "stand-alone" offline? Means, I use my NewPGen-file to feed and use no server.

[rogue]

Originally Posted by Svenie25

Maybe a stupid question, but is it possible to run PRPNet as "stand-alone" offline? Means, I use my NewPGen-file to feed and use no server.

No. That is why you would use LLR/phrot/pfgw with the file produced by NewPGen. If you multiple cores, then you could use the server to manage the work across those cores.

Am I missing something in your need to run a client by itself?

[Svenie25]

It´s because in the near future, then I start my private TPS, I thought I could test the found primes at the same time with pfgw.
I thought about setting up my own server for my boxes, but really have no idea how to do so...

[mdettweiler]

Originally Posted by Svenie25

It´s because in the near future, then I start my private TPS, I thought I could test the found primes at the same time with pfgw.
I thought about setting up my own server for my boxes, but really have no idea how to do so...

Well, actually there's no need to re-test the primes with PFGW. The primes found by LLR for base 2 numbers are definite primality proofs--no further testing necessary.

If you mean that you'd like to run GFN tests for k*2^n+1 primes, well, usually the way a TPS search works is that you test the Riesel side (k*2^n-1), and any primes found are then automatically tested for the Proth side (k*2^n+1) additionally. So, in that case, you definitely won't have any Proth primes to GFN test unless you actually find a twin, which will probably be rare enough that running the GFN test manually would not be a big deal.

(Somebody correctly if I made a big gaping erorr in my reasoning regarding the GFN testing stuff--having never been involved in a project that does GFN testing on Proth primes, I am largely clueless on the specifics of how things work and only vaguely know the process.)