This post summarizes the advanced options which are available to optimize the performance of the Folding@home client, and special considerations for running F@h on HyperThreaded and dual-CPU systems.
Most of these options are configured when you intially install the Folding@home client; a few must be specified on the command line which is used to launch the client, instead of being configured at installation time.
Requesting large work units
If you have a reasonably fast system (~1.5GHz or better), at least 512MB of RAM, and a broadband Internet connection, you should consider requesting large work units. Large WUs take longer to process, and occupy more RAM while they are running. But Stanford artificially inflates the point value of large WUs, so that they are worth more points per day than "normal" WUs.
To enable large WUs for the console client, answer "yes" when the client asks you "Allow receipt of work assignments and return of work results greater than 5MB in size?"
To enable large WUs for the graphical client, check the "Allow receipt of work assignments and return of work results greater than 5MB in size" check box on the Connection tab of the Folding@home setup screen.
If your system seems to become sluggish and "laggy" after enabling large WUs, this is probably due to increased pagefile activity from the additional RAM used by the large WUs. To fix this, you will either need to disable large WUs, or add 256MB of RAM to your system.
Forcing assembly optimizations
Under most circumstances, the F@h client will automatically detect whether your CPU supports 3DNow! or SSE optimizations, and enable them accordingly. However, there are a few situations where the automatic detection may not work properly -- some older AMD Athlon/Duron CPUs incorrectly default to no optimizations; furthermore, if the client is killed and restarted unexpectedly (e.g. system is turned off without cleanly shutting down the F@h client), assembly optimizations will be disabled by default for the remainder of the current WU.
You can determine whether assembly optimizations are being enabled by looking in your FAHlog.txt file, for a line like "Extra SSE boost OK" or "Extra 3DNow boost OK" whenever you start (or resume) processing of a Gromacs WU. If the "boost OK" line is present in the log, then assembly optimizations are enabled; otherwise they are not enabled.
To ensure that assembly optimizations are always used, specify the -forceasm
option on the command line which is used to start the Folding@home client.
(Note: Assembly optimizations only affect Gromacs WUs. Tinker WUs do not use assembly optimizations at all.)
Requesting experimental WUs
From time to time, Stanford will make new experimental WUs available to the Folding@home community. Only people who have explicitly indicated that they would like to receive experimental WUs will receive them. To request experimental WUs, specify the -advmethods
command line option.
Experimental WUs are a bit of a double-edged sword. Sometimes they are worth extra points (e.g. the "large WUs" were available a couple of weeks early, to people who were running with the -advmethods
option). But you can also receive WUs that haven't been completely debugged, and which may hang or crash out before the WU is complete. (In any case, overall system stability should not be affected... it is only the stability of the Folding@home client that can suffer, when running with -advmethods
Specifying command line options
To specify command line options for the graphical or console client, you need to add them to the shortcut which is used to launch the F@h client. Edit the properties of the shortcut, and add the option(s) you want to the "Target" line. Make sure you separate the options from the program name (and from each other, if you specify multiple options) with spaces.
Shortcut with -forceasm option
If you are running as a service, specifying command line options is a bit more involved. In order to add command line options for a service, you will need to edit the registry after the service is installed. WARNING!! Misuse of the Windows Registry Editor tool can result in serious damage to your Windows installation, up to and including preventing the system from booting. If you damage the registry, you may need to reinstall Windows to get the system working again. You have been warned!
To run the Registry Editor, click Start->Run, type regedit
in the box, and click OK. Now navigate to the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
, and find the registry key with a name that looks like FAH@x:+yyyy+FAH500-Console
(x will be the drive letter where you installed F@h, and yyyy will be the name of the directory you installed it in). Underneath this registry key, there will be a registry value named ImagePath
. Edit the ImagePath
value (double-click it), and append any desired options to the end.
Command line options in the registry for F@h running as a service (Note: this screenshot was taken on a dually system, that's why there are two F@h registry keys listed in the left pane)
Special issues for dual-CPU systems
If your system has dual CPUs, you may want to run multiple copies of the F@h client, to maximize your throughput. A few considerations:
- You must use the console client (optionally running as a service). The graphical and screensaver clients cannot take advantage of dual CPUs.
- You must install two copies of the client in separate directories, and configure each copy individually.
- Each copy must be assigned a different Machine ID. During client setup, answer "yes" when it asks you if you want to change advanced options. When prompted for Machine ID, enter 1 for the first client, and 2 for the 2nd client.
- If you are enabling large WUs on a dually system, make sure you've got an additional 512MB of RAM above and beyond what you need for your foreground apps. Running 2 copies of the client with large WUs enabled can potentially chew up quite a bit of RAM, resulting in pagefile thrashing if you haven't got a lot of RAM to spare.
- Note that running 2 copies of the client on a HyperThreaded system does not
double your throughput, even though the Windows Task Manager will appear to show your CPU usage jumping from 50% to 100%. The actual increase in point production is more like 10-20%, and in some cases may actually be detrimental
to Stanford's science efforts (see Steel's link below). This seemingly illogical state of affairs is due to the fact that Windows does not accurately report CPU usage on HT systems when multiple CPU-intensive processes are running. (On a true dual CPU system, the actual throghput will
in fact nearly double, and running two copies is a clear win if you have two real