2008-11-12: fixed links for OGR-26
This is the usage section for the current RC5/OGR clients (v2.8010, i.e. builds 460 and newer). If you for some weird reason still run the older ones (v2.71xx/420 and before), well, uh, don't. Upgrade to the new ones and read below (if you use Myzar, you need at least v2.1 for the latest clients although the use of Myzar is deprecated). Note that a lot of stuff has changed since the previous releases (420 and older). 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)?
Please read this section in its entirety before using the client! It should answer a lot of questions resulting in unnecessary mail. For the client executable names below, substitute dnetc_68k and dnetc_PPC for dnetc_xxx as appropriate.
After you have done that, read the Top 10 FAQ, this answers (guess what :) 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! Of course normally this is 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. That's all fine and dandy, but D.Net cannot know you want your work to be counted under the Amiga team effort as well, so you have to set that. For this they have an automated web based frontend where you can change such things. 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 (for most browsers pressing the enter key is enough). 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 blocks 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 blocks 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 (most browsers will cache it, so you might not have to enter the combo again). Note that this page might be under (partial) construction as new features are added and some of it might not always work.
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, crack and flush a couple of packets 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 blocks 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.ogr) 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.
You also have the option to set the preferred size of work units (only for RC5), especially handy for slower CPUs where larger packets would take too long to do (note though that currently you may get larger packets than your preferred size, this is imposed by the particular proxy for bandwidth reasons. This might change in the future if clients break up those larger packets locally, while sticking to your threshold value).
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 or Myzar 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,RC5=0,CSC=0,DES=0 (CSC and DES are not in the clients anymore, so it's not a problem there). 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.
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.
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 cracking 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, 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, if you use that.
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, 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 become faster on the cracking. This used to be a big issue for the PPC clients, since every OS operation meant a 68k context switch, 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.
The new generation of clients currently implements a somewhat unwieldy way when handling the ini file, on client start it may open/reopen the file several times and cause slowdown/disk access for a couple of seconds (noticable on PPC because of context switches), this is in the main source tree, so it's not known whether this will be fixed. A side effect of the multiplatform approach is that fetching/flushing may be relatively slow due to disk IO when your packets are small and your buffers contain a lot of these (several hundreds). The solution to this is to buffer as large packets as you can, which in turn minimizes the network overhead (or if you must stick to small packets for some reason, use RAM: to fetch/flush to/from, although this is not recommded).
General speed: the faster the CPU, the better obviously. RC5 is linear and with a known size for each work unit, you will see a steady stream of dots in the progress meter. OGR is non-quantifiable, every work unit might contain a couple of Giganodes, or up to 100 some.. This means that even a PPC could do one single unit all day. 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 constantly being developed, 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. Particularly PPC equipped systems (perhaps equipped with a bolt on GFX card) may suffer from this, since the clients increase power usage on any CPU. So make sure you have enough and a clean current (peaks and especially drops in the power grid may cause crashes). This is not easy to measure without special equipment like surge protectors that have appropriate monitoring, or even measuring current inside the system with specialist tools. But you might notice occurences such as a CPU or PSU fan changing speed (and thus noiselevels) a lot, especially when other power hungry hardware like HDs, CD-ROM's etc. kick in. Remember that the original power supplies were specced on the low end (usually with a machine with a smaller CPU, less HD, RAM and cards in mind), this is not adequate if your Amiga is fully populated with all the modern accessories like PPC cards, 48x hairdryers ..oops, CD-ROMs, 10,000 RPM HDs etc. Furthermore, with age components inside the PSU or on the motherboard, such as capacitors, may suffer from degradation and widening tolerances, which can cause power problems. We had one team member experience this and after a long search for and replacement of the culprit component his Amiga was in top shape again.
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.
Also heat related: due to the varying temperatures in a computer (custom) chips, RAM 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). It is often said that 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 keyrate :)
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
|