-- Leo's gemini proxy

-- Connecting to perso.pw:1965...

-- Connected

-- Sending request

-- Meta line: 20 text/gemini;

Measuring power efficiency of a CPU frequency scheduler on OpenBSD


Author: Solène

Date: 26 September 2021

Tags: openbsd power efficiency


Comment on Mastodon


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.


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.


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.

-- Response ended

-- Page fetched on Thu Mar 28 23:38:56 2024