Spare processor cycles

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 (of a type that does not involve a heat pump) at the time. It can also 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. On the other hand, some providers actually encourage CPU usage by saying idle machines will be reclaimed, but they might have rules about what kind of calculations are acceptable.

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), as long as the project does not need your results quickly (not all projects are suitable for this). 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, such as if it's going to be replaced on a schedule anyway.

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. For example, 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, and in mid-2024 the Folding@Home project started to give single-core x86-64 CPUs deadlines they were unable to meet, automatically erasing their work once it became too late.