ARCHITECTURAL SOFTWARE POWER ESTIMATION SUPPORT FOR POWER AWARE REMOTE PROCESSING

ARCHITECTURAL SOFTWARE POWER ESTIMATION SUPPORT FOR POWER AWARE REMOTE PROCESSING Gerald Kaefer, Josef Haid, Karl Voit, Reinhold Weiss Graz University of Technology Graz, AUSTRIA {kaefer, haid, voit, rweiss}@iti.tugraz.at ABSTRACT Mobile devices can reduce their energy consumption through power aware remote processing. Software components running on battery-operated wireless nodes are migrated to wall-power wired remote servers. To increase the efficiency of power aware remote processing, we propose a novel integrated estimator for software component's power energy consumption. This adaptive estimator is based on a software component interface, which provides power timing information. The unit is one of the main components in our framework for power aware remote processing, providing information for efficient internal decision making whether software components are worth for migration or not. Furthermore, we present results from our framework evaluation in Java environment stard wearable computing hardware, using sample software components for AES encryption decryption. KEY WORDS Awareness, Remote Processing, Code Migration, Distributed s, Wireless Networks. 1. INTRODUCTION As wireless communications goes into the realm of network-based services such as wireless internet access video phones, to name a few, the constraints on energy efficiency of portable, battery-operated, h-held devices significantly increase. Furthermore, in mobile wearable systems, the minimization of energy consumption, the time integral of power, is critical to extend battery lifetime. An important aspect of our research is to bring the issue of energy efficiency to higher levels of system design while still keeping transparency for the user, as far as possible for the software engineer. A key requirement is to equip software components with a stard interface that provides information about the software components machine-related energy consumption. Rather than statically assigning software component execution to a local host, we propose a framework which dynamically determines if it is more efficient to migrate software components to a remote machine to retrieve results when the execution was completed. We introduce a novel software power estimation approach, which provides essential information of software components power energy consumption. Additionally, timing information of remote method calls is provided to support intensive system idle state usage. The rest of the paper is organized as follows. Section 2 discusses related work in the area of remote processing dynamic power management. Section 3 gives an overview of our framework. Section 3.1 presents the concept of our power estimation approach. Section 3.2 shortly explains the stard power estimation interface provided by framework software components. Section 3.3 explains the transparent software component migration unit. Section 4 presents the evaluation of the framework in a Java environment presents experimental results demonstrating the efficiency. 2. RELATED WORK Rudenko et al., in [1] have described experiments using portable machines with wireless LAN devices, using simple experimental methods. This paper showed significant possible power savings through remote processing for several realistic tasks. Othman [2] has used simulation to show that battery life can be extended through process migration. The authors ran simulations of servers with different workload bwidth characteristics. The simulation showed that, highly utilized mobile hosts are more likely to benefit from job migration. Again Rudenko et al., in [3] have presented a Remote Processing Framework, which provides system support for making decisions about the efficiency of migrating processes. They have shown the importance of proper decision-making for such a framework showed their own concept of migrating processes. Carla Ellis et al., in [4] have performed some initial experiments on the energy-saving potential of remote execution for the Palm. Their experiments were based on

