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 CPUs.)

Last edited by just brew it! on Mon Feb 28, 2005 11:53 pm, edited 4 times in total.

I'll have no problem if just brew it! wishes to delete this, since it is his thread for the purposes he indicated.

But, with all due consideration for the Stanford people, their view of how we run our own machines, especially hyperthreaded ones, is of no interest to me whatsoever. They want the WUs back faster? That's nice. We're doing them a favor. Beggars can't be choosers. If running a single client delivered the same output and thus ranking as running 2, I'd listen to them. But I'll take the extra 15% or so if I can.

Of course... it's your hardware; if you want to run 2 copies on a HT system, that's your prerogative. Stanford would certainly rather have you folding in a slightly non-optimal (for them) manner, than not folding at all; otherwise, they would detect and explicitly block the running of 2 copies on HT systems!

There may be a practical consideration, however. HT "tricks" the OS into thinking there are 2 CPUs, when there is in fact more like 1.25 CPUs. As a result, the CPU scheduler may not make optimal scheduling decisions when there are multiple CPU-intensive tasks running at the same time. In other words... running 2 copies of F@h on a HT system can have some adverse impact on performance of your foreground apps, even though F@h runs at "Idle" priority. This would not matter at all for a dedicated folding system, but may be a consideration if the system is used for other tasks.

I have 4 or 5 HT systems in my little army here and none of them are running two instances. It just didn't seem worth it for me to have to maintain seperate images for the HT boxes for ~15% more points.

The console version? Yes, just tell it to run as a service when you install it. Make sure you're running 5.02 or better though... To reconfig it if it's already installed run it with the "-config" flag.

I am unable to run the command line version as a service, when asked to do so I say `yes` but then it keeps the command line running, I really want these things running in the background and not on my taskbar. I`m running Vista. Whoopee that`s the problem already

-Playing shooters on a console is like doing brain surgery with an ice-cream scoop-

Jon wrote:I am unable to run the command line version as a service, when asked to do so I say `yes` but then it keeps the command line running, I really want these things running in the background and not on my taskbar. I`m running Vista. Whoopee that`s the problem already

It should run it as a service when you reboot your system after you install it for the first time.

Reboot your computer and then check your task manager to see if the services are running and if your CPU or CPUs are running at 100%.

I have Vista and haven't noticed any differences from how it ran on Win XP.

Jon wrote:I am unable to run the command line version as a service, when asked to do so I say `yes` but then it keeps the command line running, I really want these things running in the background and not on my taskbar. I`m running Vista. Whoopee that`s the problem already

It should run it as a service when you reboot your system after you install it for the first time.

Reboot your computer and then check your task manager to see if the services are running and if your CPU or CPUs are running at 100%.

I have Vista and haven't noticed any differences from how it ran on Win XP.

I rebooted and the client didn't start up. I also checked the registry to determine if it had been installed and I don't see it as JBI indicates in his post above. What else should I be looking at to fix it?

-Playing shooters on a console is like doing brain surgery with an ice-cream scoop-

i just add the necessary flag to the short cut before running it, then run it w/ admin permission. that should work in service mode. however if u are doing SMP, then the service method is not supported yet even though it asks you about it in the setup.