2009-03-07: updated various bits and the FAQ with OGR-27, fixed Aminet CSPPC233Fix link
2008-11-12: fixed links for OGR-26
This is the usage section for the current RC5/OGR clients. You basically need the latest client for OGR-NG, so don't waste your time with older ones. This section is updated as appropriate after every new release, also see the download section for known bugs and client updates.
The Top 10 FAQ is at the bottom.
How do I install/benchmark/use the client(s)?
You don't need to read this page in its entirety before using the client, most of it is self explanatory, but it should answer a lot of questions. For the client executable names below, substitute dnetc_68k and dnetc_PPC for dnetc_xxx as appropriate.
Also see the Top 10 FAQ, this answers the Top 10 Frequently Asked Questions.
Then there is the Distributed Net FAQ-O-Matic.
Here is the Amiga specific guide:
You can also get a list of the options by running the client with the -help argument
Note to PowerPC users: if you run the client together with the 68k client, make sure to use separate checkpoint files for each client! Normally this should be the case, since the differently named 68k and PPC clients will create checkpoint files with the same stub names as their executables.
How do I attribute my work to the Amiga effort?
The E-mail address you have set in the configuration is used to register you in the Distributed.Net database, any work you submit will be listed under that address. At this point D.Net does not know you want your work to be counted under the Amiga team effort as well, for this they have an automated web based frontend where you can change such settings. Once you have flushed some of your work to the Distributed.Net proxies and their database contains your address and lists it in their statistics (this could take up to 24 hours) you can go to the appropriate webpage and attribute the work you have done and will do to the Amiga team.
To do this, go to the Distributed Net statistics page (this is for OGR, click on links at the bottom for the other projects like RC5), click in the string box below 'Participant Stats' at the top, enter your own E-mail address and click on the 'Search' button. Click on the line for your E-mail on the page that appears, this will take you to the statistics for your own E-mail address. At the bottom of that page you will see a link 'I cannot remember my password' or something to that effect, click on it; you will now be mailed a password by Distributed.net.
Once you have received your password in the mail you can attribute your work to the Amiga team (team number 200). This link is on the Distributed.net server, you can also access it by going to any statistics page (for example the Amiga team's) and clicking on the 'I want to join this team' link at the bottom. At this point a requester for E-mail address and password will pop up, fill in the E-mail address you used and the password you have been mailed. Now all work you do will be counted under the Amiga team as well as under your own E-mail.
Additionally, you can edit some info about yourself ('Edit your Information' under 'Project Stats' at the top of any stats page) again using your E-mail and password (if your browser caches it, you might not have to enter the combo again).
If you change E-mail address it is possible to move your work from your old address to a new one: set your client to use the new address, finish and flush a couple of work units and wait until the new address appears on the D.Net statistics server, then choose edit information for the old E-mail and use the retire link. The onscreen help after that should speak for itself (also you need to get a new password for the new E-mail and set attribution for that too, both as described above). Note that some browsers automatically save authorization info (such as AWeb) or remember it as long as you don't quit the browser, so you might need to temporarily delete old (or new) authorizations, or quit and restart the browser when changing between settings of the old and new E-mail address. This is due to the fact that you are dealing with two different E-mails/passwords, but the basic 'edit your information' link used on the D.Net server does not discriminate between the two (actually you can add login/password in the URL by hand, but lets not complicate things, if you need to frequently change info for multiple E-mail addresses you can ask the coordinator if you can't figure it out) (address obscured to thwart spambots, replace the at with @ and remove the capitalized word).
In case you ever forget your password, simply search for your E-mail (or possibly ID or name if you hide your E-mail) and click on the 'I forgot my password' link, it will be remailed to you then. Should you have changed E-mail, the old one not be active anymore, or misspelled an E-mail so you can't get a password to retire it by conventional means you can mail email@example.com for help.
If you want to stay completely anonymous, you can use rc5(at)amiga.REMOVETHIS.xs4all.nl (obscured here to thwart spambots, replace the at with @ and remove the capitalized word) instead of your own real E-mail address in the client settings, this address is attributing to the Amiga team so you don't need any of the attribution/info change steps outlined above. Note that work from non existent or misspelled E-mail addresses will not be counted; you cannot attribute the blocks from these as the password is sent to a non-existent address. You must change the default E-mail address in the client in any case, since the client default is giving all work to Distributed.Net!
If any of the above doesn't make sense to you, please ask (address obscured to thwart spambots, replace the at with @ and remove the capitalized word).
There is some more documentation in the client archives and on the D.Net site on the other options not mentioned here, such as using an http proxy, sending your blocks by mail if you're behind a firewall, etc. Please consult there. On the E-mail fetching and flushing, you can also visit the miscellaneous page, though D.Net's own FAQs are probably more up to date.
When you start the client it looks at whether a buffer file is present to work on (for example buff-in.rc5). If there is none it will try to connect to the default Distributed.Net proxy and get a new buffer file with work units (as much as specified in your configuration file), then start working on it. If it is present it will read that file and see whether there are unsearched ranges of keys (for RC5) or nodes (for OGR) in it. Again if not it will try to connect to replenish the buffer file. If there is something in the buffer file it will start working on that. The results are saved to the file buff-out.rc5 (or buff-out.og2) and once the out buffer has been filled with the number of units you have set in the configuration (the threshold value) it will flush it to a D.Net proxy and replenish the inbound buffer as well.
Depending on the current effort, client and proxy network you may also have the option to set the preferred size of work units, especially handy for slower CPUs where larger packets would take too long to do (note that you may still get larger packets than your preferred size, this is imposed by the particular proxy for bandwidth reasons).
If you don't have any work units left in the buffer file and the client cannot connect to a proxy to fetch new work, the client will do random units. This is however highly undesirable as most of this work will be duplicated by others and thus be totally useless.
You can set which effort to participate in, currently that's OGR and RC5-72. If you only want to participate in one of them, use the appropriate shell config/GUI option, or make sure the effort you do not want to participate in is switched off by adding '=0' (or ':0') to its name in the client configuration, for example OGR-NG,RC5-72=0. Otherwise the client will rotate between contests.
There is also a specific off-line mode, you do not have to have Internet access or even a TCP stack installed. If you have other networking, use the client on a connected machine to fetch blocks (-fetch option), then you can copy the inbound buffer file (for example buff-in.rc5) over to your non-networked machine and have it crunch on that using the -runoffline argument. Once it's done, you can copy the outbound buffer file (e.g. buff-out.rc5) back to the networked machine and use the client there to flush the blocks using the -flush argument (or appropriate menu option in a GUI client). The buffer files are compatible between platforms, as long as you use the same version of the client on each.
This means you have to be online only when not working in off-line mode and work is to be up/downloaded (or, as of build 464, you can set the client to lurk, i.e. the client will wait until a network connection is detected and then do fetching/flushing). An actual physical connection to the net is not necessary when starting the client even in on-line mode, the client detects whether a connection exists when it needs to do fetch/flush operations. The clients are also multithreaded, which means they keep working while networking occurs, if the update is automatic (i.e. not triggered by hand). All major Amiga TCP/IP stacks are supported through bsdsocket.library (for example AmiTCP and Miami), if you want to use InterWorks' I-Net 225 you need the bsdsocket46.lha archive. For AS225r2 you need another (?) port mapper that translates bsdsocket.library calls to their own socket.library API, though I don't know where to get this if it isn't the same as for I-NET 225, if someone uses this please tell me.
If you start the client from the shell remember to change to the directory where the buffer files are located before starting the client (normally you would also have the client and the buffer files in the same dir), otherwise it will try to connect to the net to get new work and create new buffer files in the directory you are, or work on random blocks if it can't connect or running in off-line mode. You can off course have an icon in WBStartUp for example with a tooltype pointing to the executable somewhere else.
The client can use a checkpoint file (the default is ckpoint.xxx where xxx denotes the effort, like rc5 or ogr) in which it saves the progress every ten minutes or every 10% of a unit (whichever comes first), so if you crash or reboot the packet you worked on will not be lost.
Important: If you are using the PowerPC client together with the 68k client make sure that you use separate checkpoint files for each! Otherwise you're going to have major trouble.. It also makes sense to use separate buffer files as well, since every time a different CPU/core is started on the same packet it will be restarted from beginning.
You can break the client at any time with CTRL-C (progress is saved in the inbound buffer file) or with Esc in the built-in GUI, a menu option or with the -shutdown option from another shell. When you restart it will read the buffer file and start from the last saved position.
It was possible to fetch and flush buffer files by E-mail if you have no direct access, but I don't know if this is still available, see the explanation here. Note: this method requires MIME, at least for when using base64. D.Net may have newer docs on this, see the Faq-O-Matic.
CPU load, priorities and performance tweaking
Normally your system is running a couple of OS tasks and some user programs and is only used for a small fraction of what it's capable of (unless you run some CPU hungry application all the time like a raytracer). When you install the client, it will try to utilize as much processor time as possible, so your system load increases to 100%, all the time. This means that in order to stay responsive and not interfere with your normal activities the client needs to run at a very low priority. Other than setting up priorities properly (which the clients do by themselves), there is nothing much to tweak with regards to performance except for disabling other CPU hungry things, like fancy screensavers.
The clients have their own defaults which should be good for everybody, but you can set them up differently if you wish. There are two ways to do this, through client configuration, or through external tools after the client(s) have started. You can choose from several degrees of 'niceness' using the -config argument. The 68k client's default is priority -120, the PPC clients have two parts, a 68k launching task which runs above 0 and the actual crunching part which runs well below 0, similarly to the 68k client. The clients will automatically set these priorities (and the default settings will be outside Executive's catch range), so you do not need to configure anything here. If you use some tool to adjust these values after the client(s) have started anyway, make sure to wait 15 seconds or so, so everything has a chance to level out after loading necessary data etc. (some versions of the ppc.library have a priority bug which otherwise may cause problems).
Some very old versions of utilities like 'top' that use an extremely low priority (e.g. -127) might not get enough CPU time to display anything, use a higher priority for these. Setting the 68k and PPC client's priority (except for the 68k launching task for PPC) to higher than 0 is not recommended. Also note that if you run a screensaver this might impact performance, since the screensaver's priority is usually above the client's. It also depends on the type of screensaver, using a DPMS based or dimmer/blanker type utility without moving graphics is ok, since these usually only switch off the monitor or open a black screen and wait for mouse/keyboard input, which uses almost no CPU.
If you use the Myzar GUI frontend (this is deprecated), it simplifies priorities to three settings: lowest, low and user. Normally you want this to remain the default: lowest. Myzar supports both the 68k and PPC clients, there is no need to run two copies of it (the same goes for the built in ClassAct/ReAction GUI).
To manually change priorities if you really must: for 68k client and 68k side of PPC client use ChangeTaskPri in the same shell before launching the client (remember that you want a lower than 0 value for the 68k client and a higher than 0 value for the 68k launching part of the PPC client), for the PPC client under PowerUp use ChangePPCTaskPri. Under WarpOS, use the included tool called 'niceppc'. As an aside: WarpOS implements its own naming for priorities: 'niceness'. Not to be confused with 68k priority values, it follows the UNIX convention of higher values being nicer instead of the Amiga convention of lower/negative values being 'nicer'. Some (old) information from the hand of the Myzar author about using the PPC client under WarpOS (also without Myzar) is to be found here.
The second performance enhancement possible used to be tweaking the timeslice value for each client in the ini file(s). This is the amount of operations each client will perform between letting other programs (and the OS) do things, this is a big issue for less well equipped OSes like MacOS (pre OS X at least), but for AmigaOS this only impacts (used to impact in fact) the time between each check for user input, such as a CTRL-C. So the higher the value the less responsive the clients become to user input, but the more time they spend in the core, and thus do more work. This used to be a big issue for the PPC clients, since every OS operation meant a 68k context switch, cache flushes etc., costing valuable time. However, the latest clients implement a much improved and optimized dynamic handling of this, all clients on any CPU will break in no more than 5 seconds on a CTRL-C and always use the optimal timeslice value which is computed internally (and are still faster than the older clients :), so there is no need (or possibility in the new clients even) to fiddle with this.
This has probably long since been fixed in the main source tree but I can't tell since I have never seen it: when starting the client may open/reopen the .ini file several times and cause slowdown/disk access for a couple of seconds (noticable on PPC because of context switches). A side effect of the multiplatform approach is that fetching/flushing may be relatively slow due to disk IO when your buffer contains a lot of small RC5 work units. The solution to this is to minimize buffer size (less units, if/when the client/effort allows it, larger work units), which in turn minimizes the network overhead (or if you must stick to small units for some reason, use RAM: to fetch/flush to/from, although this is not recommended, since you will lose all work on a reboot).
General speed: RC5 is linear and with a known size for each work unit, OGR is non-quantifiable, every work unit might contain a couple of Giganodes, or up to a few hundred. This means that even a PPC could do one single unit all day. If you use the relative speed display (percentages), each dot might therefore take a long time to appear, and the speed between every 2% that a dot represents may vary a lot. Also several CPU specific optimizations are employed where appropriate, such as MMX, AltiVec etc.
If you experience inexplicable problems, crashes, instability
First of all, if you experience problems, and provided you have read this page in its entirety (including the FAQ below) but found no suggestions that fixed your problem, don't hesitate to ask the coordinator (obscured to thwart spambots, replace the at with @ and remove the capitalized word), or on the mailinglist.
Although the current clients are pretty much bug free (that we know of) and are updated when something is found, it is possible that your particular setup is not happy with them, particularly PPC systems are subject to a lot of varying factors that may make client operation troublesome. Below a number of known causes for instability, and appropriate fixes/workarounds are listed.
As with any system, an adequate and clean supply of power is essential, peaks and especially drops in the power (both grid and inside the machine) may cause crashes. Particularly PPC equipped systems (perhaps equipped with an additional GFX card) may suffer from this, since the clients increase CPU power usage close to the maximum. This is not easy to measure without an oscilloscope or surge protectors that have appropriate monitoring, but you might notice it second hand by lights dimming, interference on the audio or by fans changing speed when other power hungry appliances on the grid or hardware like optical drives etc. inside the system kick in. The original power supplies were specced on the low end with a 68030/25, single HD etc. in mind. This may not be adequate if your Amiga is fully populated with a PPC card, GFX card, optical drives, multiple HDs etc. Furthermore, with age components inside the PSU or on the motherboard - especially capacitors - suffer from degradation and widening tolerances, which can cause power problems. On the A4000 for example IIRC some diode in the audio path is wired wrong and will eventually cause problems (on mine it looked like some component leaking acid fuzz and trying to eat through that corner of the mobo). Electrolytic liquid based capacitors are a notorious source of problems, I've had several systems with bulging/brown gunk leaking caps that worked OK until rebooted, or just freezing unexpectedly ever more often. Resoldering new ones solved the boot/stability problems.
Heat is a major source of problems. For A1200 systems with full trapdoors this should be obvious, especially PPC cards generate more heat than the case was designed for. If you have problems make sure that the case has enough clearance from your desktop, perhaps the trapdoor is left open or extra cooling in the form of fans is applied (ambient room temperature is a factor too). In desktops like the 4000, some users reported placing a fan that blows over the RAM chips and CPU has helped. Another tip is to remove a protection plate in the back for an unused Zorro slot, and to rearrange cabling in front of the PSU fan to minimize blocking the airflow and improve circulation. The phase 5 PPC fans have been known to be of a lesser quality and even to fail, if you have the means replace these with higher grade (ball bearing) components. In any case this should be one of those things to check once in a while (together with the clock battery, acid eating through your mobo is just as fatal as a CPU overheating). Cleaning dirty fans (in the PSU too) makes them live longer and use less power. Sometimes you can peel off the sticker protecting the bearing on fans and spray in some lock grease type of oil which will make them run smooth again for a while.
Also heat related: due to varying temperatures in computer use but also daily and seasonal temperature cycles chips, accelerator and other cards may become unseated with time, strange behaviour like mouse, floppies etc. misbehaving, colours on the startup screen etc. could point to this. Reseat (or just firmly push) chips to see if that helps. There are some other causes for this to happen as well, like plain old dirt between contacts or even cold solder joints or microfractures (which can develop due to heat/cold contraction). A lot of equipment lives longer if it's simply always on, as the power and temperature surges/differences when switching on/off will place more stress on components than the extra wear for operating constantly. This will also increase your average client speed :) In fact, I use the client on my laptop to prevent the irritating fan spinup/down cycles and keep it at a level medium speed. The fan is a standard part and can be exchanged when it wears out, my sanity can not :)
A higher than average stack is sometimes helpful too, try whether 200,000 bytes fixes instability. The 68k client sets it's stack to 64 KB on startup, the WarpOS client shouldn't need more than the environment default, but for PowerUp this might help.
Make sure you have the latest PowerPC libraries or flash update as appropriate, the client archives list the minimum version required.
A strange bug has been noted on 233 MHz PPC systems which does not appear to manifest itself on 200 MHz ones, perhaps this applies to faster than 200 MHz in general, or overclocked systems. If you run some utility like CyberGuard you can detect this by looking at it's output and watch for the LR register. There is a utility on Aminet by Emmanuel Lesueur and Frank Wille (the ppclibemu author) that attempts to fix this, here's a snippet from the readme:
Some CyberStormPPC 604e/233MHz boards seem to suffer from annoying random crashes under WarpOS as well as under PowerUp. They might be caused by some kind of hardware bug, which sets bit 0 or bit 2 of the PowerPC's LR register in certain situations. This will result into an instruction access fault, when a program returns from a sub routine. If you ever got an instruction access exception where the first digit of LR is not '0', then this program might solve most of your troubles. Whether this problem comes from a defective board, or a bad power supply, or from too much heat is unknown. But surprisingly it only affects CSPPCs with a 233 MHz CPU. 200 MHz is fine, I have one for comparison! This archive contains two exception handlers, one for PowerUp (CSPPC233Fix_ppc) and one for WarpOS (CSPPC233Fix_wos), which reset those trashed bits in case of an exception which is recognized as the "LR-Bug problem". The PPC program is able to continue after LR was fixed.
The filesystem you use may interfere with client operation, although no specific problems have been detected yet in this respect. Just in case none of the above helps, try a different partition with a different filesystem, or even RAM:
Finally, read the notes in the download section as known bugs are listed there.
If you have any questions left, don't hesitate to ask (address obscured to thwart spambots, replace the at with @ and remove the capitalized word).
Be sure to look at the miscellaneous stuff section, here you will find extensions like icons, log analyzers, scripts etc. that may be interesting and/or useful.
The top 10 Frequently Asked Questions