I'm curious as to why BOINC throttling was designed to be coarse-grained. Is this a more efficient throttling method or is it just easier to implement? It somewhat reminds me of how my microwave works when I set it to x% power - it just runs the magnetron for "y" seconds and then shuts it off for [100y-xy]/x seconds. I never really did like that method of power reduction for my microwave, but I always imagined it was just easier to implement than incorporating a variable-power magnetron. I've noticed if I set the BOINC throttle to 100% and drop the max number of CPU's to 1, that Windows automatically implements an uneven fine-grained throttle of its own: core 1 tends to run around 70% and core 2 around 30%. But I do like the appearance of steady state processing in this configuration.

I'm curious as to why BOINC throttling was designed to be coarse-grained. Is this a more efficient throttling method or is it just easier to implement?

Maybe I'm wrong but I don't know any OS that would allow application to define how much of a CPU it should allow (eg. 50%). The only thing that OS does do (and it should do it well) is to schedule between apps that want to get CPU according to their priorities and across CPUs available (if there are more than one). If you see split 70:30 between CPUs with only one app running then that means that scheduler of your OS of choice doesn't do its job too well.
Which in turn means that the only way of telling OS that an app shouldn't run as much as possible is to suspend it occasionally. Which is, as you noticed, a bit coarse-grained.

Much like your microwave oven that only has magnetron with fixed power. If you place two cups of food into the oven, each cup (or rather its contents) will get roughly half of radiation (and thus energy).

The only way of reducing CPU power scheduled for BOINC app is to reduce CPU's clock. Ubuntu Linux does it for low-priority jobs (BOINC processes are generally such) which was not really welcome by many dedicated BOINC users.

---

Metod ...

Some years back, I used the independent SETI client. I forget the name, but there was a command-line throttling program specifically made for use with the SETI client. However it worked, it wasn't coarse-grained...it would maintain a stable percentage. But that was when I had a single core CPU.

Not sure why there's a 70/30 split when I tell BOINC just 1 CPU...but it does stabilize the overall processing to 50% with no spikes/drops. Of course, BOINC is running multiple projects and also BOINC isn't the only program running. So I suppose there are too many variables for me to make any conclusions.