The CPU is easy to schedule. When a process comes along and wants more CPU percentage FAH gets out of the way seamlessly. Momory allocation is more difficult. When something comes along and wants to use the RAM that FAH wants the system writes the FAH part to the paging file. The access speed to recover what was saved is 40 times slower than the time it takes to access it if it were in RAM. There is no way to limit the amount of RAM allocated to a WU except by lying to the assignment server and getting a smaller WU. These are generally worth fewer points so we like to avoid doing that.
If you're going to be doing something that kicks your computer's butt I definitely reccomend opening up services.msc and stopping FAH.
This is a problem faced by all DC programs. It's just that Folding@Home seems to be one of the msot demanding projects in terms of RAM footprint. No other projects (AFAIK) have naything that comes near the 350 MiB hunger that is a QMD. It's not really that big of an issue though. The only time it comes into play is when you're installing on an older machine that does not have a lot of idle RAM during normal use. If you have a machine like that disable the >5 MiB WU option when configurating. THe WUs that can be had with that setting all come in at less than 40 MiB RAM used.
If you're going to be doing something that kicks your computer's butt I definitely reccomend opening up services.msc and stopping FAH.
This is a problem faced by all DC programs. It's just that Folding@Home seems to be one of the msot demanding projects in terms of RAM footprint. No other projects (AFAIK) have naything that comes near the 350 MiB hunger that is a QMD. It's not really that big of an issue though. The only time it comes into play is when you're installing on an older machine that does not have a lot of idle RAM during normal use. If you have a machine like that disable the >5 MiB WU option when configurating. THe WUs that can be had with that setting all come in at less than 40 MiB RAM used.
Last edited: