Title: Measuring power efficiency of a CPU frequency scheduler on | |
OpenBSD | |
Author: Solène | |
Date: 26 September 2021 | |
Tags: openbsd power efficiency | |
Description: | |
# Introduction | |
I started to work on the OpenBSD code dealing with the CPU frequency | |
scaling. The current automatic logic is a trade-off between okay | |
performance and okay battery. I'd like the auto policy to be different | |
when on battery and when on current (for laptops) to improve battery | |
life for nomad users and performance for people connected to the grid. | |
I've been able to make raw changes to produce this effect but before | |
going further, I wanted to see if I got any improvement in regards to | |
battery life and to which extent if it was positive. | |
In the incoming sections of the article I will refer to Wh unit, | |
meaning Watt-hour. It's a measurement unit for a quantity of energy | |
used, because energy used is absolutely not linear, we can make an | |
average of the usage and scale it to one hour so it's easy to compare. | |
An oven drawing 1 kW when on and being on for an hour will use 1 kWh | |
(one kilowatt-hour), while an electric heater drawing 2 kW when on and | |
turned on for 30 minutes will use 1 kWh too. | |
Kilowatt Hour explanation from Wikipedia | |
# How to understand power usage for nomad users | |
While one may think that the faster we do a task, the less time the | |
system stay up and the less battery we use, it's not entirely true for | |
laptops or computers. | |
There are two kinds of load on a system: interactive and | |
non-interactive. In non-interactive mode, let's imagine the user powers | |
on the computer, run a job and expect it to be finished as soon as | |
possible and then shutdown the computer. This is (I think) highly | |
unusual for people using a laptop on battery. Most of the time, users | |
with a laptop will want their computer to be able to stay up as long as | |
possible without having to charge. | |
In this scenario I will call interactive, the computer may be up with | |
lot of idle time where the human operator is slowly typing, thinking or | |
reading. Usually one doesn't power off a computer and power it on | |
again while the person is sitting in front of the laptop. So, for a | |
given task among the main task "staying up" may not be more efficient | |
(in regards to battery) if it takes less time, because whatever the | |
time it will take to do X() the system will stay up after. | |
# Testing protocol | |
Here is the protocol I did for the testing "powersaving" frequency | |
policy and then the regular auto policy. | |
1. Clean package of games/gzdoom | |
2. Unplug charger | |
3. Dump hw.sensors.acpibat1.watthour3 value in a file (it's the | |
remaining battery in Wh) | |
4. Run compilation of the port games/gzdoom with dpb set to use all | |
cores | |
5. Dump watthour3 value again | |
6. Wait until 18 minutes and 43 seconds | |
7. Dump watthour3 value again | |
Why games/gzdoom? It's a port I know can be compiled with parallel | |
build allowing to use all CPU and I know it takes some times but isn't | |
too short too. | |
Why 18 minutes and 43 seconds? It's the time it takes for the | |
powersaving policy to compile games/gzdoom. I needed to compare the | |
amount of energy used by both policies for the exact same time with the | |
exact same job done (remember the laptop must be up as long as | |
possible, so we don't shutdown it after compiling gzdoom). | |
I could have extended the duration of the test so the powersaving would | |
have had some idle time but given the idle time is drawing the exact | |
same power with both policies, that would have been meaningless. | |
# Results | |
I'm planning to add results for the lowest and highest modes (apm -L | |
and apm -H) to see the extremes. | |
## Compilation time | |
As expected, powersaving was slower than the auto mode, 18 minutes and | |
43 seconds versus 14 minutes and 31 seconds for the auto policy. | |
```result numbers with compilation time | |
Policy Compile time Idle time | |
------ ------------ --------- | |
powersaving 1123 0 | |
auto 871 252 | |
``` | |
Chart showing the difference in time spent for the two policies | |
## Energy used | |
We see that the powersaving used more energy for the duration of the | |
compilation of gzdoom, 5.9 Wh vs 5.6 Wh, but as we don't turn off the | |
computer after the compilation is done, the auto mode also spent a few | |
minutes idling and used 0.74 Wh in that time. | |
```result numbers with energy usage | |
Policy Compile power Idle power Total (Wh) | |
------ ------------ --------- ---------- | |
powersaving 5,90 0,00 5,90 | |
auto 5,60 0,74 6,34 | |
``` | |
Chart showing the difference in energy used for the two policies | |
# Conclusion | |
For the same job done: compiling games/gzdoom and stay on for 18 | |
minutes and 43 seconds, the powersaving policy used 5.90 Wh while the | |
auto mode used 6.34 Wh. This is a saving of 6.90% of power. | |
This is a testing policy I made for testing purposes, it may be too | |
conservative for most people, I don't know. I'm currently playing with | |
this and with a reproducible benchmark like this one I'm able to | |
compare results between changes in the scheduler. |