Power management of a computer display - KTH
Power management of a computer display - KTH
Power management of a computer display - KTH
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
<strong>Power</strong> <strong>management</strong> <strong>of</strong> a <strong>computer</strong> <strong>display</strong><br />
Developing a daemon for intelligent <strong>management</strong> <strong>of</strong> <strong>computer</strong> <strong>display</strong> brightness<br />
SEBASTIAN OLSSON, seo@kth.se<br />
JONATAN ÅKESSON, jonatan.akesson@gmail.com<br />
Bachelor’s Thesis at CSC<br />
Supervisor: Per Austrin<br />
Examiner: Mårten Björkman<br />
Degree Project in Computer Science, First Level, DD143X<br />
CSC, Royal Institute <strong>of</strong> Technology
Abstract<br />
The goal with this project is to investigate how the energy <strong>management</strong><br />
can be improved on a linux <strong>computer</strong>. Focus lies on the screen back light<br />
as this is one <strong>of</strong> the major energy consumers in a laptop <strong>computer</strong>. In the<br />
systems available today the regulation is static and the back light is set<br />
in fixed steps without the user behavior in consideration. Adaboost is a<br />
machine learning algorithm that is implemented in a s<strong>of</strong>tware daemon<br />
to regulate the back light adaptive. The algorithm is trained with data<br />
containing the user demands in the specific system state. Data covering<br />
key presses per time, actual brightness,battery level and the information<br />
if power cord is plugged in or not. The algorithm will continuously classify<br />
the current system state and increase or decrease the back light. A<br />
statistical study shows that the daemon consumes more energy than the<br />
original system. Future developments and improvements are discussed.
Referat<br />
Energistyrning av datorskärmar<br />
Detta projekt syftar till att undersöka hur energihanteringen kan förbättras<br />
på en Linuxdator. Fokus i implementationen ligger på skärmens<br />
bakgrundsbelysning eftersom detta är en av de största energiförbrukarna<br />
i en bärbar dator. I de system som finns tillgängliga idag så sker<br />
regleringen statiskt och bakgrundsbelysningen regleras i fasta steg utan<br />
anpassning till användarens beteende. Adaboost som är en lärande algoritm<br />
implementeras i en mjukvaru daemon för att reglera ljusstyrkan<br />
adaptivt. Algoritmen tränas med data för användarens önskemål i det<br />
aktuella körläget med avseende på tangenttryckningar per tid, aktuell<br />
ljusstyrka, batterinivå och information om strömkabeln är inkopplad eller<br />
ej. Algoritmen klassificerar sedan kontinuerligt aktuellt körläge och<br />
höjer eller sänker bakgrundsbelysningen adaptivt. En statistisk undersökning<br />
visar att vår energihanterare drar mer ström än om den är<br />
inaktiv. Framtida utveckling och förbättringar diskuteras
Statement <strong>of</strong> collaboration<br />
The table below gives an estimate on how much <strong>of</strong> each part <strong>of</strong> the project each<br />
author has worked on.<br />
Table 1. Distribution <strong>of</strong> the workload<br />
Part Sebastian Jonatan<br />
Research 30 % 70 %<br />
Preliminaries 60 % 40 %<br />
Evaluation methods 50 % 50 %<br />
Report layout 60 % 40 %<br />
Developing the s<strong>of</strong>tware 50 % 50 %<br />
Report writing 50 % 50 %
Contents<br />
1 Introduction 1<br />
1.1 Problem formulation . . . . . . . . . . . . . . . . . . . . . . . . . . . 1<br />
1.2 Scope <strong>of</strong> the project . . . . . . . . . . . . . . . . . . . . . . . . . . . 2<br />
1.3 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2<br />
2 Method 3<br />
2.1 Literature review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3<br />
2.2 Preliminaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3<br />
2.3 System design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4<br />
2.3.1 Back light control . . . . . . . . . . . . . . . . . . . . . . . . 4<br />
2.3.2 Adaptive Boost - Adaboost . . . . . . . . . . . . . . . . . . . 4<br />
2.4 System evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5<br />
3 Results 6<br />
3.1 Aspects <strong>of</strong> power <strong>management</strong> . . . . . . . . . . . . . . . . . . . . . 6<br />
3.1.1 Full brightness at all times . . . . . . . . . . . . . . . . . . . 6<br />
3.1.2 Persistant behavior . . . . . . . . . . . . . . . . . . . . . . . . 6<br />
3.1.3 Incorrect behavior . . . . . . . . . . . . . . . . . . . . . . . . 7<br />
3.1.4 No gradual change in brightness . . . . . . . . . . . . . . . . 7<br />
3.2 System design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7<br />
3.2.1 Program structure . . . . . . . . . . . . . . . . . . . . . . . . 7<br />
3.2.2 Training set . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8<br />
3.2.3 OS commands . . . . . . . . . . . . . . . . . . . . . . . . . . 9<br />
3.3 Statistical evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . 10<br />
4 Discussion 13<br />
4.1 Existing shortcomings . . . . . . . . . . . . . . . . . . . . . . . . . . 13<br />
4.2 System design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13<br />
4.3 Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14<br />
4.4 Further research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15<br />
4.5 Learning algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15<br />
4.6 User experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15<br />
4.7 Energy saving versus user experience . . . . . . . . . . . . . . . . . . 16
5 Conclusion 17<br />
Bibliography 18<br />
Appendices 18<br />
A Source code 19<br />
A.1 daemon.py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Chapter 1<br />
Introduction<br />
Mobile devices increase their market share every year. In 2007 [1], for the first time,<br />
more laptop <strong>computer</strong>s that stationary <strong>computer</strong>s were sold. In December 2012 [2]<br />
more tablets that laptops were sold for the first time.<br />
The increased mobility and dependency <strong>of</strong> battery-powered devices have made the<br />
power <strong>management</strong> an even more important subject. <strong>Power</strong> <strong>management</strong> is a large<br />
subject and a lot <strong>of</strong> factors and many different hardware components influence power<br />
consumption.<br />
LCD [3] technology has evolved and traditional CCFL [4] back light is now being<br />
replaced with more power efficient LED [5] instead. Still the back light <strong>of</strong> the LCD<br />
is a major power consumer. S<strong>of</strong>tware power conservation related to the LCD are<br />
automatic switch <strong>of</strong>f and screen dimming. Commercial available power <strong>management</strong><br />
in personal <strong>computer</strong>s behaves relatively static with regard to back light and will<br />
turn the back light <strong>of</strong>f after a fixed time <strong>of</strong> inactivity. Very common is also the<br />
function to detect if the lid on a laptop is closed and react with screen switch <strong>of</strong>f or<br />
sleep mode. In some units ambient light sensors are used to be able to do intelligent<br />
dimming.<br />
Despite these advancements, we think that the power managers <strong>of</strong> today lack intelligence<br />
in a sense that they are quite indifferent to how the user behaves. We have<br />
been quite disappointed with this fact, and thus decided to try to make a minimal<br />
power manager <strong>of</strong> our own.<br />
1.1 Problem formulation<br />
In short, the goal <strong>of</strong> the project is to<br />
1. Carry out a study about the shortcomings <strong>of</strong> standard present-day <strong>computer</strong><br />
power managers<br />
1
CHAPTER 1. INTRODUCTION<br />
2. Based on the results from the study, develop our own power manager<br />
3. Evaluate our power manager<br />
1.2 Scope <strong>of</strong> the project<br />
To accomplish the first point, we will study only our own laptop <strong>computer</strong>s. Because<br />
the field <strong>of</strong> research is huge, we decided to confine ourselves only to the study <strong>of</strong><br />
power <strong>management</strong> <strong>of</strong> the brightness level for a <strong>computer</strong> <strong>display</strong>.<br />
The power manager we are developing will be a s<strong>of</strong>tware daemon, capable <strong>of</strong> manipulating<br />
the brightness settings. It will be specifically configured to work on<br />
Sebastian’s laptop <strong>computer</strong>, which is an Asus Zenbook UX31A with Arch Linux<br />
installed. There is therefore no guarantee <strong>of</strong> portability. To add a sense <strong>of</strong> originality<br />
to our project, we will focus on making the daemon [6–8] intelligent in terms <strong>of</strong><br />
understanding the way the user behaves. The idea is that the power <strong>management</strong><br />
will adjust itself to the usage <strong>of</strong> the <strong>computer</strong> in relation to activity and habits.<br />
The aim is to save power without obstructing user interaction drastically.<br />
Lastly, the power manager will be evaluated through a minimal study measuring<br />
the amount <strong>of</strong> power it saves. The user-friendliness aspect <strong>of</strong> the manager will not<br />
be evaluated due to limited time and difficulty.<br />
1.3 Purpose<br />
The main purpose <strong>of</strong> the project is to reduce the amount <strong>of</strong> electricity that personal<br />
<strong>computer</strong>s consume. This is <strong>of</strong> course relevant since sustainable development is<br />
an important subject today. We are ourselves quite unhappy with present-time<br />
standard power managers when it comes to controlling the brightness <strong>of</strong> the screen<br />
because <strong>of</strong> their overly simple behavior (described in later sections). Our view<br />
is that because power managers behave in such simple manner, great amounts <strong>of</strong><br />
energy go to waste. We think that this problem can be averted by designing a more<br />
intelligent power manager.<br />
Besides the energy-saving aspect, we also acknowledge a few problems about today’s<br />
power managers in terms <strong>of</strong> user experience. We think that a more intelligent power<br />
manager would be able to improve this factor as well. Another purpose is therefore<br />
to hopefully make users appreciate the behavior <strong>of</strong> the power manager more.<br />
2
Chapter 2<br />
Method<br />
The following sections describe how we went about fulfilling our goals.<br />
2.1 Literature review<br />
Our source material consisted primarily <strong>of</strong> articles and specifications on the Internet.<br />
The ACPI specification [9] has been a useful and undisputably reliable source <strong>of</strong><br />
information, being compiled by leading organizations in the area <strong>of</strong> technology. It<br />
has provided the theoretical bits <strong>of</strong> information that we need to understand power<br />
<strong>management</strong> in itself.<br />
While we did find quite much information about ACPI and about self-learning<br />
daemons, we did not manage to find anything combining these two concepts. We<br />
interpret this as an indication that our specific idea is somewhat unique. The articles<br />
and documentation that we do have found were supportive when working with the<br />
more practical parts <strong>of</strong> the project (mostly coding).<br />
2.2 Preliminaries<br />
To better understand the problem and the possibilities with the technologies involved<br />
in this project, we perform a small study <strong>of</strong> the problems with today’s common<br />
power managers. The result will simply take the form <strong>of</strong> a collection <strong>of</strong> problems<br />
that we have identified in our daily usage <strong>of</strong> our own <strong>computer</strong>s. Both usability<br />
aspects and power-wasting aspects will be taken into account. These problems will<br />
then be kept in mind when thinking <strong>of</strong> features to focus on during development <strong>of</strong><br />
the daemon.<br />
3
2.3 System design<br />
CHAPTER 2. METHOD<br />
The daemon is designed with properties described in the sections below.<br />
2.3.1 Back light control<br />
It must be possible for the user to manually set the <strong>display</strong> brightness while the<br />
daemon is running. There are usually at least two different ways <strong>of</strong> controlling the<br />
<strong>display</strong> brightness on a Linux laptop <strong>computer</strong>. Most <strong>computer</strong>s complie to the<br />
ACPI [9] standard and this is the default way to control the backlight. The second<br />
option is to control the <strong>computer</strong> specific hardware directly. An alternative way to<br />
switch <strong>of</strong>f the back light is through DPMS. [10; 11]<br />
2.3.2 Adaptive Boost - Adaboost<br />
To fulfill the objectives there is a need to classify the current system situation. The<br />
classification will be used to take the decision if the brightness should be increased<br />
or decreased in a specific situation. In this project we use an Adaboost implementation<br />
called isciboost to do the classification. The advantages with Adaboost is<br />
that it is able to tweak the classifier to take incorrect classifications into consideration.<br />
For each iteration in the training <strong>of</strong> the algorithm the weight <strong>of</strong> the incorrect<br />
classifications are raised and the weight <strong>of</strong> the correct classifications are lowered.<br />
In this way the subsequent iterations focus on the data-sets that have been incorrectly<br />
classified. Adaboost can react to nonconforming data and form a responsive<br />
algorithm suitable to the situation.<br />
Training the algorithm<br />
To be able to take decisions based on the current system state it is necessary to<br />
have a set <strong>of</strong> training data with information <strong>of</strong> desired states in different situations.<br />
In the current application the training <strong>of</strong> the algorithm is performed when the user<br />
add information that is valuable for the algorithm. The system will take action if<br />
the user adjusts the brightness with the hardware keys on the keyboard. When this<br />
activity is discovered the program will consider this as a back light level state that<br />
is desired by the user in the current situation. This information will be stored into<br />
the training set and the algorithm will train with the updated training set. The<br />
system information that is collected is the time average <strong>of</strong> the key press rate the<br />
last minutes, current back light level, battery charge level and the power cord is<br />
connected or not. The collected data-sets will also contain the information if the<br />
specific entry is classified as one <strong>of</strong> the two classifications: decrease back light or<br />
increase back light. The collection <strong>of</strong> user desires through this data and the repeated<br />
4
2.4. SYSTEM EVALUATION<br />
training <strong>of</strong> the algorithm will make the system adapt to user preferences in a given<br />
unclassified state.<br />
Classification<br />
The implemented daemon will iteratively ask the Adaboost implementation for a<br />
classification given the current system state. Adaboost will respond with a classification<br />
<strong>of</strong> the unclassified state based on the training data described above. The<br />
classification is performed with a statement that the back light should be lowered<br />
and the Adaboost algorithm will then tell if this statement is likely to be true or<br />
false and the back light will be decreased or increased. Since the classification is<br />
done in real time iteratively the system will reach an equilibrium state where the<br />
back light is kept stable if none <strong>of</strong> the analyzed parameters are changed.<br />
2.4 System evaluation<br />
The system can be evaluated in essentially two ways: in terms <strong>of</strong> usability and in<br />
terms <strong>of</strong> how much power it saves. Because we have little time at our disposal,<br />
we have chosen to evaluate only the power-saving aspect, and not very comprehensively.<br />
One hour is dedicated to studying the power consumption when the daemon is not<br />
active. Each second, the file /sys/class/power_supply/BAT0/power_now is read,<br />
which contains the current power consumption. The higher the value, the faster is<br />
the rate at which the battery is discharging. The power cord is to be unplugged and<br />
the screen will be configured with a full level <strong>of</strong> brightness (4302/4302 units), which<br />
is the default configuration. During the measurements, the <strong>computer</strong> is to be used<br />
for the sole task <strong>of</strong> writing this report. Another hour is dedicated to studying the<br />
consumption with the daemon running. The configurations are the same as above<br />
except for the brightness level, <strong>of</strong> course. Like the other hour, we are continuously<br />
using the <strong>computer</strong> to write this report.<br />
5
Chapter 3<br />
Results<br />
Following our preliminary study, we will start by presenting our recognition <strong>of</strong> the<br />
areas where standard power managers lack the intellect to save power. We will then<br />
describe the actual program and finish by presenting the results <strong>of</strong> our statistical<br />
evaluation.<br />
3.1 Aspects <strong>of</strong> power <strong>management</strong><br />
The following subsections explain the problems that we identified in our preliminary<br />
study.<br />
3.1.1 Full brightness at all times<br />
Presumption 1: The longer time that has passed from the moment when the user<br />
last touched the <strong>computer</strong>, the higher is the probability that the user is not currently<br />
using the <strong>computer</strong>.<br />
3.1.2 Persistant behavior<br />
Because usual power managers are unable to learn, they persist to continue behaving<br />
in a way that might trouble the user. Imagine the following scenario: A person is<br />
sitting in front <strong>of</strong> a stationary Ubuntu <strong>computer</strong>, logged in. Instead <strong>of</strong> actively<br />
interacting with the <strong>computer</strong>, she is studying from a book on the table that the<br />
monitor is placed on. Every fifteen minutes or so, she browses the Web briefly and<br />
then returns to her studies.<br />
Because <strong>of</strong> the current power <strong>management</strong> settings, the <strong>display</strong> shuts <strong>of</strong>f and automatically<br />
logs out after ten minutes <strong>of</strong> no interaction. Since the person does not<br />
6
3.2. SYSTEM DESIGN<br />
want to have to reenter the password each time, she presses a key or touches the<br />
mouse now and then to make sure the <strong>computer</strong> “stays awake”. This annoying phenomenon<br />
is one <strong>of</strong> the quite obvious issues that a more intelligent power manager<br />
might be able to fix.<br />
3.1.3 Incorrect behavior<br />
Perhaps uncommonly, there are times when the power manager behaves in a way it<br />
should not. On one occasion, we started an audio file which was set to repeat when<br />
done playing, pressed mute and left the <strong>computer</strong> on over the night, expecting it to<br />
eventually enter sleep mode by itself. However, because the audio file was constantly<br />
playing, even if muted, the <strong>computer</strong> stayed awake.<br />
3.1.4 No gradual change in brightness<br />
On perhaps most systems, the <strong>display</strong> brightness tends to jump between a few<br />
discrete states instead <strong>of</strong> gradually changing. For example, pressing a button on a<br />
<strong>computer</strong> while its screen is turned <strong>of</strong>f generally causes the screen brightness to go<br />
from turned <strong>of</strong>f to maximum. We consider this to be a problem, as the user might<br />
not always want to increase the brightness more than “necessary”.<br />
3.2 System design<br />
This section will describe the behavior <strong>of</strong> the system. For the actual source code,<br />
see the appendix.<br />
The system consists <strong>of</strong> a folder <strong>of</strong> files. The daemon is initiated on the targeted<br />
machine by executing<br />
sudo python2 daemon.py<br />
from the terminal (tested with Python 2.7.3).<br />
3.2.1 Program structure<br />
The behavior <strong>of</strong> the program is summarized in form <strong>of</strong> pseudocode below:<br />
1. Start the keylogger, which keeps record <strong>of</strong> the number <strong>of</strong> keypresses lately.<br />
2. Start the keylistener, which listens on the F5 and F6 keys and decreases or<br />
increases the brightness <strong>of</strong> the screen accordingly.<br />
3. Read current backlight brightness level.<br />
4. Read current power consumption.<br />
7
CHAPTER 3. RESULTS<br />
5. Classify the current system state using Adaboost.<br />
6. If the current state was classified as a state where the brightness should<br />
increase:<br />
7. Increase it by 0.5 \%<br />
8. Else:<br />
9. Decrease it by 0.5 \%.<br />
10. If F6 is pressed:<br />
11. Add a tuple (k,p,l,b,higher) to the training set, where<br />
k is the number <strong>of</strong> keypresses last 60 seconds,<br />
p is T if the power cord is plugged in and F otherwise,<br />
l is the current brightness in percent,<br />
b is the current battery level in percent.<br />
12. Increase the brightness by 500 out <strong>of</strong> 4302 units (about 12 \%).<br />
13. Wait for 5 seconds.<br />
14. Re-train with Adaboost.<br />
15. If F5 is pressed:<br />
16. Add a tuple (k,p,l,b,lower) to the training set.<br />
17. Decrease the brightness by 500 out <strong>of</strong> 4302 units (about 12 \%).<br />
18. Wait for 5 seconds.<br />
19. Re-train with Adaboost.<br />
20. Return to step 3.<br />
3.2.2 Training set<br />
The file named power.data contains the entries for the training set.s An excerpt<br />
with three entries might look like this:<br />
66, T, 0, 99, higher<br />
30, F, 57, 99, lower<br />
0, F, 100, 28, lower<br />
where:<br />
• The first column is a numeric measure <strong>of</strong> the keyboard activity last 30 seconds.<br />
This is roughly the same quantity as six times the number <strong>of</strong> keypresses within<br />
that time period.<br />
• The second column is T if the power chord is plugged in and F otherwise.<br />
• The third column is the screen brightness given in percent.<br />
• The fourth column is ther battery level given in percent.<br />
• The fifth column contains the word “higher” if the brightness is decided to be<br />
increased and “lower” otherwise.<br />
8
3.2. SYSTEM DESIGN<br />
3.2.3 OS commands<br />
Backlight<br />
The backlight level can be read from the system directory in Linux. There are<br />
normally two separate directories one for the ACPI control and one for the specific<br />
graphics hardware. The actual brightness that the <strong>computer</strong> is set to can be<br />
read from the system with the following or similar commands depending on linux<br />
installation and hardware:<br />
cat /sys/class/backlight/acpi\_video0/actual\_brightness<br />
cat /sys/class/backlight/intel_video/actual_brightness<br />
The graphics hardware specific setting has the advantage <strong>of</strong> greater specificity and<br />
greater range than the ACPI setting. The ACPI setting can only show integers<br />
from 0-10 where 0 is low( but non zero) back light and 10 is maximum back light.<br />
The graphics hardware specific setting can be set from 0 to 4000 where 0 is back<br />
light <strong>of</strong>f and 4000 is maximum back light. We choose to implement the Intel specific<br />
method because <strong>of</strong> the factors mentioned above. the aim with the daemon is to be<br />
seamless and user friendly. The steps in the ACPI setting is to large to fulfill the<br />
task. The portability should have been better with the ACPI setting.<br />
To set the back light the same directories as above is used. The commands used to<br />
set the back light to the numeric level specified in the command:<br />
echo 10 | sudo tee /sys/class/backlight/acpi_video0/brightness<br />
echo 4000 | sudo tee /sys/class/backlight/intel_video/brightness<br />
This will set the backlight to maximum level.<br />
<strong>Power</strong> data<br />
The current battery charge level is calculated from the data retrieved from the<br />
system directory:<br />
cat /sys/class/power_supply/BAT0/charge_now<br />
cat /sys/class/power_supply/BAT0/charge_full<br />
The commands will return the battery actual charge and the charge when fully<br />
charged in mAh Battery remaining in percent is then easily calculated by dividing<br />
these values.<br />
To be able to tell if the AC cord is connected or not this command is used:<br />
cat /sys/class/power_supply/ADP0/online<br />
All console commands are called from the implemented program that also reads<br />
their return as input.<br />
9
Keyboard<br />
CHAPTER 3. RESULTS<br />
Since the algorithm will take keystrokes as an input this data has to be catured.<br />
This is achived by reading the following file for keypress events.<br />
/dev/input/event0<br />
3.3 Statistical evaluation<br />
The study was performed from 8 AM to 10 AM, April 11. The daemon was unactive<br />
during the first hour (3600 seconds) <strong>of</strong> measurement and active during the second<br />
hour. The power usage is illustrated in the graph below. There are a total <strong>of</strong> 7200<br />
data points, each associating a point in time (separated by one second) with a level<br />
<strong>of</strong> electric power.<br />
Figure 3.1. One hour <strong>of</strong> normal usage followed by one hour <strong>of</strong> usage with the<br />
daemon activated.<br />
It was apparent that the brightness level was changing continuously during the<br />
latter hour. At one point, the brightness was slowly brought down to its lowest<br />
level.<br />
Shortly thereafter, two additional measurements were made in order to get an idea<br />
<strong>of</strong> how much power we could potentially save. The red graph in the plot below<br />
10
3.3. STATISTICAL EVALUATION<br />
shows the level <strong>of</strong> power consumption during ten seconds with the brightness level<br />
at maximum. The green graph does the same but with the screen turned <strong>of</strong>f.<br />
Figure 3.2. Comparison <strong>of</strong> power consumption for two brightness settings.<br />
The values were taken from the table below.<br />
Table 3.1. <strong>Power</strong> consumption for two different brightness settings<br />
Full brightness (µW) Turned <strong>of</strong>f <strong>display</strong> (µW)<br />
Second 1 10220000 7063000<br />
Second 2 10374000 6937000<br />
Second 3 10374000 9324000<br />
Second 4 10290000 7371000<br />
Second 5 10290000 7329000<br />
Second 6 10234000 7238000<br />
Second 7 10234000 7329000<br />
Second 8 10136000 7350000<br />
Second 9 10269000 7483000<br />
Second 10 10703000 7378000<br />
Average power 10312400 7480200<br />
These measurements show that in theory, the power usage can be dropped down to<br />
11
CHAPTER 3. RESULTS<br />
7480200<br />
≈ 73 % (3.1)<br />
10312400<br />
<strong>of</strong> the standard level by controlling the <strong>display</strong> brightness alone.<br />
12
Chapter 4<br />
Discussion<br />
4.1 Existing shortcomings<br />
Early in the project focus was to identify specific problems regarding power <strong>management</strong><br />
and to try to address them. These specific problems could be that an playing<br />
muted audio file could keep the screen turned on even if the <strong>computer</strong> is unused<br />
for example. Exceptional problems that could be common depending on situation.<br />
This approach could have been extended with thorough user studies to identify<br />
when the traditional power <strong>management</strong> is inadequate. When greater knowledge<br />
in the area was achieved focus shifted somewhat towards the implementation <strong>of</strong><br />
an more general algorithm that seamed more interesting with the limited time and<br />
resources at hand. This implementation solve many <strong>of</strong> identified issues. When the<br />
daemon is active the brightness is actively changed dependant on system state and<br />
it is changed gradually almost constantly in a way that doesn’t interfere with the<br />
user. The system is also adoptable as long as the user actively adjust the back light<br />
to learn the system.<br />
4.2 System design<br />
The implementation is naturally strongly dependant on the information in the training<br />
set. In the current design some parameters are taken into consideration and it<br />
is probably possible to reach better results if more/other variables are introduced.<br />
The implementation is experimental at this stage and it has limitations. The current<br />
approach will demand that the user actively adjusts the back light. If the user<br />
doesn’t adjust the back light it will not be able to learn from new situations. Of<br />
course a good initial training set can produce adequate results but the system will<br />
not be adoptable in this case. Another aspect in a real life scenario is that it is<br />
likely that the user primarily increases the back light. This will probably lead to<br />
13
CHAPTER 4. DISCUSSION<br />
that the back light is set to high in many situations if the user not actively tries to<br />
save energy by lowering the back light. Contributing to the poor test results is the<br />
fact that the current program runs with high update rate and many iterations per<br />
minute. The main focus has been to evaluate the possibilities regarding back light<br />
control for power <strong>management</strong>. The program is not optimized to lower consumption<br />
at this stage.<br />
4.3 Diagram<br />
As we can see from figure 3.1, the s<strong>of</strong>tware daemon has not contributed to reducing<br />
the power consumption in our case. Quite the contrary - it appears that the consumption<br />
stays around 11 W in the unactive case while it stays around 12.5 W in<br />
the active case most <strong>of</strong> the time. If we were to presume that the power consumption<br />
is roughly proportional to the level <strong>of</strong> brightness, the results contradict our<br />
presumption. This is because the <strong>display</strong> was set to full brightness during the first<br />
hour, and varying during the second. How can this be?<br />
The likely answer is that just running the system drains more power than the system<br />
saves. After all, our system performes quite many tasks regularly: logging keys,<br />
reading and writing to files, and training a classifier (though not very <strong>of</strong>ten).<br />
More formally, let b1(t) denote the brightness level at time t during the first hour<br />
<strong>of</strong> the experiment, given as a quota. The power usage P1 µW may then be modeled<br />
by<br />
P1(t) = α + βb(t) (4.1)<br />
where α ≈ 10312400 according to table 3.1 (assuming that the sampling error is<br />
reasonably small). Note that b1(t) = 1. Quite similarily, the power usage P2 µW<br />
during the second hour may be modeled by<br />
P2(t) = α + βb2(t) + δ (4.2)<br />
where b2(t) ranges between 0 and 1 at time t, and δ is the additional power strain<br />
that running the daemon puts on the machine. Our objective has been to save<br />
power during a time period [a, b], i.e. make it so that<br />
b<br />
b<br />
P2(t)dt > P1(t)dt (4.3)<br />
a<br />
a<br />
As has been shown, this mission failed. While it must be true that b2(t) ≥ b1(t) for<br />
all t, this comes at the price <strong>of</strong> a constant addition δ which apparently causes the<br />
net power usage to be higher when our daemon is active.<br />
In order to complete the objective, we need to reduce δ and/or force the b2 function<br />
to map to lower values. Ideally, we focus on minimizing δ to insignificance and<br />
leaving b2 untouched so that the user has the freedom to vary the brightness level<br />
14
4.4. FURTHER RESEARCH<br />
at own will. This could for example be accomplished by reducing the frequency at<br />
which our daemon reads the current brightness. Doing so would make the system<br />
less responsive, however. There are probably a huge number <strong>of</strong> parts <strong>of</strong> the program<br />
which could be refined that we have not thought about yet.<br />
4.4 Further research<br />
The implementation today consists <strong>of</strong> a general algorithm that do not address all<br />
the specific problems described in chapter 3. The daemon can be developed further.<br />
Our chosen Adaboost implementation can accept various data and we believe that<br />
significant power conservation could be achived by identifying(preferably by user<br />
studies) and addressing the back light setting in this situations. Ultimately the<br />
user could learn the system to address these specific exceptional problems. The<br />
challenge in this case is to be able to create an intuitive way for the user to pass on<br />
this information to the system.<br />
4.5 Learning algorithm<br />
Adaboost has shown to be useful in this application. The ability to train the<br />
algorithm is very suitable in this case because the system can be in an endless<br />
number <strong>of</strong> states and it is impossible to anticipate the required action in different<br />
situations. The icsiboost implementation has the advantage that it is easy to work<br />
with. It also easily adopts to different data making testing and evaluation <strong>of</strong> different<br />
parameter problem free. Using the implemented program over time will create a<br />
substantial amount <strong>of</strong> data in the training set. One way to limit the data set is to<br />
remove old entries. The execution time <strong>of</strong> the classification and training will limit<br />
the update rate <strong>of</strong> which the program can run. One way to restrict the training<br />
time is to limit the number <strong>of</strong> iterations in the training. This will make training<br />
faster but the classification error will also be larger. In the current implementation<br />
the weak classifiers is constructed from the discrete system states. It might be<br />
possible to improve the classification if different weak classifiers are constructed<br />
and maybe other learning algorithms are tested. To fulfil the aims with this project<br />
it is important that the execution <strong>of</strong> the program is energy efficient. One important<br />
concern is to limit the update rate as much as possible to conserve energy but on<br />
the other hand keep it high enough to give a responsive behaviour.<br />
4.6 User experience<br />
To be able to take wise decisions to conserve energy user interaction has been<br />
observed. By analyzing common user behavior the system can adapt to the user<br />
15
CHAPTER 4. DISCUSSION<br />
interaction and not the other way around. A common behavior <strong>of</strong> a generic system<br />
is to do a full wake up when a user interact with the <strong>computer</strong>. The system will<br />
turn on full back light regardless <strong>of</strong> the user intent and the intensity <strong>of</strong> the user<br />
interaction. A user can for example move the mouse with the intent to check if<br />
the <strong>computer</strong> is turned on or awake. In another situation a user can hit a key on<br />
the keyboard to check the current time or the name <strong>of</strong> the playing song in a media<br />
player. It would be acceptable or even better for the user experience to do a partial<br />
wake up in this situations. Generic systems <strong>of</strong> today behaves relatively static in<br />
the respect <strong>of</strong> back light dimming. When a user is dissatisfied with the current<br />
brightness and adjusts it the system will keep the new setting regardless <strong>of</strong> changes<br />
in the user environment.<br />
4.7 Energy saving versus user experience<br />
By implementing learning algorithms it is possible to create a system that interact<br />
with the user in an more intelligent way. By taking historical factors into account<br />
it is possible to make the system adoptable and alterable over time. This can<br />
create a better user experience if the system can avoid unintended behavior. One<br />
consideration when implementing the system to maximize energy conservation is<br />
also to what extent the user can accept a worsen user experience with the benefit<br />
<strong>of</strong> energy conservation.<br />
16
Chapter 5<br />
Conclusion<br />
As our results have shown, the brightness <strong>of</strong> a laptop <strong>display</strong> in our case alone<br />
accounts for 27 % <strong>of</strong> the power usage, making it quite a significant factor to reduce.<br />
By studying the way the user behaves, we believe it is be possible to save most<br />
<strong>of</strong> this power. We are also confident that the user experience can be enhanced<br />
this way. More research needs to be done in this area in order to find out how.<br />
Perhaps even more power can be saved by controlling other related factors in the<br />
same fashion, such as when the <strong>computer</strong> goes to sleep? Maybe the user experience<br />
really improves by changing the <strong>display</strong> brightness in a gradual manner, as we have<br />
theorized? Could more intelligent <strong>management</strong> <strong>of</strong> power usage be the key to save<br />
vast amounts <strong>of</strong> electricity in the future? For the sake <strong>of</strong> sustainable development,<br />
we hope so, and hope that our study has contributed to the progress, even if by<br />
only scraping the surface <strong>of</strong> a vast number <strong>of</strong> power saving possibilities.<br />
17
Bibliography<br />
1. Bärbara datorer går om stationära [homepage on the Internet]. IDG; 2007.<br />
Available from: http://www.idg.se/2.1085/1.116318.<br />
2. Surfplattan går om bärbar pc [homepage on the Internet]. Dagens<br />
Nyheter; 2012. Available from: http://www.dn.se/ekonomi/teknik/<br />
surfplattan-gar-om-barbar-pc.<br />
3. LCD Definition [homepage on the Internet]. PCMag; 2012. Available<br />
from: http://www.pcmag.com/encyclopedia_term/0,1237,t=LCD&i=45973,<br />
00.asp.<br />
4. Cold cathode [homepage on the Internet]. Wikipedia; 2012. Available from:<br />
http://en.wikipedia.org/wiki/CCFL.<br />
5. Back light [homepage on the Internet]. Wikipedia; 2012. Available from: http:<br />
//en.wikipedia.org/wiki/Backlight.<br />
6. Deamon Defenition [homepage on the Internet]. The Linux Information Project;<br />
2012. Available from: http://www.linfo.org/daemon.html.<br />
7. Linux daemon howto [homepage on the Internet]; 2012. Available from: http:<br />
//www.netzmafia.de/skripten/unix/linux-daemon-howto.html.<br />
8. Linux daemon list [homepage on the Internet]; 2012. Available from: Referens:<br />
https://wiki.archlinux.org/index.php/Daemons_List.<br />
9. Hewlett-Packard. Advanced Configuration and <strong>Power</strong> Interface Specification;<br />
2011.<br />
10. Display <strong>Power</strong> Management Signaling [homepage on the Internet]. Arch Linux;<br />
2012. Available from: https://wiki.archlinux.org/index.php/Display_<br />
<strong>Power</strong>_Management_Signaling.<br />
11. Goodart J. Display <strong>Power</strong> Management (DPM) Standard Release A. 39899<br />
Balentine Drive, Suite 125 Newark, CA 94560: Video Electronics Standards<br />
Association; 2003.<br />
18
Appendix A<br />
Source code<br />
Further below is the source code for the main module <strong>of</strong> the program, demon.py,<br />
slightly modified to make it fit. At the time <strong>of</strong> writing, all the project files can be<br />
found here:<br />
https://github.com/Sebelino/kexjobb<br />
This includes statistics.dat, which contains the results for figure 3.1.<br />
A.1 daemon.py<br />
#!/usr/bin/env python<br />
# -*- coding: utf-8 -*-<br />
import time<br />
import os<br />
import subprocess<br />
import re<br />
import thread<br />
from threading import Thread<br />
from constants import MAX_BL<br />
from constants import TRAIN_DELAY<br />
from constants import DIM_PERCENT<br />
from sysdata import sysdata<br />
def initialize():<br />
os.system("python2 key.py &")<br />
os.system("logkeys -k")<br />
open("keylog.log","w").close() # Empties the file.<br />
19
os.system("logkeys --start --output keylog.log")<br />
APPENDIX A. SOURCE CODE<br />
initialize()<br />
keylog_change = (123,0,0) # (Bytes,number <strong>of</strong> F5s,number <strong>of</strong> F6s)<br />
train_delay_counter = -1<br />
def add_entry_decrease(brightness,key_presses):<br />
sysdata_tuple = sysdata()<br />
battery_level = str(sysdata_tuple[0])<br />
plugged_in = ’T’ if sysdata_tuple[5] else ’F’<br />
entry = "\n%s, %s, %s, %s, lower"%(key_presses,plugged_in,brightness,<br />
battery_level)<br />
print "Adding entry: %s"% entry<br />
with open("power.data","a") as training_set_file:<br />
training_set_file.write(entry)<br />
def add_entry_increase(brightness,key_presses):<br />
sysdata_tuple = sysdata()<br />
battery_level = str(sysdata_tuple[0])<br />
plugged_in = ’T’ if sysdata_tuple[5] else ’F’<br />
entry = "\n%s, %s, %s, %s, higher"%(key_presses,plugged_in,brightness,<br />
battery_level)<br />
print "Adding entry: %s"% entry<br />
with open("power.data","a") as training_set_file:<br />
training_set_file.write(entry)<br />
def confine_training_set():<br />
rows = file(’power.data’,’r’).readlines()<br />
entry_count = len(filter(None,rows))<br />
if entry_count >= 20:<br />
start_index = entry_count-19<br />
open(’power.data’,’w’).writelines(rows[start_index:])<br />
def manual_adjustments(brightness,key_presses):<br />
global train_delay_counter,keylog_change<br />
lines = file(’keylog.log’,’r’).readlines()<br />
last_line = lines[-1]<br />
p = re.compile(r’(|)’)<br />
tokens = p.split(last_line)<br />
current_vals = (os.path.getsize("keylog.log"),<br />
len(filter(lambda x: x == "",tokens)),<br />
len(filter(lambda x: x == "",tokens)))<br />
if((keylog_change[1] == current_vals[1]) and<br />
(keylog_change[2] == current_vals[2])):<br />
20
A.1. DAEMON.PY<br />
return False<br />
confine_training_set()<br />
for token in reversed(tokens):<br />
if token == ’’:<br />
add_entry_increase(brightness,key_presses)<br />
break<br />
elif token == ’’:<br />
add_entry_decrease(brightness,key_presses)<br />
break<br />
train_delay_counter = TRAIN_DELAY<br />
keylog_change = current_vals<br />
time.sleep(0.3)<br />
return True<br />
def kod():<br />
global train_delay_counter,keylog_change<br />
print " %s"% train_delay_counter<br />
bl = str(MAX_BL)<br />
s = get_active_window_title("")<br />
actual_bright = os.popen(’python2 get_brightness.py’).readline()<br />
#read keypresses<br />
f = open(’keypress_count’,’r’)<br />
key_presses = f.read()<br />
f.close()<br />
if not key_presses:<br />
print "Should not happen."<br />
key_presses = "0"<br />
manual_change = manual_adjustments(str(int(float(actual_bright)/MAX_BL*100)),<br />
key_presses)<br />
if(train_delay_counter == 0):<br />
os.system("icsiboost -S power -n 10")<br />
train_delay_counter = -1<br />
if(manual_change):<br />
return<br />
# skriver till fil klassifierings<br />
sysdata_tuple = sysdata()<br />
battery_level = str(sysdata_tuple[0])<br />
plugged_in = ’T’ if sysdata_tuple[5] else ’F’<br />
skriv = "\n%s, %s, %s, %s, lower"%(key_presses,plugged_in,<br />
21
APPENDIX A. SOURCE CODE<br />
str(int(float(actual_bright)/MAX_BL*100)),battery_level)<br />
f = open(’power.test’,’w’)<br />
f.write("")<br />
f.write(skriv)<br />
print(skriv)<br />
f.close()<br />
lista = boost()<br />
stay = lista[2]<br />
higher = lista[3]<br />
increase = 0<br />
if float(stay) > 0:<br />
pass<br />
elif float(higher) > 0:<br />
increase = 1<br />
delta = int(DIM_PERCENT*0.01*MAX_BL)<br />
if increase == 1:<br />
blint = int(actual_bright) + delta<br />
if blint > MAX_BL:<br />
bl=str(MAX_BL)<br />
else:<br />
bl = str(blint)<br />
else:<br />
blint = int(actual_bright) - delta<br />
if blint < 0:<br />
bl="0"<br />
else:<br />
bl = str(blint)<br />
arst = os.system("python2 illuminator.py %s"% bl)<br />
train_delay_counter -= 1<br />
if train_delay_counter < 0:<br />
train_delay_counter = -1<br />
time.sleep(0.1)<br />
def get_active_window_title(self):<br />
root = subprocess.Popen([’xprop’, ’-root’, ’_NET_ACTIVE_WINDOW’],<br />
stdout=subprocess.PIPE)<br />
22
A.1. DAEMON.PY<br />
for line in root.stdout:<br />
m = re.search(’^_NET_ACTIVE_WINDOW.* ([\w]+)$’, line)<br />
if m != None:<br />
id_ = m.group(1)<br />
id_w = subprocess.Popen([’xprop’, ’-id’, id_, ’WM_NAME’],<br />
stdout=subprocess.PIPE)<br />
break<br />
if id_w != None:<br />
for line in id_w.stdout:<br />
match = re.match("WM_NAME\(\w+\) = (?P.+)$", line)<br />
if match != None:<br />
return match.group("name")<br />
return "active win no"<br />
def boost():<br />
lista = []<br />
read = os.popen("icsiboost -S power -C < power.test; echo $?")<br />
time.sleep(0.1)<br />
rad = read.readline()<br />
lista = rad.split(" ")<br />
return lista<br />
while 1:<br />
kod()<br />
root.mainloop()<br />
23