How DDOGreen Decides When to Save Power

DDOGreen is a small daemon that watches how busy a machine is and moves the operating system between its high-performance and power-saving profiles. On Linux it drives tlp; on Windows it switches power plans. The interesting part is not the switching — that is two shell commands. The interesting part is deciding when to switch, and being disciplined about not switching.

The flapping problem

Take the obvious design: one threshold. If load is above 50%, go to performance mode; below 50%, go to power saving. Now picture a machine sitting at roughly half load — a browser with a few tabs, a language server indexing in the background, nothing dramatic. Load drifts across the line every few seconds.

Each crossing triggers a mode change, and a mode change is not free. It re-applies a whole set of kernel and firmware parameters: CPU governor, energy-performance preference, SATA link power management, runtime PM on PCI devices, wireless power saving. Doing that once is cheap. Doing it every few seconds burns more energy than the power saving recovers, and the user notices it as stutter — the machine feels like it is thinking about something other than their work.

A single threshold guarantees this behaviour for any workload that happens to sit near it. And "near the threshold" is not an edge case; it is what normal desktop use looks like.

Two thresholds and a dead band

The fix is hysteresis, the same idea a thermostat uses so it does not click on and off around the target temperature. DDOGreen takes two thresholds instead of one:

• Load above high_performance_threshold → switch to performance.
• Load below power_save_threshold → switch to power saving.
• Load between the two → change nothing. Stay where you are.

That middle region is a dead band, and it is the whole design. With thresholds at, say, 30% and 70%, a machine hovering at half load simply keeps whatever mode it was already in. To flip it into performance mode the workload has to genuinely climb past 70%; to send it back to power saving, load has to genuinely fall below 30%. Ordinary noise no longer reaches either boundary.

The consequence worth stating plainly: DDOGreen does not always run in the mode its current load would suggest. Two machines at identical 50% load can be in different modes, because they arrived there from opposite directions. That is not a bug to be fixed later — it is the property that makes the daemon quiet.

Why per-core load average, not raw load

DDOGreen reads the one-minute load average and divides it by the CPU core count before comparing against the thresholds. Configuration is therefore expressed as load per core: 0.70 means 70% of one core's worth of work, per core.

This matters because raw load average is not comparable across machines. A load of 4.0 on a four-core laptop means every core is saturated; on a sixteen-core workstation it means the machine is mostly idle. A configuration file written against raw load would have to be retuned for every machine it is deployed to, which in practice means it would be wrong on most of them.

Normalising also makes the logs readable. The daemon reports both the absolute threshold it computed for the current core count and the percentage it came from, so when a machine behaves unexpectedly you can see immediately whether the thresholds landed where you intended.

The one-minute window is itself part of the hysteresis. A shorter average would react to a single compile; a minute of sustained load is a reasonable proxy for "the user is actually working."

Refusing to ship defaults

DDOGreen has no built-in default values. If monitoring_frequency, high_performance_threshold, or power_save_threshold is missing from the configuration file, the daemon logs which one is missing and refuses to start.

This is a deliberate and slightly unfashionable choice. Silent defaults in a program that manages power are a bad trade: a typo in a key name would leave the daemon running happily on values the operator never chose, and the symptom — a laptop that is subtly slower or subtly hungrier than expected — is almost impossible to trace back to its cause. Failing loudly at startup turns a mystery into a one-line log message.

Validation goes beyond presence. Each value is range-checked (monitoring_frequency between 1 and 300 seconds, high_performance_threshold between 0.1 and 1.0, power_save_threshold between 0.05 and 0.9), and then the two thresholds are cross-checked against each other: power_save_threshold must be strictly less than high_performance_threshold.

That last check is the one that pays for itself. Inverted thresholds are individually valid numbers, so no amount of per-field validation catches them — and they destroy the dead band, producing precisely the flapping the design exists to prevent. A constraint that only makes sense between two fields has to be checked between them.

Not trusting the tool you shell out to

On Linux, switching modes means running tlp ac or tlp bat. The obvious implementation checks the process exit code and moves on.

That turned out not to be reliable: TLP does not consistently signal failure through its exit status. So DDOGreen captures the command's combined output and inspects it rather than trusting the return value alone, and it checks up front that tlp is even present on the system before claiming it can manage power at all.

There is a general lesson in this that applies well beyond power management. When you shell out to an external tool, its error reporting is part of its interface, and you have to verify that interface empirically rather than assume it follows convention. A daemon that believes a failed command succeeded will report a mode it never actually entered — and that is worse than crashing, because the logs will look fine.

Designing so the decision can be tested

Power management is hostile to testing. The real behaviour depends on root privileges, on TLP or Windows power plans being installed, and on system load you cannot conjure on demand. Test it directly and you get a suite that only runs on one developer's laptop.

DDOGreen puts every platform interaction behind a narrow interface — ISystemMonitor for reading load, IPowerManager for applying modes, plus interfaces for signal handling and platform utilities — with a factory that selects the real implementation at build time. Tests substitute mocks.

With that seam in place, the threshold logic becomes an ordinary pure-ish unit under test: feed it a load sequence, assert which mode transitions it requests. The scenarios that matter most are exactly the ones that are impractical to reproduce on real hardware — load oscillating inside the dead band, load crossing a boundary exactly once, inverted configuration being rejected before the daemon starts.

The abstraction was not introduced for architectural tidiness. It was introduced because the interesting logic is unreachable without it.

DDOGreen is open source and packaged for Linux and Windows. The threshold logic described here lives in the activity monitor, and the configuration validation in the config loader, if you would like to read the real thing: github.com/abkulakli/ddogreen.