A week ago I attended the KDE Eco Sprint in Berlin for some experiments around power consumption measurements and tools for that. It has been the first in-person KDE sprint for me since the start of the pandemic, and even happened to be in exactly the same place as the last pre-pandemic one I have been to.
External energy measurement
I have previously written about what we are looking for in terms of measuring energy consumption of a device, and an experiment to re-purpose a cheap 8€ WiFi power plug for that. While this works, it left some doubts about the precision (or lack thereof) of that solution.
The sprint provided the opportunity to compare these results with those of a proper power measuring device, in form of a development board with a Microchip MCP39F511N measurement chip.
While still cheap compared to other equipment on the market it’s significantly more expensive than the WiFi plugs (~180$ pre-pandemic, ~260$ now) and isn’t sufficiently encased for safe operations outside of a lab setup and/or by untrained users. With a 5ms sampling interval it has a significantly higher time resolution though, and being properly calibrated means the results are a lot more trustworthy.
And here’s the surprising result: The WiFi plugs are actually reasonably accurate, the jagged signal we see isn’t caused by noise or imprecision in their sensors, it’s primarily the effect of considerable undersampling.
When measured with the 40x higher sampling rate of the MCP39F511N we see that the source signal actually has much higher amplitude variations than we see on the WiFi plugs (10-15W on top of an average of 4-5W baseline), but in the form of very short peaks (10-20ms).
This is most likely an effect of how switching power supplies work (with linear resistive loads we get the same nearly perfectly flat line with both). Unfortunately I didn’t capture screenshots of this during the sprint.
The undersampling is purely an effect of the update rate on the external interface, internally the power use is measured correctly during one interval, so accumulated or averaged values match quite closely.
Overall this is good news, and shows it’s worth exploring this path further. There’s a few things to look into:
- Can we modify the Tasmota firmware to report the power readings with a higher update frequency? This seems to be available internally, and is mainly aggregated for human consumption.
- The necessary software setup for any of the measurement devices is complex, error prone and cumbersome at best. And that’s even without live plotting.
- We had serious issues with finding a working solution for realtime plotting. Things crashed on startup, didn’t manage to keep up with the 200 samples per second, added random delays or just randomly stopped. And that’s just for the basics and not even looking at other useful things like realtime low-pass/averaging filters.
The good part is that all of those are software problems, something we know how to deal with :)
Internal energy measurement
Another tool to look into further is using built-in power sensors such as those of Intel’s Running Average Power Limit (RAPL). The advantage of those is the wide and continuous availability, and the ability to measure certain system components (CPU, RAM) separately.
Measuring in-place however is only really meaningful if there’s actual system activity, as due to the measurement process itself the system will never fully be idle.
Reading out RAPL measurements isn’t particularly hard, so adding those to e.g. KSystemStats would be an obvious first step to get a feeling for how energy consumption varies under regular system use.
Unfortunately there’s an obstacle, reading those measurements requires elevated privileges. And that’s for good reasons, they are so fine-grained that this opens a potential side-channel attack vector.
So this still needs a bit more thinking about how to make this easily accessible, be it by asking for elevated privileges or by only allowing access to a sufficiently reduced resolution for example.
If you are interested in these topics and want to collaborate or contribute to this, check out KDE Eco’s get involved page.
With in-person meetings slowly and carefully resuming, it also becomes possible to contribute towards that again, by providing a venue (like KDAB did in this case), or by donating to KDE e.V. to support contributors with travel expenses.