Real Tests

In order to choose the best predictors to be taken into account for our model, different applications that control each component (while others are turned off) were run, and the battery current discharge was stored; such analysis is important in order to identify the best predictors and the relations that will be used. For the proof of concept purpose, four main subsystems of the tablet were considered: Screen, CPU, WiFi and Audio. Cellular and graphics will be included in the next release. These components were chosen since they show major impact on energy consumption during tests. To derive

a more accurate model, other components such as bluetooth, GPS, 3G, could have been analysed. According to our tests, some components like Audio, they all have binary states, namely on and off. Once turned on, they all show nearly constant battery discharge, regardless of detailed changes. Therefore, Audio only is analysed in our work. The same methodology can be applied to other ”binary-state” modules, such as GPS.

Testing Scenario Description

Utility applications are developed to harvest the relevant data, including CPU fre- quency, CPU usage, WiFi packet rate, WiFi bit rate, battery current, battery voltage, audio state, screen brightness, etc from Samsung Galaxy Note 10.1 tablet. Dedicated applications are developed to load CPU and WiFi NIC to different extents. The above mentioned Android applications were developed on a laptop and installed on a An- droid smart phone and the Android tablet. A wireless router is in place for the real tests on WiFi NIC. In these tests, the Android smart phone and the Android tablet transmit data packets at different bit rates and packet rates between each other. An application is deployed on the tablet to collect the relevant results for inbound traffic and outbound traffic respectively. The whole set-up is shown in Fig.3.5. The USB cable connecting the laptop and the tablet is disconnected during tests so that the tablet is always powered by battery.

Screen

The screen power consumption model is derived using a training program that changes the brightness from 0 % to 100 % using 10 % step intervals each five minutes. The color of the background was also analysed, so the tests were performed for three differ- ent background colors (white, black and blue). As observed from the tests, the colour change results in very slight power changes only. Therefore, blue is used to represent

Figure 3.5: Real Tests : Set-up of Devices

the colour background. All the other components were turned off (WiFi card ,sound, Bluetooth) and the CPU was kept to a low load level, the battery current discharge was recorded.

The results can be seen in the Fig.3.6 below. It is noticed that the brightness is related in a linear way to the power consumed, however, changing the color of the display results in a slight variation of the power consumed, and although interesting, it will not be taken into account for the model since it is a slight variation and the tablet must be rooted to have information of the screen color, which can be an in- convenience for some users. The reason for such a behaviour is that LCD displays have a passive nature, most part of the energy used is to control an external lighting in contrast to OLED displays [165]. The color model for an OLED display can be

done as proposed in [166]. The proposed energy model is shown in equation (3.13), where current discharge changes linear with the change of the brightness regardless of the detailed change of colour. The relation between screen brightness and battery discharge is shown in Fig.3.6: Power is linear to the percentage of brightness settings Brightness, and CScreenis the coefficient.

P ower = CScreen· Brightness (3.13)

Figure 3.6: Relation between Battery Discharge and Screen Brightness

CPU

Many studies indicate that to estimate the power consumed by the CPU it is needed to analyse the load and the operating frequency of the CPU. In order to derive such a model for the CPU, an application written in Linux Script was used, this script ex- ecutes an infinite loop and sleep during a certain amount of the period of this loop; changing this ”sleep time”, permits us to change the CPU load. This application was run, changing the CPU load at every 5 minutes, and the results were recorded. This

test was repeated for 3 different CPU frequencies (200MHz, 800MHz and 1,4GHz), the CPU frequency can be set if the tablet is rooted. Some results are shown in Fig.3.7.

Figure 3.7: Relation between Battery Discharge and CPU Workload

It can be concluded that for a given frequency, the power consumption is linear with the load. This behaviour was also observed by [105], their solution to overcome this problem is to use two different predictors. In our case, the available frequencies are many from 200MHz up to 1400MHz. 100MHz steps are used; but considering a predictor for each frequency could lead to a dissolution of the data, so in order to derive a better model, more tests were performed and regression was conducted for each frequency. The model was derived as in Fig.3.8.

Next, two linear functions are considered to model the CPU. Frequencies from 200 MHz to 800MHz will be modelled as a ”LOW FREQ”, and frequencies from 900 MHz to 1,4 GHz will be modelled as ”HIGH FREQ”. The results are shown in Fig.3.9.

Finally, putting together all the results previously described, a strange behaviour noted when the CPU frequency is not previously set and is controlled by a a dedicated ”CPU frequency governor component” can be explained. If being configured in on demand mode, the governor will change CPU frequency on demand. Given the power

Figure 3.8: Relation between Battery Discharge and CPU Frequency

Figure 3.9: Relation between Battery Discharge and CPU Workload - Two-stage Frequency Setting

consumed in function of the load, a big leap of power for high values of load can be observed, this behaviour was also noted by [5]. However, observing the frequency, such a leap by a changing of the frequency is made by the dedicated ”CPU frequency governor component” as illustrated in Fig.3.10 and Fig.3.11.

Figure 3.10: Relation between Battery Discharge and CPU Workload without Knowing Frequency Settings

Figure 3.11: Relation between Battery Discharge and CPU Frequency Settings

WiFi

to predict its power consumed is a question that must be answered.

In order to find out the relation, to choose the predictor used, and to model the power consumed by the WiFi module, an application that permits the communication between the tablet and a computer via UDP packets in a LAN (Local Area Network), changing the rate of the transmission and the length of the packets (screen is kept off during the experiments) was built. Since the main reason of the present work is to create an energy-aware application to stream video (which is usually done by UDP packets), UDP packets were used instead of TCP. However, other works indicates that the results are similar for TCP packets [105].

To analyse the outbound traffic (from tablet to computer), the application changes its rate every 3 minutes (5 packets/s up to 120 packets/s) and the application was run three times with different packet lengths (614B, 1168B, 1568B). It is observed that the WiFi module activity and the CPU load are very related. Hence, in order to analyse the WiFi impact, the discharge variation caused by CPU is subtracted from the total power using the model previously described.

The results are shown in Fig.3.12, Fig.3.13 and Fig.3.14. It is clear that using the bit rate instead of the packet rate is a more accurate linear model and will lead to bet- ter results, therefore I use it for the inbound traffic. Other works suggest a state-based model [167], I believe that this kind of model could improve the accuracy in estimating the power, however, they are not as practical deploy-wise. This is due to the often lim- ited refreshing rate of battery interface and the lack of knowledge of individual battery. Our effort aims at making the model generic and practical. The results are shown in Fig.3.12 and Fig.3.13. To analyse the inbound traffic (from computer to tablet), similar tests were done, an application changes its rate every 3 minutes (5 packets/s up to 120 packets/s) with a constant length. The results are shown in Fig.3.14. The WiFi energy model is demonstrated in equation (3.14).The Power is determined by both receiving data rate bitraterxand transmitting data rate bitratetx.

Figure 3.12: Relation between Battery Discharge and Bit Rate (Outbound Traffic)

Figure 3.13: Relation between Battery Discharge and Packet Rate (Outbound Traffic)

Figure 3.14: Relation between Battery Discharge and Bit Rate (Inbound Traffic)

Binary-state Module

Different audio volumes were set and a music was played during 8 minutes for each volume level, after that, the audio was turned off during 8 minutes. There is no big variation of the power consumed for different audio volumes, so the model considered is demonstrated by equation (3.15). In equation (3.15), Stateaudio uses 1 and 0 to indicate on and off respectively. Other components such as Bluetooth, WiFi, GPS, network 3G can be analysed similarly.

P ower = βaudio· (Stateaudio) (3.15)