In the days of sub-100MHz DOS PCs, unused CPU cycles were literally wasted: an idle PC waiting for input would be using about the same amount of power as one that is performing calculations, therefore if you have some free RAM then you might as well run a low-priority background task to compute something while your PC is otherwise doing nothing: it’s *free CPU cycles*. In 1996 I ran an automatic composition experiment by installing a small TSR on some school computers (by permission) and it had no ill effects.
However, modern CPUs, which are orders of magnitude faster, use *more electricity* (sometimes many times more) when occupied with calculations as compared to their use when idle. Therefore, allowing your CPU to *remain idle* while waiting for input will save electricity (unless you are using thermostat-controlled electrical heating at the time), and it can save on fan noise and/or component wear. This means people participating in distributed computation efforts are likely to do so only if they feel their contribution is worth those costs.
It might seem to make more sense to run background tasks on servers at data centres, especially ones that obtain their power responsibly. In those places, hopefully nobody has to sit next to the fan and hardware is probably replaced on a regular schedule. However, this decision is probably best left to the administrators of the *physical* hardware. Many commercial servers are “virtual”—they look like separate machines but are actually sharing resources on a single machine—and providers of virtual servers tend to discourage sustained high CPU use *even at low priority*, because the virtualisation software might not be able to combine priority levels across virtual machines.
If you want to participate in a long-running project without it generating fan noise then the best option is probably to run it locally but throttle it to consume only a *small percentage* of idle CPU cycles (which would probably give computing power similar to a full-on CPU from the old days). Some GNU/Linux distributions can install a cpulimit command to throttle an arbitrary process using SIGSTOP and SIGCONT signals if the process itself doesn’t have a throttling option, provided it doesn’t spawn child-processes (as, although some versions of cpulimit *can* be set to monitor for child-processes, doing so typically results in 10%+ CPU being taken by cpulimit itself). Limiting the CPU *will* make work units take longer, and it will still take *some* extra power and warm the hardware, so to be truly “free” it’ll have to be done in a place that’s electrically heated anyway (or from power that would otherwise go to waste) and on hardware whose lifetime you don’t mind reducing.
On the other hand, if *new* hardware is purchased with a warranty and needs to be stress-tested before the warranty expires, and there is a choice of running an otherwise-useless load test or participating in a distributed computation, and the distributed computation makes a good enough test, then CPU cycles that would have been consumed by the load test *are* “free” for the distributed computation as long as one or more of its work units can be completed within the duration of the test. (If using BOINC in a temporary directory, you might want to set --abort_jobs_on_exit so the project ‘knows’ not to wait for the deadline before reassigning any work you’ve interrupted.)
A final consideration is the project’s system requirements, some of which might not be made explicit in the project’s documentation. If your client completely fails to return results, or if it does return results but they’re mostly rejected (check the status), it might be a case of “the developers didn’t expect your OS version/CPU type/etc” and your contributions can’t help until that’s fixed. Also, some projects now prefer programmable GPUs; if you don’t have a suitable GPU for these projects then your CPU-only contribution might be dwarfed by those who do, representing diminishing returns in terms of electricity consumed per computational unit. This does not apply to CPU-only projects, but some of these do still have unstated system requirements (e.g. the “Outsmart Ebola Together” project which ran on IBM’s World Community Grid between 2014 and 2018 declared invalid all results computed on old versions of Mac OS X unless run in a suitably-configured GNU/Linux in VirtualBox).
All material © Silas S. Brown unless otherwise stated. Linux is the registered trademark of Linus Torvalds in the U.S. and other countries. Mac is a trademark of Apple Inc. VirtualBox is a trademark registered by Oracle in various countries. Any other trademarks I mentioned without realising are trademarks of their respective holders.