PRPNet 5.5 Released

[pschoefer]

There are two % missing in WWWWMail.cpp, lines 91-96:

 
if (ii_ServerType == ST_WALLSUNSUN)
   success = NewMessage(toEmailID, "%s special instance %lld (0 %+d) p was found by PRPNet!",
                        searchType, prime, quotient);
else
   success = NewMessage(toEmailID, "%s special instance %lld (%+d %+d) p was found by PRPNet!",
                        searchType, prime, remainder, quotient);

[rogue]

Originally Posted by pschoefer

There are two % missing in WWWWMail.cpp, lines 91-96:

 
if (ii_ServerType == ST_WALLSUNSUN)
   success = NewMessage(toEmailID, "%s special instance %lld (0 %+d) p was found by PRPNet!",
                        searchType, prime, quotient);
else
   success = NewMessage(toEmailID, "%s special instance %lld (%+d %+d) p was found by PRPNet!",
                        searchType, prime, remainder, quotient);

Thanks

[rogue]

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.

• 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.

You can d/l 5.2.6 from here.

[rogue]

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

You can d/l 5.2.7 from here.

[mdettweiler]

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:

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}

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!

Max

[rogue]

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.

[mdettweiler]

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):

cd prpnet/1
nohup ./prpclient
cd ../2
nohup ./prpclient

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 "../binary-name" 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.

[rogue]

Originally Posted by mdettweiler

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):

cd prpnet/1
nohup ./prpclient
cd ../2
nohup ./prpclient

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 "../binary-name" 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.

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.

[mdettweiler]

Originally Posted by rogue

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.

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 run 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 started 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). 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).

[mdettweiler]

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 directory where the LLR binary is located. 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 ../llr64 -w"./" 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 ). 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.

[mdettweiler]

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.

[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

I guess that's what I get for trying to pass arguments directly to LLR via the llrexe= option. 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"...