PRPNet 5.5 Released

[Happy5214]

My upgrade of the HTML markup to HTML5 that I started many months ago is finally ready for review. It can be seen at https://github.com/happy5214/prpnet/tree/html5.

[rogue]

Originally Posted by Happy5214

My upgrade of the HTML markup to HTML5 that I started many months ago is finally ready for review. It can be seen at https://github.com/happy5214/prpnet/tree/html5.

If I add you as a developer to the project on sourceforge, would you be willing to merge your changes into it? I ask because you have made a lot of changes and I fear not merging your changes correctly.

Also on my wish list is to replace sprintf with snprintf and vsprintf with vsnprintf so that modern compilers don't squawk.

[Happy5214]

Originally Posted by rogue

If I add you as a developer to the project on sourceforge, would you be willing to merge your changes into it? I ask because you have made a lot of changes and I fear not merging your changes correctly.

Also on my wish list is to replace sprintf with snprintf and vsprintf with vsnprintf so that modern compilers don't squawk.

I wouldn't know how to merge them either, since I don't know how to use SVN. My background is with code reviews using branches or (in the case of Wikimedia) patch commits, and I'm not accustomed to having the right to commit directly to someone else's repository. Would sending you a patch file off the latest SVN revision with my changes suffice?

[rogue]

Originally Posted by Happy5214

I wouldn't know how to merge them either, since I don't know how to use SVN. My background is with code reviews using branches or (in the case of Wikimedia) patch commits, and I'm not accustomed to having the right to commit directly to someone else's repository. Would sending you a patch file off the latest SVN revision with my changes suffice?

Can you just send the files that you update? A number of changes were committed this week. This way I can easily see the diffs without having to do a merge.

[Happy5214]

Originally Posted by rogue

Can you just send the files that you update? A number of changes were committed this week. This way I can easily see the diffs without having to do a merge.

Attached.

[rogue]

I have posted PRPNet 5.5 over at sourceforge. Here are the changes:

 prpserver:  Added HTML5 support.
             Updated prpnet.css for HTML5 and provided default URL for it in prpserver.ini.
             Replaced sprintf and vsprintf with snprintf and vsnprintf.
             Added minutesbetweenstatsrefresh= configuration option to prpserver.ini.
             Fixed Sohpie-Germain server support.
             Fixed length calculation for Carol/Kynea servers.
             Fixed sorting of candidates for work selection.

 prpclient:  Add support for new -A parameter for pfgw.  This allows targeting pfgw to
             a specific CPU (Windows only).

[mdettweiler]

I found a funny little "bug" (maybe not a bug so much as unexpected input) in prpclient today regarding parsing LLR's lresults.txt file when LLR has logged messages relating to roundoff errors. I noticed that one of my unattended machines' clients had stopped crunching, and found that its prpclient had stopped with this message in prpclient.log:

[2023-04-01 16:07:23 EDT] G1300: Could not find RES64 residue [lresults.txt].  Is llr broken?

Seeing that there was indeed an lresults.txt in the directory, I examined it and found that it was unusually verbose as a result of LLR having detected a round-off error and restarted from an earlier checkpoint:

Iter: 3798469/3785205, ERROR: ROUND OFF (0.401769273) > 0.4
Continuing from last save file.
Resuming probable prime test of 681041*2^5562306-1 at bit 2435691 [43.78%]
Using FMA3 FFT length 560K, Pass1=448, Pass2=1280, clm=4, 4 threads, a = 3, L2 = 746*466
681041*2^5562306-1 is not prime.  RES64: 407FCCFFB8828E21  Time : 4134.141 sec.

Looking at the prpclient source code (LLRProgram.cpp line 136 in the current SVN r112; the client I experienced this with was compiled from r107, but the code in question hasn't changed), I think I see why this happened:

• In line 136, the while-loop condition examines each line in lresults.txt to see if it contains an actual test result, by looking for substrings such as "RES64", "is prime", "probable prime", etc.
• However, down in line 173 where the line is checked in more detail to determine the actual result, it compares against the more precise substring "is a probable prime".
• Hence, line 136 incorrectly identifies the "Resuming probable prime test" line as the one to parse for the result, but line 173 correctly recognizes that this does not contain an actual positive PRP result. Since at that point the code thinks it's already found the result line, it doesn't continue searching the file to find the real result line.

I'm guessing the best fix here is to change line 136 to compare against the more precise substring "is a probable prime", just like 173 does. That way, prpclient will keep searching the lresults.txt until it either finds a line it knows how to parse, or reaches the end of the file and concludes that LLR was stopped intentionally.

Note for reproducing/testing this issue: the reason LLR is doing a PRP test instead of an LLR test on this number is because I'm using LLR2 (v1.3.3) with the "-oGerbicz=1" option set (using the "batch file/shell script trick" discussed in this thread for setting command-line options), which for k*2^n-1 will force PRP mode so it can do Gerbicz error checking. By default without command-line options, LLR2 behaves like older (pre-Gerbicz) versions of Jean's mainline LLR, defaulting to an unchecked LLR test instead of a PRP. The recent versions of Jean's LLR (e.g. the current 4.0.3) now default to PRP for k*2^n-1 candidates in order to enable Gerbicz checks (unless -oErrorChecking=0 is set), so they may produce similar lresults.txt output. (I'm currently using LLR2 since it doesn't suffer the excessive overheads that Jean's current Gerbicz implementation incurs.)

Since the particular roundoff error I experienced here appears to be non-reproducible (probably a hardware error caught by the Gerbicz checks!), the easiest way to test this may be to manually write contents like the above to lresults.txt while PRPNet+LLR is running, then use Ctrl-C to terminate LLR so prpclient will check the lresults.txt for a result. (At least, that's how I worked around the issue to get this particular result submitted to my server without re-running the test. )

[rogue]

I changed the text to "is a probable prime".

[mdettweiler]

Thanks! Seems to have done the trick. My CRUS clients are giving the new code a pretty good workout right now as they work through an FFT boundary region with lots of (apparently at least somewhat reproducible) roundoff errors...haven't had any stuck clients since upgrading to PRPNet 5.5/r113 earlier today. (Was getting one every few hours on the old version.)

[MischaR]

I think the DecimalLength calculator for Carol-Kynea is incorrect. The formula used is:
floor(log10(base) * (n * 2) / 3 + 1)

But I think it should be
floor(log10(base) * (n * 2) + 1)

Few examples:

sum                 used formula  suggested formula  actual length
(10^123-1)^2-2      83            247                246
(10^1061+1)^2-2     708           2123               2123
(60^11307+1)^2-2    13404         40212              40212
(290^124116-1)^2-2  203749        611246             611246

[Happy5214]

Originally Posted by MischaR

I think the DecimalLength calculator for Carol-Kynea is incorrect. The formula used is:
floor(log10(base) * (n * 2) / 3 + 1)

But I think it should be
floor(log10(base) * (n * 2) + 1)

I think it might have been flipped with the Wagstaff case below it (though the formula looks slightly incorrect in that case too).