PRPnet beta test server

[gd_barnes]

Ah, very good guys. I assumed by its use that it must be somehow different than an executable or compiled version of a program. Obviously that's not the case. I guess the term "binary" got it's start from the fact that the executable is what the machine runs, i.e. a bunch of 1's and 0's, in slightly more (but not much more) readable format.

For Cobol programs, the compiled version is usually reflected as a bunch of hex characters that the machine quickly converts to assembler code. The hex chars. have address registers that can be used to refer back to line #'s within the original source code.

As I told Max at a previous time, one of these days I may get into writing some code for some of the prime # programs. I wrote some C+ and Pascal programs in college. I got my start in programming by writing old-time Lotus-123 macros. I had reached a programming burnout stage in my life when I was laid off last year but I can feel the call beckoning me once again; at least as a hobby to have fun with and not as a profession where I have to do it.

Ah, I'm really showing my age now.


Gary

[AMDave]

It comes from the compile process
1 - source file
2 - object file - text based ASM content that can often be executed
3 - binary file - all 1s and 0s - Machine code

1 source file can produce multiple compiled 'binaries' through linking to different object files during the compile process (eg different architecture libraries)

Some compiled 'binaries' are not termed as executable because they cannot be executed by 'you' but are dynamically loaded into memory to extend the execution of a parent 'executable binary'.

You can have binary files that are simply representations, like visual images, video, music etc.. which cannot be run.

Hence the distinction between 'executable' and 'binary'

To be pedantic, we should say 'executable binary' vs 'non-executable binary' LOL

[IronBits]

It is not limited to just .exe files

Binary files are usually thought of as being a sequence of bytes, which means the binary digits (bits) are grouped in eights.
Binary files typically contain bytes that are intended to be interpreted as something other than text characters.

And of course, Gary, Google is your friend.
http://en.wikipedia.org/wiki/Binary_file
http://kb.iu.edu/data/afrw.html
http://www.cs.umd.edu/class/sum2003/.../asciiBin.html

[gd_barnes]

Excellent explanation AMDave. As a former mainframe programmer, I could understand what you mean.

Thanks for the links David. They were helpful.

To really show my age, although I've never written an assembler program from scratch, I have had to modify quite a few of them before they were finally converted to Cobol.

Coding address registers in a program...yuck. I'm glad them days are over. lol Does anyone remember the commands: AP (add packed) and CP (compare packed)? That's all that I can remember from my assembler days off of the top of my head.

[Xyzzy]

http://www.mersenneforum.org/showthread.php?t=10645

[mdettweiler]

The PRPnet server has almost dried out its current workload. Much thanks to all who contributed to the beta test! We uncovered a number of bugs in the client, one of which (the Ctrl-C bug) turned out to be semi-critical.

Mark has released PRPnet 2.1.0 for alpha testing not long ago. I haven't gotten the chance to try it out yet, but it should fix all reported bugs. I will do some preliminary testing myself and then upgrade the G2000 beta test server to the latest version.

Note that the 2.1.0 server is NOT backwards-compatible with the 2.0.4 client you guys are currently using. Thus, I am going to let the current 2.0.4 server completely dry out its workload before upgrading it to 2.1.0, which will have fresh work loaded in it, to give you guys a chance to upgrade your clients. I will post the updated client here when the server is in place.

As may or may not have been mentioned in this thread, Gary is performing a manual doublecheck of the mini-drive ranges that were run through the server. This should confirm for us that PPRnet will, indeed, produce sound results and can be trusted for future first-pass testing efforts.

In addition, for the next batch of work to be run through the server, we will be performing doublechecks on the range of k=300-1001, n=260K-300K. Since we already have first-pass residuals for this range, this will be a perfect job for PRPnet since we can compare residuals and not have to worry about the stability of machines involved. This is a task NPLB would have gotten to in the somewhat near future anyway, so the server will still be helping out with real work.

In the meantime as the G2000 server dries out, it is recommended that you configure a backup server in the client as work will be available somewhat sporadically (due to abandoned tests expiring at different times, etc.). This will ensure that your computer does not go idle in the absense of work from one particular server. To configure a backup server, follow the instructions in the prpclient.ini file's comments and set the server you're adding to a percentage of 0. This will mean that it will only fetch work from that server if no other servers with %>0 can be reached.

A number of servers are in existence that can be used as backup. PrimeGrid has (I think) three of them, the SR5 project has one, and we've got one (G3000) at Conjectures 'R Us, our sister project, currently running Sierpinski base 6 work. All of them except the SR5 server are listed in the prpnet_servers.txt file included with the client.

Max

[IronBits]

You should use the same work over and over until the Server/Client issues with the application are corrected.
This way, you know the results going into the testing range and know what to expect.
Kinda like washing socks. You put 20 pair in, you better get 20 pair out.

[Mini-Geek]

Originally Posted by IronBits

Kinda like washing socks. You put 20 pair in, you better get 20 pair out.

Like that ever happens!

[mdettweiler]

Originally Posted by IronBits

You should use the same work over and over until the Server/Client issues with the application are corrected.
This way, you know the results going into the testing range and know what to expect.
Kinda like washing socks. You put 20 pair in, you better get 20 pair out.

That's why this n=260K-300K doublecheck work will be perfect for the server: we already have one set of results from it (the socks went through the washer once already but we don't know how many made it) and we can compare a second set with those with relative ease. The chances of two erroneous residuals being identical are essentially nil, so even if we've got instability or whatnot on both runs, if anything doesn't match then we can pop it back in the washer for another run and once we get two residuals that match, bingo! Pop 'em in the sock drawer.

Long story short: since erroneous residuals are essentially never repeatable, any errors will be detected quite easily, whether they were in the first or second run. After running a third test we can take whichever residual makes a pair and accept that as the canonical result.

[rogue]

Originally Posted by mdettweiler

Note that the 2.1.0 server is NOT backwards-compatible with the 2.0.4 client you guys are currently using.

A point of clarification. The 2.1 server will work with the 2.0 client, but 2.1 clients will not work with 2.0 servers.

[mdettweiler]

Originally Posted by rogue

A point of clarification. The 2.1 server will work with the 2.0 client, but 2.1 clients will not work with 2.0 servers.

Okay, cool. In that case, I'll just go ahead and upgrade to the 2.1 server as soon as it's finished alpha testing, since users won't be strictly required to upgrade their clients prior to the upgrade.