an IBM Workpad running PalmOS version 3.0 a Dell Dimension PII400 running Sun OS 5.7. The transportation execution of their remote processes were hled by Tcl agents that were part of the D'Agents system. D'Agents is a system already established for hling remote executions from a Palm device using a program called Pilot Launcher. Communication with the server was over a 56K modem. They tested two scenarios: First the size of the data sent the results returned were independent of the amount of computation to be performed which was varied by specifying a number of loop iterations, second the data size transmitted was proportional to the computational intensity of the process. For the first case, the results were as expected: as the computation increased, the energy consumed from local execution eventually began to overcome the constant network costs of remote execution remote execution steadily became more advantageous. On the other h, their experiments with the second scenario never showed an advantage for remote execution, illustrating the importance of selectivity. Lorch [5] Yung-Hsiang [6] have investigated the potential of software controlled power management have presented their strategies for dynamic power management. The Estimation Unit (PEU) is the heart of the Framework for Aware Remote Processing (figure 3). It provides information of software component s power energy consumption. Additionally, timing information is provided. A detailed description is given in subsection 3.1. The Multi Unit (MMU) provides transparent software component migration over the network. A detailed description is given in subsection 3.3. Method Call REMOTE Attribute Set? LOCALl or REMOTE execution attribute set ESTIMATION Attribute Set? PEU PMA Scheduler MMU 3. ARCHITECTURAL SUPPORT Our approach (figure 1) extends stard remote processing concepts [1],[3] with the novel concept of dynamic power estimation of software components. The integration of an adaptive power estimator in each software component is an absolutely novel way of abstraction in software power estimation. Description List Calculation Estimation Unit (PEU) Management Agent (PMA) Scheduling Scheduler Network Resource Management Agent (NRMA) Physical Logical Environment s Environment Remote Network The network provides remote resources for the local device. The physical layer could be wireless or non wireless. Figure 1. Framework for Aware Remote Processing [7]. Multi Unit (MMU) Local Remote s Result of Method Call Figure 2. Framework working cycle. The Management Agent (PMA) has to suggest a distribution of software components among the local the available remote machines in order to reduce the energy consumption of the mobile device. Its constraints are available remote machines, network bwidth, latency, actual battery power. The Scheduler is responsible for starting, running, stopping of software components on the local the remote machines. Its responsibility is to keep short response times. It overrules the proposed component distribution of the PMA, if necessary. The Network Resource Management Agent (NRMA) is a special kind of discovery trading service, responsible for allocating computing resources in the actual wireless network environment. It has to discover remote network servers has to negotiate about bwidth, processing performance, quality of service, financial costs. Figure 2 shows a typical framework working cycle. When a component method is called, the method s attribute is checked. If the attribute is ESTIMATE, the PEU is used to estimate local remote execution time energy consumption. The PMA suggests (relative comparison of energy consumption among the local the remote machines) where to process the method. The Scheduler includes further criteria as latency to

decide where to process the method may overrule the PMA. The MMU transparently migrates executes the method on the determined machine. If the attribute is REMOTE the estimation process is bypassed, the PMA suggests a remote machine with low workload for processing. The LOCAL attribute forces local method execution. 3.1. POWER ESTIMATION UNIT Software components can be grouped in presentation, application, data storing components. A typical application designed for the framework consists at least of three software components, one of each group. In order to investigate the power energy consumption of each component on the local the available remote machines the software components have to support a stard interface for power energy estimation. This interface provides timing information of software component s execution times, which can be used for power energy estimation. The following subsection gives a detailed description of that interface. Calculation to prevent redundant adaptation tasks. In order to reduce the estimation overhead this cache additionally stores the last estimated results of software component s method calls. The MEM internally uses two energy models, namely the Network Energy Model (NEM) the Processor Energy Model (PEM). The NEM estimates the energy consumed for transferring to receiving all necessary data from a remote machine. It considers the bwidth the average latency to a remote machine which is measured. Timing information relevant for migration is supplied by the software components; hardware component power information (e.g. network interface card) is taken from the parameter database. The PEM estimates the expected energy consumption for executing software components. Both, the NEM the PEM make use of the adaptive timing model provided by the Estimation for Software s [8]. To the overall power consumption mainly contributes the system-idle power, the processor power eventually the network power, if the software component makes use of the network connection. The estimated energy consumption for remote execution is based on the energy necessary for transferring the data, the energy consumed while the mobile device stays in idle mode. Description MEM 1 Local MEM 2 Remote 1 MEM N Remote N Estimation Unit (PEU) Local Measurement Unit Cache Figure 3. Estimation Unit (PEU). The PEU (figure 3) internally uses Energy Models (MEM) for the local the remote machines. The internal parameters of the model are quantified using local hardware component benchmark functions a Local Measurement Unit (hardware support for power energy measurement). Parameters are e.g. actual processor power consumption power consumption of additional system components. These parameters are quantified automatically when a hardware component is installed are stored in a system parameter database. The MEM uses the timing information provided by the software component s power estimation interface. Additional system information as actual network bwidth latency are used to estimate power, energy execution time. An internal Cache stores parameters of installed software components 3.2. STANDARD POWER ESTIMATION INTERFACE FOR SOFTWARE COMPONENTS The energy consumption of each software component running on the actual machine is investigated automatically using the Estimation for Software s [8]. According to the interface each software component has to provide timing categorizing attributes, methods for power parameter access description, an internal benchmark function. The public categorizing attributes inform about the component s code size timing models for local remote execution. Additionally, a special attribute determines if the component is mapped statically or has to be estimated mapped dynamically. A benchmark function has to adapt the internal data-time functions (adaptation of the complexity model) per software component method automatically. Our implementation provides time-based parameters, which are related to the software components power consumption. There are timing models for local remote execution. More exact estimation results would be possible by the use of clock cycles instead of time, but we have no support for clock counting on our Java platform. The data-time function (figure 4) is part of the software component s time models. It provides the estimated

