bruce wrote:At this forum, it's natural to find folks who feel F@H is superior to BOINC. We don't promote BOINC, but there are a number of good projects that use the BOINC infrastructure so we don't bad-mouth it either.
What's really important is that you manage your resources carefully.
Turn-around time in FAH is critical, and unlike BOINC, it's not sufficient to just meet the deadline.
While turnaround-times doesn't matter to some of the projects, like SETI@home, it does matter to others, and example GPUGRID, just like Folding@home, therefore gives a fast-turnaround-time-bonus...
For that reason, we recommend against sharing resources between FAH and BOINC. Even though you may make it work, FAH would be better off if you ran one or the other or you decided exactly which of your resources you're willing to DEDICATE to FAH.
Each FAH Uniprocessor client needs a dedicated CPU (not a HT virtual processor or a BullDozer core that shares a FPU with another task). The FAH SMP client needs all of your CPUs to be dedicated to it. The FAH GPU client is a bit strange because it's performance depends both on which type of GPU you have and how much CPU is available to it. An ATI GPU will use most of a single CPU, though it can be a virtual cpu). A Fermi GPU will use quite a bit of a CPU. Pre-fermi NV GPUs need very little CPU time.
As long as FAH can have dedicated resources or you can manage CPU priorities so that BOINC only uses the CPUs when FAH has nothing to process, we welcome you to run both. If not, I recommend you run BOINC one week and FAH the next week, carefully using the -oneunit flag (or the Pause When Done menu option) to finish the current WU before shutting FAH down for more than a short period.
Running FAH's Nvidia, Ati or single-cpu-client alongside BOINC is easy, it's just to decrease #BOINC-cores accordingly (if cpu-client). It's also easy to run FAH's SMP-client alongside one (or more) BOINC GPU-projects.
But, atleast my opinion is the "pay" is too low on the FAH-single-cpu-client compared to the SMP-client to be worth it, assuming fast enough computer to run SMP-client that is, so I'll recommend to run the SMP-client and BOINC together this way:
FAH-side, a small batch-file with the cmd-client, something like this (*):
Code: Select all
:START
call fah-smp-client.exe -oneunit
call sleep 86400
goto START
In case doesn't already have it, you'll need to download a Sleep-application. The 86400 is how many seconds wait until should start FAH again, it equals 24 hours, so to increase/decrease the wait just increase/decrease this number.
BOINC-side, a cc_config.xml located in BOINC's data-directory, minimum including:
Code: Select all
<cc_config>
<options>
<exclusive_app>FahCore_a3.exe</exclusive_app>
</options>
</cc_config>
Then neccessary, just add more lines with <exclusive_app> then other FAH-cores would be used.
There's also a <exclusive_gpu_app> that can be used in case would run both a FAH-gpu-client and a BOINC-GPU-project (except GPUGRID that is).
The advantages of running things this way, compared to running "1 week FAH, 1 week BOINC", is that BOINC will immediately take-over in case problems getting work from FAH, won't sit idle waiting on uploads/downloads and no idle time switching between clients. Depending on BOINC-project, in some BOINC-projects 7 days is the deadline so crunching one week FAH would either mean some wu's crunching-time would be wasted, or, cpu-cores is part of the time idle waiting until all BOINC-work is finished before can startup FAH again. Exiting client instead of pausing will also waste anything crunched since last checkpoint, depending on project this can be everything from 1-minute between checkpoints upto multiple hours between checkpoints, so a shutdown at the wrong point can potentially waste many hours crunching.
So for anyone wanting to run both FAH and BOINC on cpu's, by using BOINC's <exclusive_app>-mechanism you'll get the same turnaround-time running FAH as if you're not running BOINC at all, you'll maximise FAH-points/day by running SMP-client instead of single-cpu-client(s), and you'll not sit idle for various reasons.
(*) Not tested with v7-client.
That's a decision that you have to make for yourself.
When that is said milkyway was a resourcehog,no problems if it is dedicated but I might run some other apps on that pc,a nightmare to vnc into it and everything hangs,and gpugrid have several clients or workgroups,some of them crashed for no reason even on stock,for gpugrid they have advices on their forum to solve much of that so that worked perfectly in the end,one occasional crash but f@h crashes too from time to time