There are optimised builds for various Intel and AMD platforms. Please pick the one that matches your platform as it will yield the best performance, and ensures program stability.

All these binaries have been statically linked, hence their size.


INSTALLATION

The program _requires_ a file in the same directory as from where it's started.
This file should look like this:
--------------------------------------------------------------------------------
[UserInfo]
Email=
UserID=
TeamID=

[SystemInfo]
NodeID=
Processor=D
--------------------------------------------------------------------------------

After Email, enter the email address you want to use for this project.
UserID is to hold the name under which you want to appear in the rankings. This has to be between 6 and 20 characters in size.
Like UserID, TeamID contains a free-form name for the team under which you want to submit your results. Leave blank to not be with a team. Team name must be under 20 characters in size.
NodeID is assigned by the server. Keep it blank if you didn't get one yet, else copy it from one of your other opx.cfg files.
Processor was a setting from the Windows client. We require its presence, but don't use it.


RUNNING

When you start the program, it will not become a daemon. Maybe a new version will have this. Informational messages are sent to STDOUT (the screen). If you want to run the program in the background, start it like so:

./pxclient > pxclient.log &

When running, there will be 3 pxclient processes. One does all the work, whereas the other two are timer processes.
Once every 5 minutes the first timer process will cause the main process to display performance statistics. Once every 3 hours the second timer process will cause the main process to try to send its data to the server. Since the main process is sending the blocks, it will block until the sending of the data has ended. If the sending fails, it'll just keep on adding keys to the keyfile until the next time the sending should be attempted, hopefully with more success.
To stop these events from happening, you can kill the timer processes. They will appear as zombies (the ps program will list them as <defunct>) and remain that way until the program has stopped.

You can force the program to display performance statistics immediately by sending it the SIGUSR1 signal. (kill -USR1 <processid>)
Similarly, you can force the program to send out its key file (xbx_send.dat) by sending it the SIGUSR2 signal. (kill -USR2 <processid>)
To end the program, gracefully, send it the SIGHUP signal.

Note that the program will assign itself a priority of 20, meaning that just about any program on the system will be given precedence by the kernel. This should make the process only eat up the idle cycles on your system.


PERFORMANCE

I have 3 types of systems available to me, a Celeron 900 (C) using kernel 2.4.19, an Intel P3-733 (P) using kernel 2.4.19 and an Athlon-XP 1700+ (A) using kernel 2.4.19-gentoo-r10.
Below is a table of the performance the various builds brings to the available platforms.

+-------------+-------+-------+-------+
|             |   C   |   P   |   A   |
+-------------+-------+-------+-------+
| i486        |  54.4 |  41.6 | 105.6 |
| pentium     |  41.6 |  31.0 |  96.0 |
| pentium-mmx |  44.8 |  35.2 | 102.4 |
| pentiumpro  |  67.2 |  51.2 | 124.8 |
| pentium2    |  67.2 |  51.2 | 128.0 |
| pentium3    |  67.2 |  54.4 | 128.0 |
| k6          |  51.2 |  41.6 |  99.2 |
| k6-2        | CRASH | CRASH | 103.2 |
| k6-3        | CRASH | CRASH |  99.2 |
| athlon      | CRASH | CRASH | 131.2 |
| athlon-xp   | CRASH | CRASH | 133.8 |
+-------------+-------+-------+-------+


WHEN THINGS FAIL

I'm hopeful this program will run with excellent stability for some time to come. If however the program were to crash, try to figure out what may have caused it and let me know. If you're using an optimised build, try going back to a build for an older processor type. On current systems, the i486 build does remarkably well.
When the main program crashes, its siblings will remain active. Just manually kill them.
Head over to the project forums and report the issue you've experienced. Hopefully we'll be able to fix it.


TODO

- Timeouts on the networking functions. They now potentially block forever.
- Daemonisation (and the subsequent logging to a file that will be needed)
- Userfriendly way of setting up the client's opx.cfg file
- Parameterise the stats and flush threads.
- Parameterise the server/port
- Proxy support?