execution time depending on the calling method arguments. In our implementation the component developer has to define at least three method arguments spread over the typical argument value range, which are used as fix-points for linear interpolation. For these fix-points (method arguments) the according average processing time is determined by the internal benchmark function. CPU Time [ms] 50ms Interpolated Data- Time Function (symbolic) remote/ local 500 2000 Method 5000 Argument User Defined Argument Values Figure 4. The internal data-time function uses linear fix-point interpolation for CPU-time estimation. The internal CPU-time measurement of our Java runtime environment was very inaccurate for times shorter than 50ms. Therefore with our model (figure 4) we obtained less exact estimations for execution times in this particular range. For functions with non-linear executiontimes the quality of this piecewise continuous linear approximation depends on the non-linearity on the choice of the fix-points. 3.3. MULTI MACHINE UNIT The Multi Unit (MMU) is the part of the framework coping with software component migration (figure 5). Software component migration is provided by transferring the component via Java RMI (Remote Method Invocation) invoking its methods remotely using the Java Reflection package (figure 6). Additionally, the MMU is responsible for the connection management (bindings) to remote servers. The machine which serves as the remote machine is called MMU- Server. There is no need for installation of software components on the MMU-Server, because the mobile device using the service migrates the software components for remote execution on the fly. All essential parts of the software component are transferred over the network remote component usage via Java RMI (current state of the object) class migration via http (Java byte code of the class). Figure 5. Multi Unit overview. One MMU-Server can serve for many potential MMUclients. If the software component should be executed locally through the MMU, a network connection is not matory. The fault-tolerance concept is based on cascaded timeouts. There is a first short timeout (about 500 ms after the estimated time) which should ensure a short response time. If this first timeout of a remote machine is activated, the actual further remote function calls, within the second timeout period are processed locally. If the pending remote function call is not finished within the second timeout period, the remote machine is canceled from the remote machine list. CLIENT starting Java Webserver starting Java Security Manager new Task + execute() Webserver classfile get results END. RMI http request RMI SERVER starting RMI-Registry starting RMI-Engine set codebase to new client classfile local avaliable? Figure 6. Multi Unit software component migration scenario. method found? throw exception END. invoke method send results

4. EVALUATION OF THE FRAMEWORK The framework has been implemented tested in a heterogeneous environment. We have used a battery operated Xybernaut MA TC [9] wearable computer (Pentium III mobile processor with 400 MHz 128 MB RAM) a wall-power wired desktop machine (Pentium IV processor with 1,6 GH 256 MB RAM). Both machines has been installed with Windows 2000 prof.. Communication between mobile device the remote machine was based on wireless LAN (IEEE 802.11b). We used the client adapters an access point (AP) from the Cisco Aironet 340 Series [10]. Both machines ran the Java Virtual version 1.4.0_01. We have chosen this hardware configuration to simulate a possible real-world scenario. The system power consumption has been determined by measurement of voltage current (sample rate 1 khz). In a first step the energy consumption of the Xybernaut MA TC s hardware components has been measured has been used to adapt the hardware energy consumption model of the Estimation Unit. During our measurements, the processor was exclusively managed by the operating system (Windows 2000 prof.). We noticed that the system idle power consumption is relatively high compared to the processing power, which decreased the efficiency. Furthermore, our experiments showed that the processor management of Windows 2000 prof. running the Java Virtual reduced processor usage during waiting for remote processed results (figure 7). For efficiency evaluation we implemented a stard encryption software component. We have chosen the Advanced Encryption (AES) [11], because encryption is an important task in real-world mobile computing is well suited for remote processing. We simulated the scenario in which a device gets an encrypted data package, which it has to decrypt, manipulate encrypt. 5. RESULTS In table 1 table 2 the results of our measurements with the AES computing software component are presented. The first column shows the length of the data to encrypt decrypt. Length in chars encrypt decrypt Execution Time (ms) Total Energy (Ws) 500 14,55 14,76 1863 27,31 1000 15,34 15,53 2832 43,75 2000 15,43 15,56 4764 73,87 5000 15,75 15,83 10589 167,28 8000 15,57 15,57 16564 258,40 15000 15,41 15,33 31136 478,53 Length in chars encrypt decrypt Execution Time (ms) Total Energy (Ws) 500 11,81 11,77 1897 22,36 1000 12,02 11,90 2301 27.38 2000 12,17 12,126 2142 25,97 5000 11,94 11,92 5256 62,64 8000 11,92 11,86 7136 84,63 15000 11,86 11,91 12800 152,38 Table 2. Remote processing results. The other columns show the average system power consumption during software component execution, the execution time, the total measured energy consumption. [W] 18 16 14 12 10 8 6 4 2 0 1 consumption of AES local remote execution (encrypt/ decrypt of 2000 characters) 501 1001 1501 2001 2501 3001 3501 4001 4501 5001 5501 6001 6501 7001 7501 8001 Time [ms] remote local Figure 7. consumption of local remote AES software component execution. For evaluation setup the PEU has been used for absolute energy consumption estimation. Since the implemented software component scheduling algorithm, used by the Management Agent is based on relative comparison of estimated results from the local the remote machines, absolute accuracy is not so important. As already mentioned, the remote server is four times faster than the mobile device, therefore the whole execution time, which includes transmitting the method call receiving the results, was less than the local execution time (figure 7). As already dated, the Java time measurement function was accurate for times greater than 50 milliseconds. For times shorter, there has not been a direct relation between time energy, which has caused problems in modeling. Table 1. Local processing results.

