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.
(HTM) 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
```
(IMG) 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
```
(IMG) 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.