How macOS battery estimation worked and why it doesn’t

For the longest time, OS X had a battery menu extra that used the following method of estimating battery life remaining on a machine: Current Remaining / Current Draw (then converted to HH:MM format). This worked reasonably well for a long time but recently became less accurate.

In the PowerPC days the processor operated at one or two clock speeds and your CPU use didn’t change that often. In the early Intel days, this was still true. Whatever you were doing at the moment the system asked the battery what was up was fairly constant. If a high CPU use app finished (or one started) or you changed the screen brightness you could see the new estimate in a minute or so and it would be accurate for the most part assuming all tasks continued.

Today’s Intel chips and the current scheduler in macOS are far less predictable. The multicore processors are constantly changing clock speed and number of active cores. Hell even since Snow Leopard the system has been using different amounts of power based on the frequency of keypresses. Many uses for power are a lot less consistent than they used to be and with ever more efficient backlights formerly significant sources of power are now less as a fraction of overall power. These combined to make current power draw at any given moment “inaccurate” in the sense that it might be measuring during an extremely short spike (which would give a significantly lower estimate for time remaining) or between periodic spikes (which would give a slightly high estimate).

There is a way to get a better estimate though and I hope Apple gets around to it. The draw needs to be polled much more often and the number used for calculation has to be a rolling average. There’s an API for this but this isn’t something that should be left to third parties, even if I’m one of them.