 Good afternoon everyone, I am Anjali Singhal and I will be giving some overview on efficient energy applications for low power devices. So, if you see the smartphone, there are now many smartphones available of like Google and many of you must be using or at least must have seen. So, if we look on the sales per year for the PCs and smartphones, in starting there were 2000 AMD processors were there which were fastest in 2000. Then after 2006 Intel launched their core processors and due to that Intel came in, Intel was the company which has the fastest processors. Then after that GP GPU user came into picture at 2009, then we had ARM processor in 2011 which took over the market which now in all the smartphones and low power devices we use ARM processors. The sales compared to PC every year. Also people are using mobile internet over the desktop internet. This showed that the usage of mobile internet users will be much more than the desktop internet users. So, as we move on from the desktop era to the smartphone era, when we were in the desktop era, we took care of the performance mostly, how to increase the performance. Now, and so that we had GNU processor at all to determine how is the performance of our desktop applications and how we can improve it. Then as we moved on to the smartphone era, now the battery life is limited. So, the thing which we have to take care of most is how to save energy which is the most critical issue in the smartphone era. So, we need an energy processor similar to kind of the GNU processor which will show where the energy is dissipated and how we can conserve it and how we can reduce the energy loss. So, first of all for this you need to know where the energy is spent. If you are running any application, the smartphone is heating up the batteries, the power is reducing. So, where the energy is going? Which component of your smartphone is utilizing that energy and which component is utilizing more energy and which is utilizing less energy. So, there are two approaches which we will be seeing in this talk. The first approach is presented in the paper and analysis of power consumption in that smartphone. This paper is presented by the University of New South Wales in 2010. So, what they say? They also try to measure where the energy is dissipated and how much it is spent. So, the technique which they are using is the hardware technique. So, also the power distribution, the components which mostly they are in the smartphone are CPU, memory, touch screen is their graphics hardware, audio storage and the networking devices. So, they take physical measurement of the power at each hardware component. So, for this testing, the device and the test which they use was the Slinger device. This is very old device and it was totally reconfigurable. So, they use this device. So, as you can see there is an application processor and it has various components like GSM module, Wi-Fi, GPS, Bluetooth and the SD card, graphics, etc. So, whenever you are running any application, each of the devices is consuming some energy. So, what they did to measure this? They used a device, Marshall Instruments, PCI-6229 DAQ. This device they used to measure the voltage and it consisted of the sense registers which they connected to the mobile circuit. So, that they can measure the voltage drop at each component. The peak voltage drop which they set was less than 1% of the supply voltage. So, that the disturbance in the voltage drop will be as minimum as possible. So, now to calculate the power consumed by component, both voltage and current should be known at each hardware component. So, we will see some benchmarking techniques which they used to measure the voltage and current and then to determine how much power each component is consuming. The first of all we will see some terminologies which they used like the total power which is supplying, which we are supplying to the device. That they termed as a total power and the sum of all the total power consumed by all the devices that is the aggregate power. Now, this is not same because of heating and some other external components which if they are attached and they are not considering. And the benchmarks were coordinated on the host machine and they were communicated to the device under test by the serial cable. So, three types of benchmark they ran? One was a micro-benchmark and the micro-benchmark. In the micro-benchmark, the CPU RAM and how much energy, CPU RAM etc. these devices are using, they calculated that. And their peak and the power consumption. And the micro-benchmark, the real usage scenario was considered. Like if there is a smartphone, either there will be a low interactive application like audio and the video in which you will just play that and you will listen or you will watch. And other than that, there will be highly interactive application in which you will use web browsing or supposed text messaging etc. So, to record the highly interactive application, what they did was they used a trace-based approach. Like if I am using a smartphone, so I will create a test. Suppose I will go to a browser, I will open it and I will type some URL and I will browse that page. I will scroll down and again I will close the browser. So, this is a type of a test. So, I will record all the events. I will record where was my coordinates on the touch screen and all these will be recorded and again will be played under the benchmarking situations. So, they will be written to a file in the Linux kernel. Actually, the horse machine is a Linux kernel on which the benchmark will be running. And then under those benchmarking situations, the power consumption of the device and the test will be calculated. So, in Linux kernel, some dev input slash event directory is there in which you can write the event and then you can run those commands on the device under test. So, it was found that in a test team event, major amount of energy is required in delivering the event from the kernel to the software. Suppose a smartphone is there. So, two baseline cases can be there. It can be in them. So, for a smartphone device suppose, then two baseline cases are there. It can be in the suspended device or an idle device. So, the suspended device in which the application processor is idle and the communication processor performs certain activity like the network synchronization has to be done. You want to receive a call, but you are not working anything. So, in that case, the device is the suspended device. So, in this case, in that paper, they found out that the GSM system dominates the consumption of the power and it consumes 45 percent of the total power. Then the device can be in the idle situation where no applications are active and it is fully awake. The display is on, but you are not doing anything. So, in this case, the display dominated and also GSM consumes the power, but display consumes about 50 percent of the total power due to the graphics chip and the LCD screen. So, first we will talk about the microbenchmark, how we can run those and measure the power consumption. So, for CPU and RAM, this is the benchmark specced CPU 2000 suit in which we can, certain standard scripts are there which we can run to find out the power consumption by CPU and the RAM. Then flash storage is there. So, flash storage that is the SD card which we use in the smartphone. So, Linux BD program is there which can find out, which can do the benchmarking of the flash storage. Then for the network which includes the Wi-Fi and the GPRS, which is there in the GSM modem. So, the test was done by downloading a file by WGAT and then finding how much power consumption is there. Then for the GPS, there is a GPS status to Android application which does the same function. So, the microbenchmark, like... We will see how much sending and receiving of the data is being done. The power consumption will be very less compared to the Wi-Fi and GPRS and GSM module we will be using. Yes, sir. It is dominates. Yes, sir. And they are supposed to measure the power consumption on that particular component and it is dominating when we run these programs. So, benchmark the following real usage scenarios. The results actually I have not performed, so I am not discussing on that much. So, in audio file we can just store in the SD card and output is given to the stereo headphones. So, in that GSM power is also included because the GSM module is all the time active. In the video, video was played using the Android's camera application. So, the display and CPU were the biggest consumer of the power. Then text messaging, in this they ran a trace application, trace event in which what they did they opened the contact, then selecting a contact, typing and sending the message and returning to home screen. So, the power consumption was of course dominated by display components. Then phone call, it is also trace based like loading the dial application, dialing and then making a call and the dial devices were configured automatically to receive the call after 10 seconds. So, in this GSM power clearly dominated. Next application is emailing. So, it included opening the email application, downloading and reading emails and replying to two of them. So, this is the standard benchmark which they have set and they ran that. So, clearly GSM consume more power. In web browsing, it can be done either by using Wi-Fi or GSM. So, they ran using both the benchmarks, using the Wi-Fi and GSM. So, what they did, again the user trace based approach and loading a browser application and then selecting a bookmark website and browsing it. So, they ran using Wi-Fi and GPR as both, but GPR is consumed more power by the factor of 2.5. As compared to Wi-Fi. So, web browsing is a real usage scenario. Microbenchmark was using, getting the power consumption for small devices. Yeah, each core component. Yes, but web browsing is a real usage scenario. Any user will, of course, browse the web and it can browse using the Wi-Fi connection or the GSM connection provided by the mobile. Didn't consider GPR is here. No, they considered network. And that was the complex application of browsing a web. So, analysis of this. So, as we can see the majority of power consumption can be attributed to the GSM. And for Wi-Fi. So, I'll show you the results. Actually, they have made a graph. Web browsing can be done by using GPRS. That was one macrobenchmark. And then web browsing can be done using Wi-Fi also. So, they compared the two macrobenchmarks, actually. GSM consume more power. So, the majority of power consumption can be attributed to GSM. And display. And also, like selecting a light on dark color screen can significantly reduce the energy consumption that was seen by the experiment done by this paper. Then, the GSM module consumes both static and the dynamic power. Static because it has to maintain the network connection. And dynamic if it is having some call or if your browsing met. I mean the backlight which is present in the mobile as Android does. It can also save the power up to 40%. And also, obviously, we should shut down the unused components and disable their power supplies if they are not using. Android does that automatically. And RAM, audio and flash systems consistently shows the lowest power consumption. So, they are not that effective. We just have to take care about the GSM and their display mostly. So, this was the hardware approach which we saw. That how we can measure the energy. Now, you see the software approach which was given by the paper. Fine-grained energy counting on smartphone with ePROF. And this was the paper by Purdue University in 2012, the recent paper only. So, they developed a tool called ePROF which was the first energy profiler tool for the smartphone applications. And so, there is one more tool called G-PROF. So, that G-PROF tool also does the same kind of thing, power analysis of power and energy, but for the desktop devices. And also, there is a unique behavior for the smartphone devices that is the asynchronous power behavior, which was not in the case of the desktop devices. So, that is why G-PROF can't handle, G-PROF can't be used for the smartphone devices. We will see what asynchronous power behavior is in the later slides. So, also in the summary, they say that most of the energy in the smartphone applications they spend is due to the IO events. So, they will try to minimize the IO events and we will see how. So, again the key enabler for the power energy consumption is to know where the energy is spent. So, there are few challenges here, which based on this, the ePROF tool works. So, first of all, they find out that they track the activities of the program entities. At the granularity which the developer is interested in. Suppose I want to know that many threads are running in a smartphone at the present time. So, I want to know that each thread is, how much energy each thread is consuming. Or I want to know each subroutine, how much energy it is consuming or a process. So, we should know at which granularity the developer wants the details. So, first of all this that we have to track all those entities. Suppose we want a particular thread, how much energy it is consuming. We have to track the thread first of all, how it is invoked and when it goes to sleep and when it finishes its tasks like that. Next challenge is that to tracking the power to activities of components, each hardware component. That GSM then how much power it is consuming at a particular time and when it goes to sleep of more etc. Then we have to map both of them at the, both of the first and second point. That what program entities are making the particular component drop power. So, the mapping of these two points has to be done in the third point. So, these are the challenges which they face and also our synchronous power behavior. And in summary they say that the ePROF tool finds that in the popular apps the third party advertisement modules in the free apps which we use consume 65 to 75 of the total energy. So, it is a huge amount. And also they track the user data like if you are using a map application. They track where your mobile is, which area you are in etc. So, that also consumes 20 to 30 percent energy. Whereas the real task which the application is doing is consuming only 10 to 15 percent of the total energy. So, first we will find out that how we can account at which granularity the developer wants to work on. So, the entities which the developer wants to account for can be a process, thread, subroutine or system call. So, first of all from the interns how many of them are available, aware of the operating system. So, operating system is an interface between hardware and software obviously. And whenever any call is there, call stack, suppose you run many applications at a time. It is not turning all those applications at the same time. It is switching between those applications at very few microseconds. So, when it switches to the other application, it does the data of the previous application in a stack. Where it maintains about the subroutine which where it has to return after completing the task. And which address the code is written etc. So, that is whenever you call suppose a read function is called for the file, that is a system call. Read, write all those are the system calls. So, in subroutine all the functions which you write are subroutine. A thread, multiple threads are running like multitasking is there in Java. So, we run multiple threads for the parallel execution. And a process, when we run a program it is a process. So, developer may want to account the energy at any of those entities, at any of the level of those entities. Now, how we have to track those entities? We can log the IOS system calls. Then we can also log the call stacks by which we can know which calling routine it is calling, that system call. And which thread it is. We can also log the process and thread IDs at each CPU context which so that we can log about the process and the thread. And the challenge which it is facing is a synchronous power behavior. Like at a time if you have any call, then suddenly the GSM module will go in a very high state. And suppose if you are browsing let and you are downloading a file. Again the GSM module will go in very high state. Then again if your text messaging is done, then the display will go in very high power state. So, suddenly very high power consuming events occur. So, to track them is a challenging task. You are calling your messaging also, you are playing games and you are browsing net also. And power consumed by each IO component is comparable or higher than that by the CPU as by the study done by this paper. So, different power state for a component can be in base state. It can be a zero power state. The component can be totally switched off or it can be on a one or more level of predictive state. Like Wi-Fi can be the signal for the Wi-Fi can be high or low. It can be in a tail state with study about the tail state further. Then it can be in the ideal state except network. This ideal state is for the whole device except network components all components are off. And whereas the above three are for the particular component. So, what we are trying to do is first of all we will track each entity, each thread and then we are talking about the component. How much power each component is using. So, we are trying to find which power state the component is in. It can be in a base state, productive state or tail state. So, what a tail energy is? Like several components, disk, Wi-Fi, 3G, GPS etc. They exhibit tail behavior. Where in activities like suppose a routine is calling the GPS and due to which the GPS goes in the high power state. So, it can trigger a component, a routine can trigger a component to a high power state and stay in that power state long beyond at the end of the routine. Suppose one routine is calling, suppose you are using SD card in a smartphone. You are reading from the SD card and simultaneously you can again write to the SD card. So, more than one routine are using the same component. Suppose you finish the read and then you write on the SD card. Then as soon as you finish the read and then you are again using the write SD card. So, the power state, high power state due to which the SD card was in was due to read. But now after read finishes the component is still in the high power state but due to some other entity that is the write call. So, this refers to a tail energy behavior that the component is still in the high power state even after that entity's end, even after the end of the routine. Now, this wake lock concept is used in Android that wake lock is used because the smartphone is using aggressive sleeping technique that whenever device is not used then just put it into the sleep state. So, what actually is done that a wake, suppose I want to use SD card and suppose I want to read it then the read entity will acquire the wake lock for the SD card then it will trigger the component into a high power state. Now, after the component is in the high power state due to the caller entity that is the read entity in this case. So, the wake lock is acquired for SD card. Now, the component continues to consume the power after the entity is completed even after the read call is completed and other entity start using the component that is you may write or something then still it will be in the high power state. The write will not try to acquire the wake lock again. The wake lock is already acquired by the read lock but to indicate that SD card is in the high power state now. Now, after the component is returned back to idle power state when the wake lock is released. So, it will be going to the zero power state only after the wake lock is released till that it will be in the high power state. So, there is a efficient diagram shown for the wake lock that initially the device is in the idle power state. Now, it will go to the full wake lock when the device is being used that is the high power state and then the wake lock is released then it will again go to the idle power state and suppose the screen is dim. So, some other wake lock is given for that. So, when the screen will be dim then from idle it will go to the screen dim wake lock that is in the background the applications may be running still but the screen is dim. So, in that case it will be consuming less power but it will still be consuming the power and the wake lock is still acquired it is not yet released. And after releasing again it will go to the idle state then the partial wake lock is there. So, similarly this is the wake lock efficient. Now, can be again due to the exotic components like gps, camera etc. Because once these components are switched on by some entity or some system call etc. they continue to drain power until the moment they are switched off. They are seen like the wake locks or the wake lock is used for them only mainly that is they continue to drain power till they are switched off like if you are not using camera but still it is on. So, it will be continue to drain same power. So, this us into a power behavior they are trying to capture it in a FSM, finite state machine. So, what the modeling is the power state each power state will be a node and the transition will be the system calls or any entity a thread process or a system call will take the component into one from one power state to another power state. So, now they are taking an example of the pale energy. What happens is suppose this is a 3G modem. So, what they are doing they are suppose first trying to collect it. Then some system calls are there after collect ramp up then TCP handshake protocol is there and after that we send something. So, what was shown in what they observed in the paper was after the send was over still it consume power. So, even if the device was not in the use. So, this they call as a tail 3G tail that even if the device is not used still it is consuming power. So, the device is totally inactive during that period. So, it is called the tail energy. Similarly, what other test they did was after the collect and the 3G ramp up and TCP handshake protocol they send after 5 second. So, what they saw that even if the send was not there still the 3G tail was there. The device was inactive still it was using the power and then it the first send came and the send was over still it use the power even if it was inactive. So, what they are trying to say that after certain period of time the device goes into the tail energy mode till it is being used again and it is in the tail energy mode for certain period of time specific period of time which is static. And it will be there whether or not it is being used. So, this is the energy which is being wasted. So, even if they have not talked actually about wake lock in this but they are saying that when the GPS is GSM modem is used and we send something. So, actually after the TCP handshake protocol immediately after that the send something was sent the data was sent. And here after the TCP handshake protocol they waited for some time and they waited for 5 second and then they send some data. So, they are trying to say that even if the device was not sending or receiving anything it still went to the tail energy state and it was in tail energy state and suddenly some event came that is the send event and after that So, pardon I didn't get you. Yes. So, I am coming to that point. Yeah. So, as we have seen in the previous diagram that the tail energy was being wasted that the device was not in the use still it was consuming the energy. So, to measure that tail energy they are using the last trigger policy various policies can be used actually. So, what they are trying to do I will explain by the example only. So, they are specifying the energy while they are measuring the energy they are specifying it as an energy tuple u,n where u represent the utilization energy what that component is actually utilizing and the tail energy for that instant. We will see example. Suppose the SD card is there. So, the assistant for SD card they have shown is first it is in the ideal state day state where it is consuming zero power. Now, if any event is coming like file read write etc then it will go to the high power state that is the devil state where it will consume certain amount of current. Then after that it will go to the tail state D2 is the tail state where it will consume less power but it will still consume power. Then in that if when it is in the tail state and any event comes then again it will go to the high power state from the tail state and if any event doesn't come and it is in the tail state then after certain time out time it will go to the day state that is the zero power state. So, who decides that? From that I don't know. It must be something operating system related event only. Because this VM6 is the windows mobile this FSM they have shown is they have tested on two devices one is the android operating system and one is the windows mobile. So, this FSM they have shown is windows mobile. So, the A-clock is not used. So, tail energy is being wasted everywhere. So, now if we are measuring the energy then if we are suppose measuring the energy directly then we will see that for this amount of time so much energy is consumed. So, still we can't know that even after the send is completed why it is consuming the energy. To account for that any component is there. So, at a time a component may be used by many different entities suppose the SD card is there. Many different activities like we may be doing two times read writing on the SD card at the same time and doing several tasks at the same time. So, concurrent access for that device is there always. So, what we will do we will take an example for the concurrent device access. So, this is a SD card usage diagram. So, suppose read call is there for the when read call is being issued to SD card it will go to the high power state then for U1 is the amount of energy which it is using for the high power state. Then it will go to the tail power state for N1. It will stay in the tail power state for certain amount of time then again they are showing that if read is issued still it is not for the concurrent access it is just to show how the tail energy is calculated. So, first read is there so, U1 energy it is using in the high power state. Then it will go to the tail power state and it is using N1 amount of energy. Then after that when it is using it is in tail state and again read command is issued so, it will go to the high power state again from the tail tail state and it will consume suppose U2 amount of energy and while it is in the read state and it has finished the read state so, it is about to go to the tail energy state and we issued a write call. So, it will go to some again high power state for the write call and utilize U3 amount of energy so, after certain time it will go to tail state N2 and again go to the base state so, this is the scenario which we have considered. So, now we want to find the energy tuples for each system call. So, for the read system call the utilization energy is U1 and the tail energy is N1. So, the read system call the utilization energy is U2 whereas, there is no tail energy so, it is 0. So, the write system call as we are using the last trigger policy so, what happens in the last trigger policy is that the tail energy which is there, we add it to the last entity which is using that device so, without seeing it will associate it to the last entity which is used. So, we will associate N2 to the U3 and then we will see that again the device is in the high power state. So, it is having 0 tail energy then again we will see that tail energy is there. So, we will associate it to the previous entity. So, therefore, we can put some energy tuppers that is U1, L1, U2, 0 and U3, N2. So, this is they are saying by using the last trigger policy. That is the tail energy is corresponding to the last entity which is using the component. So, from backside we start. Of course, actually it may be different. I am not sure. Depends on the operating system may be. So, actually the N1 may not be completed in its tail power state in between if there is a call. Yes, sir. Yes, because in the FSM if it is in the tail state and high power state. I didn't take that example. But in if N1 goes down then it will be in a base power state. Then it can again easily calculate. So, this is how we calculate the energy tuppers. Now, there may be concurrent access as we talked about that multiple thread can access the component at the same time. Like if you take Angry Bird application. There is a Flurry application which is a static module which is showing you the advertisement. So, the concurrent thread is being run for the Angry Bird application. So, similarly for our component many concurrent threads may be running. So, what we do? Like now how to find energy tupper in that case when a concurrent access this there. Because we will just find the total energy consumed by the device. So, how are we distributed to each system call or the threads? So, what we do is first to estimate the complete time of the system call. Discrete to. So, all are happening at the same time and the device is in the high power state for this much amount of time and then it is in the tail state for this much amount. So, how do we classify that which system call is using how much energy and what is the tail energy corresponding to that. So, that how we will calculate the technique which they have in this paper they have used is like suppose three events are there, three entities are there. Then we will divide that total time of the high power state such that in each interval different amount of entities are on. Like in this right. Yeah. So, in this only discrete one is running in this only discrete in this only these two are running in this all three are running. Then in this only these two and in this only the last one is running. So, like that they split. Of the component. Like we saw in the diagram D1 and D2. The device is in totally high power state only. So, now we are splitting it according to the entities. So, this is how we calculated the energy that in U1 only discrete one is there in this first interval only U1 is there for corresponding to discrete one. Then in second interval half of it is consumed by discrete one. Then one third of it is consumed in here like that it is there. Like in the fourth interval they considered that only these two reads are running. Whereas this right is running in these two intervals. So, you see the tail energy is corresponding to the last entity which was using that component. So, it will be corresponding to only the discrete two even. And rest all have zero tail energy. So, this is how we calculate the energy tuple. Now, they have not covered for RAM and the LED screen. Because they are accessed at much higher rates. And they exhibit more a synchronous power behavior. So, this was having very high over it. So, they did not cover this part. Now, actually developing this tool. So, now we have got challenges were there and how they overcome that and how they found out the energy tuple etc. Now, the tool which they have developed has three parts. First part is the code instrumentation and the logging. Now, we have to trace the entities like if the thread at the thread level we want the details. Then we have to trace all the threads. If we have to calculate for the processes then we have to trace all the processes. So, the code instrumentation has to be done that is the application source code has to be modified and we have to add the logging code to log all the events, IO events process IDs, thread IDs etc. And then again we have to install it on our mobile. So, after this installing of the application then we will account for the energy which the policy which was the last trigger policy and we find the energy tuples in this energy accounting and then according to those energy tuples we show that present the data. Yes, sir, actually they found. So, the override was very less. They said that 4 to 11 percent 4 to 11 percent over it. Actually written I don't remember it right now. I will tell you later. So, in first phase it is the logging is done and then in the second phase what is being done that first of all all the trace events are calculated. Suppose we want to run for any benchmark then we calculate we record all the input events. Suppose for web browsing we are opening the browser then we are downloading a page then we are so these events are being recorded and then again played in a benchmarking condition and then the energy tuples are calculated and finally it outputs the energy profile. So, the system calls they log by inserting android debugger logging APIs. So, these are used for logging the system calls and to log the calls and calls tag also and also the ARM Linux does not supports server space backtracking from inside the kernel. So, Bionic C library interface was used to log the call C tags. Now what happens like android application is there where source code is not available then how do you trace and log all the events etc. So, what they have done? They modified the framework to automatically start and stop ePROF routine and the system called tracing. So, now the android framework will do all the work of call tracing and logging and then it performs the energy profiling without needing a recompile for the application and then the accounting is done. So, for a particular application ePROF has to be started and then it accounts for the energy the trace has to be again replayed. So, the application framework does that. No. When we have to account. Yeah. In this case you don't know when we are on the app. Yeah, because the source code is not available. Yeah. In this paper they have mentioned that in the previous version of android just in time compiler was not present due to which it used to consume lot huge amount of energy even for the CPU computations. So, this they reduce to greater amount by using the jit compiler in android also. So, this was just a study how jit compiler reduces the power consumption. So, the references which are used were the two papers. Any questions? Let me say 50 percent it is consumed. For example, suspended state it is 50 percent. 50 percent of what? Total power. Like in suspended state only the GSM is running. So, it is consuming the total power which the smart phone is consuming during that state. GSM is consuming 50 percent 40 percent of that total power. It includes idle state also. The idle state is when the device is active the screen is on but you are not doing anything. And suspended what is 100 percent? 100 percent is when your GSM is also on display is also on call is also on. GSM 10 percent will be 100 percent. 10 percent for the actual application if you are running. Thank you.