Main

Last updated: 12-Nov-2008

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:

Get the Amiga client.
Unpack it to a directory on your harddisk (do not use RAM:).
Run the dnetc_xxx executable(s) in a shell with the -config option (dnetc_xxx -config) or use the GUI. Below the shell operation is used for the various options, but you can do most of them through the GUI as well.
- In the config menu press 1, ENTER, do this again and type your E-mail address. This must be a real address you can receive mail on, otherwise your work is lost for the effort (you can't change settings and attribution on the D.Net pages without a password, which is (once you have taken the appropriate steps) sent to the address you configure here).
  Note: the E-mail address is encoded in the buffer file when a packet is completed, so it is important to set it before you start cracking for all clients you use, offline or not. If you want to remain completely anonymous, enter rc5(at)amiga.REMOVETHIS.xs4all.nl for E-mail address (obscured here to thwart spambots, replace the at with @ and remove the capitalized word), this address is configured to attribute its work to the Amiga team. But you need to set at least this, since the default address is giving away the work to Distributed.Net.
- Change any other config settings you want.
- Save changes to config file with the appropriate option. Repeat for both clients if you use both 68k and PPC! (separate config files are created).
Should you want to change configuration later, run the client with dnetc_xxx -config again.
Alternatively you can edit the dnetc_xxx.ini file by hand, it's ASCII, though leaving it to the config option (or GUI) is safer, since you must know what you are doing here (and most options will not be present in it unless changed from the client default).
Run the dnetc_xxx executable in a shell with the -test argument (dnetc_xxx -test) to see if your CPU is ok (also available from GUI).
Benchmark the dnetc_xxx executable in a shell (dnetc_xxx -benchmark rc5) or from the GUI to see the speed and send us your data. For now we only list the RC5-64 numbers in the member list (for Amigas this is practically the same as RC5-72). RC5-64 rate is still used on the member list pages as a benchmark until that gets updated. You may include the OGR rate in the comment section for now. If you have a slow CPU, use -benchmark2, this will give you a benchmark faster but less accurately. It is BTW better to do some real work and send the average speed data over a number of work units from your logfile instead, this way you get a more accurate picture of real world rates.
For previous releases some people reported setting the stack to some higher number (I use 200,000 bytes for just about anything anyway) helps if you are experiencing trouble (for both client and TCP stack).
Run the appropriate clients (dnetc_68k / dnetc_ppc). You can rename them if you want, just bear in mind that they will look for a settings file with the same name and .ini attached, rename that too if you do (the clients will always use dnetc_68k and dnetc_ppc as internal/shell names), if you want to break them from another shell, use the -shutdown option, this will search for and gracefully shut down any running clients. You need to be connected to the net at this point so the client can download the packets to work on (or get a buffer file from a net-connected machine and run in off-line mode with the -runoffline argument).
The clients can be either used from shell, or through the built in (ClassAct/ReAction) GUI, or alternatively through the MUI frontend called Myzar (deprecated).
If you set the client to show relative progress (percentage within work unit), note that for RC5-72 the progress is linear (each percent takes as long as the next), for OGR the progress is variable (usually later on in the work unit progress is faster).
Don't forget to attribute your work to the Amiga team, see below

You can also get a list of the options by running the client with the -help argument (dnetc_xxx -help). Any arguments used on the shell when launching the client(s) will override those in the .ini file.

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 help@distributed.net 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

The member list on the team stats page is password protected, can I access it?
No, it will remain closed due to spam/privacy considerations (other teams with this list open have been spammed before). Although it is possible to hide behind a participant number or ID instead, there are some issues with that (doesn't work immediately, hard to change if original E-mail not usable anymore etc.)

But what about the interesting info such as seeing who is contributing and comparing speed within the team? This info will be available as soon as a real database is in use on these pages and the raw data becomes available again or I suddenly have ample time on my hands (the full local member list is an 800+ KB HTML file and currently the D.Net stats data is only presented in the form of dozens of consecutive and interdependent webpages, a parsing nightmare). If the latter happens I'm moving the scripts from ARexx to e.g. CGI/Perl, the member list will be filtered on contributing members, anonymous settings, and list rankings in various ways. For now you will have to make do with the static member list.

What project should I concentrate on, OGR or RC5? Or some other effort?
There are three considerations: client availability, user choice and team preference. Since only the distributed.net efforts have Amiga clients this is preferred, other machines/OSes can participate as well. Within d.net OGR is preferred since RC5 has been deprecated (RSA Labs dropped the $10k challenges after RC5-64, so RC5-72 should only be done as a 'parking' effort while no other efforts are underway or clients available for them). This preference also stems from the focus of the effort: a show of unity that is most obvious in the form of team rankings. Since we have good rankings in OGR the choice in that respect should be easy, it is not in the interest of the community to compete within (e.g. a MorphOS team concentrating on RC5-72).

My E-mail changed, can I delete my old E-mail and move my old work to the new E-mail?
Yes! Click on the 'Edit your Information' link on any statistics page (for example the team page at distributed.net), enter your E-mail and password and choose the 'retire this E-mail' link near the bottom, follow instructions from there. All work will be moved to the new E-mail you select (and work you do from then on will get attributed to the team the new E-mail is assigned to). The retired E-mail will not show in the statistics anymore. You can change the information on these pages by resubmitting your machine data and noting the changes (old/new E-mail/nick/etc) or sending the coordinator (address obscured to thwart spambots, replace the at with @ and remove the capitalized word) an E-mail with this data, but this is only for the informational member list on the Amiga effort pages (the site you are looking at now). Note that work attributed previously to a team cannot be reattributed to a new team, only the work you do after you change attribution, but this is a completely separate issue from the E-mail one.

If you do not have the password for your old E-mail address anymore and cannot access that address (so the password for it can't be sent to it anymore) you need to get in touch with help (at) distributed (dot) net, only they can change it for you manually.

Are there PPC and 040/060 optimized clients and are processor specific features like AltiVec taken advantage of?
Yes, there are separately optimized cores for each CPU type and family, including MMX/SSE/AltiVec usage where useful (AltiVec when using the appropriate AmigaOS 4 and MorphOS versions that support it, otherwise the client falls back to whatever your CPU/OS supports). The best core for your CPU is automatically chosen by the client based on a micro benchmark at startup, but can be set manually if you so desire.

Several other possibilities like using the Amiga blitter, DSPs on sound cards etc. have been investigated, but most either do not make sense (would slow things down instead due to extra communication overhead) or are not possible due to lack of resources and documentation (i.e. manpower and manufacturer cooperation). There are some exceptions to this: d.net clients for the Playstation 3's CellBE processor and CUDA/Streams clients for nVidia and AMD/ATI GPUs are in development. EFF's Deep Crack machine (a purpose built machine using large arrays of programmable FPGA processors built just for cracking DES) is a special case as the idea in general is to use hardware already available to the participant, such as a home console/desktop box.

DES III/CSC/OGR/etc. is over, what now? And how long will the team effort continue? RC5-72 for example has 256 times the keyspace of RC5-64, will it take 1250 years to complete if we participate?
We will continue for the forseeable future as this is an open ended project, even if Amiga should be relegated to mostly hobbyist 'retro' computing, this is as much about the spirit as about the technology. Also depends on what new interesting projects come along and of course clients being written for or ported to Amiga. OGR should last us some time if we do all the way up to the higher marks. As distributed computing gains a foothold we will probably have some other interesting things to do like the THINK/LigandFit cancer research.

As for duration, the same question was asked between RC5-56 and RC5-64 and the latter took a lot less than 100 years :) Even though the keyspace is much larger it is offset by increasing participation, and especially computing power. The latter can be categorized by evolutionary growth and revolutionary jumps: Moore's Law (paraphrased: computing power doubles every 18 months) and new technology (integration improvements such as AltiVec quadrupling RC5 rate, massive parallelization using multi-core CPUs and GPUs, future breakthroughs like quantum computing). This means that new efforts always take a lot less time than envisioned when they start (or be concluded the next day if exceedingly lucky, but the same could be said of winning the lottery). To see how the optimist's vs. the pessimist's view is supported by raw data, visit the RC5-64 prediction page. A nice illustration of our own growth is within RC5-56, a lone 060 equipped Amiga would have taken 80,000 years to do as much as we eventually did in 60 days!

What about the E-mail address, should I keep using one of the old default addresses in clients (if your client had one at installation, this is no longer the case!) or put my own address in there?
You can and should use your own E-mail address, for some new efforts you must as otherwise work you do is basically gone. If you want to stay anonymous, you can hide behind a name or ID number on the D.Net statistics pages, for other efforts possibly use some free E-mail address, as long as you can read mail on that because passwords etc. are mailed there, and of course should you win, you have to be notified somehow. Do not use any of the old defaults (containing Cistron for example), these can be considered gone or gone any day for those still in use. Retire your entry into one that has a separate mail address you can use if you still use any of these. Note that you need to attribute your work to the Amiga team when you use your own E-mail address, for a guide on how to do this for OGR/RC5 see above.

I crashed and lost a work unit, help!
For RC5/OGR, with the checkpoint option you should not lose more than 10 minutes or 10% worth of work (whichever comes first), check if you have the checkpoint file option enabled. Should you really lose a work unit, don't worry, the server will reissue work units not returned either by the time the effort is concluded or if/whenever there is an intermediate recycle to close out gaps. In short: you can't disrupt the entire effort by losing/deleting your own assigned work. Once the client reads a work unit from the buffer it will mark it out so other clients/machines fed from the same buffer will not do double work, it will also only keep it in memory and write to the checkpoint file every 10 minutes or 10% of a packet (whichever comes first) to keep progress. On breaking the client it will write progress to the appropriate buffer file. For other efforts each may implement their own type of checkpointing, read the accompanying documentation.

Can I run more than one client on the same machine to crack keys?
Yes, you can, but you should benchmark them each separately as well as running together since it's most likely they will be slower running together than when alternating between them. Unless the clients employ different CPU/GPU cores or regions of the available processor(s) they will compete for cycles and lose overall speed due to context switches, associated cache flushes etc. Some clients may have explicit provisions for something like this (e.g. the d.net client can alternate between efforts). PowerUp equipped Amigas can run one client on each CPU, but take care to use separate checkpoint files for each client; separate buffers is also a good idea. Note: using a (temporary) second instance of the d.net client to fetch/flush work only is alright, although you don't need this since the latest clients support multithreading and will continue work during an automatic update.

I get a lot of network errors, or cannot update at all, is something wrong with my setup?
No, as with any network that is as complex as the Internet there are a number of things why you cannot connect to a proxy or why it's slower at different times, just retry and experiment with different times of day and proxies if you have major trouble. Also set a higher network timeout through client configuration if you are on a slow network. Network outage may occur on the server end too, or especially when major efforts are ending/starting you may not be able to get enough work because others are en masse trying to do the same. Such things are usually resolved within a few days at most. Keep an eye on the news section if it takes longer than that.

Also, if you are behind a proxy or firewall, you need to set up the client for that. There are numerous options with regards to this, for instance you can use HTTP, or even E-mail to fetch/flush work, set the client to use UUEncoding if your network isn't 8 bit clean, set the port numbers to connect on, or the address of a personal proxy if you run one.

I have an unconnected Amiga/other machine or a slow one, can/should I still use it?
Yes! Simply fetch work from a connected machine and transfer the buffer file(s) over. Use the client in offline mode on the unconnected machine, this is settable through the appropriate GUI or shell configuration options. Once the work is done, copy the buffer file(s) back to a connected machine and flush it from there. The buffer files are compatible between different platforms for the same version (note that the buffer format has changed several times, so make sure you use a version that is the same or of the same generation/main version on each machine). Different efforts (than D.Net's RC5/OGR) may handle such buffer files in other ways, the miscellaneous section often points to tools to do this with. Also see the usage section above for other problems.

As for speed, absolutely. No matter how little it can do, every bit counts and for encryption challenges it just might do the one right work unit! Also, the more Amigas on the list, the larger the chance that an Amiga will find the right key.

10 question FAQs are not enough!?
You can join the mailinglist or mail the coordinator (address obscured to thwart spambots, replace the at with @ and remove the capitalized word) for help with your queries, see the contact page.