Energy savings through remote processing (AES-algorithm) Savings in percent 70 60 50 40 30 20 10 0 Remote machine is four times faster than mobile machine 500 1000 2000 5000 8000 15000 Length of text to encrypt decrypt (chararcters) Figure 8. Energy savings through remote processing (AES encryption decryption). 6. CONCLUSION In this paper we have presented our concepts of architectural support for power aware remote processing including the evaluation of our Framework for Aware Remote Processing in a Java environment. The framework supports mobile devices equipped with wireless communication, to save battery power transparently. Since there is no direct support for software component migration in Java, the implementation of the MMU is quite complex. There is not yet hardware support for the Local Measurement Unit, which is part of the Estimation Unit. Therefore, we have used an external measurement unit. We expect further stardized support for both in near future. We have shown that it is possible to save about 70 percent (figure 8) of processing energy consumption by using a real world hardware configuration in combination with remote processing. The energy saving depends on the computation task, communication bwidth, system idle power the computation performance of the local the remote machine. In our case the systems idle power consumption has been relatively high compared to the power consumption of the rest of the system, which has decreased the savings obtained from remote processing (figure 7). On the other h we have also noticed a possible remote processing overhead for the encryption of very short strings, illustrating the importance of selectivity. Since the efficiency of remote processing depends on the decision which software components are migrated, it is important to find effective decision criteria. Of course the energy consumption overhead for estimation decision making has to be considered. REFERENCES [1] A. Rudenko, P. Reiher, G. J. Popek, G. Kuenning, The remote processing framework for portable computer power saving, Proc. ACM Symposium on Applied Computing (SAC99), San Antonio, USA, 1999. [2] Othman S. Hailes. conservation strategy for mobile computers using load sharing, Mobile Computing Communications, Review, 2(1), Jan. 1998, 19-26. [3] A. Rudenko, P. Reiher, G. Popek G. Kuenning, Saving portable computer battery power through remote process execution, Mobile Computing Communications Review, 2(1), Jan. 1998. [4] C. Ellis, A. Lebeck, A. Vahdat, support for energy management in mobile embedded workloads: A white paper, Technical report, Duke University, 1999 [5] J. Lorch, A. Smith, Software strategies for portable computer energy management, IEEE Personal Communications Magazine, 5(3), June 1998, 60 73. [6] L. Yung-Hsiang, T. Simunic, G. De Micheli, Software controlled power management, Proc. IEEE Hardware/Software Co-design Workshop, Rome, Italy, 1999. [7] G. Kaefer, J. Haid, B. Hofer, G. Schall R.Weiss, Framework for power aware remote processing: Design implementation of a dynamic power estimation unit, Proc. 5th IEEE International Symposium of Wearable Computing (ISWC01), Zurich, Switzerl, 2001. [8] G. Kaefer, J. Haid, G. Schall, R. Weiss, The stard power estimation interface for software components, Proc. Telecommunications Mobile Computing (TCMC2001), Graz, Austria, 2001. [9] Xybernaut, http://www.xybernaut.com. [10] Cisco, http://www.cisco.com. [11] AES, http://csrc.nist.gov/encryption/aes/.