formulasearchengine - User contributions [en]

Recursive tree

2014-11-05T02:26:21Z

134.190.164.79:

The author is known by the name of Figures Lint. Hiring is his profession. Body building is 1 of the issues I love most. His family lives in South Dakota but his spouse desires them to transfer.<br><br>Feel free to visit my site - [http://www.ubi-cation.com/ubication/node/6056 http://www.ubi-cation.com/]

Binning (Metagenomics)

2014-01-28T16:32:43Z

134.190.152.80: /* Other algorithms */

{{multiple issues|
{{Orphan|date=October 2013}}
{{Original research|date=December 2012}}
}}

{{Tech|date=November 2012}}

Electronic systems’ '''[[power consumption]]''' has been a real challenge for Hardware and Software designers as well as users especially in portable devices like cell phones and laptop computers. Power consumption also has been an issue for many industries that use computer systems heavily such as Internet service providers using servers or companies with many employees using computers and other computational devices.<ref>{{cite journal|last=Mudge|first=T.|title=Power: a first-class architectural design constraint|journal=Computer|date=Apr 2001|year=2001|month=April|volume=34|issue=4|pages=52–58|doi=10.1109/2.917539|url=http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=917539&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D917539}}</ref> Many different approaches (during design of HW, SW or real-time estimation) have been discovered by researchers to estimate power consumption efficiently. This survey paper focuses on the different methods where power consumption can be estimated or measured in real-time.

Measuring real time power dissipation is critical in thermal analysis of a new design of HW like processors (CPU) just as it is important for OS programmers writing process schedulers.<ref name="Real time power estimation"/><ref name= "PC3">{{cite journal|last=Li|first=Tao|coauthors=John, Lizy Kurian|title=Run-time modeling and estimation of operating system power consumption|journal=ACM SIGMETRICS Performance Evaluation Review|date=10 June 2003|volume=31|issue=1|pages=160|doi=10.1145/885651.781048}}</ref> Researchers discovered that knowing the real-time power consumption on a subsystem level like CPU, hard drives, memory and other devices can help power optimizations in applications such as storage encryption, virtualization, and application sandboxing, as well as application tradeoffs.<ref name="Low-cost Estimation of Sub-system Power">{{cite web|last=Sun, Wanner, and Srivastava|first=Yuwen, Lucas and Mani|title=Low-cost Estimation of Sub-system Power|url=http://nesl.ee.ucla.edu/fw/documents/conference/2012/Sun_IGCC_2012.pdf}}</ref>

Different technologies have been discovered that can enable measuring power consumption in real-time. They can be ranked in two main categories: direct measurement using subsystem power sensors and meters or indirect estimation based on provided information like temperature or performance counters.<ref name="Low-cost Estimation of Sub-system Power"/> There are also different methods within each category; for example, different models are discovered to use performance counters for power estimation. Each one of these methods has its own benefits and disadvantages. The goal of this paper is to '''[[survey]]''' that different methods in each category.

==Run-time Estimation of System and Sub-system Level Power Consumption==

Power consumption can be different for the same type of system because of differences in manufacturing of Hardware and in temperature conditions in which the device is going to operate. Real-Time power management can be used to optimize the system or subsystems to minimize the energy consumption which may, for example, extend the battery lifetime of mobile devices or result in energy savings for Internet companies operating with many computer servers.<ref name="Low-cost Estimation of Sub-system Power"/> The following sections are technologies discovered to enable real-time power estimation.

==Indirect Power measurement==

Indirect power measurement such as using a CPU performance monitoring unit (PMU),<ref name="System-level power estimation">{{cite journal|last=Cho|first=Youngjin|coauthors=Younghyun Kim, Sangyoung Park, and Naehyuck Chang|title=System-level power estimation using an on-chip bus performance monitoring unit|year=2008|pages=149–154|url=http://dl.acm.org/citation.cfm?id=1509456.1509499}}</ref> or performance counters to estimate run-time CPU and memory power consumption <ref name="Intel XScale">{{cite journal|last=Contreras|first=G.|coauthors=Martonosi|title=Power prediction for Intel XScale® processors using performance monitoring unit events|date=8-10 Aug. 2005|year=2005|doi=10.1109/LPE.2005.195518 |url=http://dx.doi.org/10.1109/LPE.2005.195518}}</ref> are widely used for their low cost.

===Performance counters===

What are '''[[performance counters]]'''? [[Hardware performance counter]]s (HPCs) are a set of special purpose registers built into modern microprocessors to store the counts of hardware-related activities for hardware and software related events.<ref name="Low-cost Estimation of Sub-system Power"/> Different models of processors have limited numbers of hardware counters with different events that will satisfy the CPU requirement.<ref>{{cite web|title=Hardware Performance Counters at:|url=http://en.wikipedia.org/wiki/Hardware_performance_counter}}</ref> These performance counters are usually accurate and provide important detailed information about processor performance at the clock cycle granularity.<ref name="Can hardware?">{{cite journal|last=Weaver|first=V.M.|coauthors=McKee, S.A.|title=Can hardware performance counters be trusted?|date=30 September 2008|issue=14-16 Sept. 2008|doi=10.1109/IISWC.2008.4636099|url=http://dx.doi.org/10.1109/IISWC.2008.4636099}}</ref> Researchers were able to create different models that use the HPCs event to estimate the system power consumption in real-time.

====First-order, linear power estimation model using performance counters====

The first-order linear model was developed by G. Contreras and M. Martonosi at Princeton University using Intel PXA255 processor to estimate CPU and memory power consumption.<ref name="Intel XScale"/> This is distinct from previous work that uses HPCs to estimate power because the Intel PXA255 processor power requirement was tighter and it offered fewer available performance events compared to mid and high-end processors.<ref name="Intel XScale"/> This method is also not tied to specific processor technology and HPCs layout for power estimation but rather can be used for any type of processor with HPCs.

This linear power model uses five performance events as follows: Instruction Executed, Data Dependencies, Instruction Cache Miss, Data TLB Misses, and Instruction TLB Misses. A linear model expression is derived (equation 1) as follows assuming a linear correlation between performance counters values and power consumption.<ref name="Intel XScale"/>

<math>Powe{{r}_{cpu}}={{\propto }_{1}}\left( IFetc{{h}_{miss}} \right)+{{\propto }_{2}}\left( DataDep \right)+{{\propto }_{3}}\left( DataTL{{B}_{miss}} \right)+{{\propto }_{4}}\left( InsTL{{B}_{miss}} \right)+{{\propto }_{5}}\left( InstExec \right)+{{K}_{cpu}}</math> (1)

Where, <math>{{\propto }_{1}},{{\propto }_{2}},{{\propto }_{3}},{{\propto }_{4}},{{\propto }_{5}}</math> are power weights and <math>{{K}_{cpu}}</math> is a constant for processor power consumption during idle time.

One can also estimate power consumption of memory (external RAM) by tracking the performance events if they are available on the designed processor.<ref name="Intel XScale"/> PXA255 processor, for example, does not have direct performance events accounting for external RAM but Instruction Cache Miss, Data Cache Miss, and Number of Data Dependencies on processor can be used to estimate the memory power consumption. Again, a linear model is derived from the given information (equation 2) to estimate the memory power consumption.<ref name="Intel XScale"/>

<math>Powe{{r}_{memory}}={{\beta }_{1}}\left( IFetc{{h}_{miss}} \right)+{{\beta }_{2}}\left( DataDep \right)+{{K}_{memory}}</math> (2)

Where, <math>{{\beta }_{1}},{{\beta }_{2}}</math> are power weights and <math>{{K}_{memory}}</math> is a power consumption constant during idle time.

The main challenging issue with this method is computing the power weights using a mathematical model (ordinary Least Squares Estimation) at different voltage/frequency points. These constant values in equations 1 and 2 are voltage and frequency depends and they must be computed during benchmark testing. After building such a table for the power weights parameters, then the table can be implemented in software or hardware to estimate the real-time power.<ref name="Intel XScale"/> The other challenge is in accessing HPCs; for example, in this case they are being read at the beginning of the main OS timer interrupt which requires a software modification. A software program can be written using the equations 1 and 2 and the estimated power weights derived from the table to estimate the power consumption at run-time. For equation 1 the program also needs 5 samples of HPCs but in this example the PXA255 processor can only sample 2 events at any given time therefore multiple code execution is required as well as aligning the data.<ref name="Intel XScale"/>

In summary, the main benefits of this approach are that it is easy to implement, low cost, and does not require special hardware modification. Software designers can benefit from this model by having a quick power estimate for their applications without any extra hardware requirement.<ref name="Intel XScale"/>

The main disadvantage of this method is that: real world processors are not perfect and this model does not account for non-linear relationships in those processors. Another issue is also the software overhead running on the processor that consumes power. This approach also does not provide detailed information about power consumption in each architectural functional unit so designers can’t see the difference between each module by executing different parts of the software. This method can’t be used by OS scheduler or software developers executing multi threaded programs because it needs to gather data by running benchmarks several times.<ref name="Real time power estimation">{{cite journal|last=Singh|first=Karan|coauthors=Bhadauria, Major; McKee, Sally A.|title=Real time power estimation and thread scheduling via performance counters|journal=ACM SIGARCH Computer Architecture News|date=23 July 2009|volume=37|issue=2|pages=46|doi=10.1145/1577129.1577137}}</ref> This work is also good for single core processors but not multi-core processors.

====Piece-wise linear power estimation model using performance counters====

The piece-wise model was developed to estimate power consumption accurately using performance counters. This method was developed by K.Singh, M.Bhadauria at Cornell University and S.A.McKee at Chalmers University of Technology independently of program behavior for SPEC 2006, SPEC-OMP and NAS benchmark suits. This method was developed to analyze the effects of shared resources and temperature on power consumption for chip multiprocessors.<ref name="Real time power estimation"/>

This method used 4 performance counters of AMD Phenom processor. The performance counters are as follows: <math>{{\text{ }\!\!\varepsilon\!\!\text{ }}_{1}}</math>: L2_CACHE_MISS: ALL, <math>{{\text{ }\!\!\varepsilon\!\!\text{ }}_{2}}</math>: RETRIED_UOPS, <math>{{\text{ }\!\!\varepsilon\!\!\text{ }}_{3}}</math>: RETIRED_MMX_AND_FP_INSTRUCTIONS: ALL, <math>{{\text{ }\!\!\varepsilon\!\!\text{ }}_{4}}</math>: DISPATCH_STALLS. These performance counters are architecturally specific to AMD Phenom and may be different for other processors. AMD allows collecting data from those four HPCs simultaneously.<ref name="Real time power estimation"/> A microbenchmarks, which is a small program, attempts to collect data from the above selected HPCs. Collected data on each processor core are used in the following equation.<ref name="Real time power estimation"/>

<math>{{P}_{core}}=\left\{ \begin{matrix}
{{F}_{1}}\left( {{g}_{1}}\left( {{r}_{1}} \right),\ldots \ldots ,{{g}_{n}}\left( {{r}_{n}} \right) \right),if\text{ }condition \\
{{F}_{2}}\left( {{g}_{1}}\left( {{r}_{1}} \right),\ldots \ldots ,{{g}_{n}}\left( {{R}_{n}} \right) \right),else \\
\end{matrix} \right.</math> (3)

Where <math>{{r}_{i}}={{\varepsilon }_{i}}/(cycle\text{ }count)</math>
<math>{{F}_{n}}={{P}_{0}}+{{P}_{1}}*{{g}_{1}}\left( {{r}_{1}} \right)+\ldots \ldots +{{P}_{2}}*{{g}_{n}}({{r}_{n}})</math> (4)

Equation 4 transformation can be linear, inverse, logarithmic, exponential, or square root; it depends on what makes the power predication more accurate. Piece wise linear function was chosen to analyze equation 4 from collected data because it will capture more detail about each processor core power. Finally, analyzing the collected HPCs data with piece wise linear method gives the detailed power consumption (for example, L2 cache misses has the highest contribution in power consumption versus L3).

The above method was used to schedule each AMD Phenom processor core in a defined power envelope. The processors core gets suspended when the core exceeds the available power envelope and it becomes available again when enough power becomes available.<ref name="Real time power estimation"/>

There are some restrictions and issues with this method; for example, this method does not account for temperature effect. There is a direct relationship between temperature and total power consumption (because as temperature increases the leakage power goes up) that this model does not account for because AMD Phenom does not have per-core temperature sensors. A second disadvantage is that mictobenchmarks is not complete to get a better power estimate (for instance, it does not cover the DISPATCH_STALLS HPC). A more complete microbenchmark will cause timing issues. Future work needs to be done to incorporate thermal data into the model and thread scheduling strategies as well as to reduce frequency (DVFS) of each core versus suspending the core.<ref name="Real time power estimation"/> This method only covers processors but there are other subsystems, like memory, and disks, that also need to be considered in total power.

This method is different from many other methods using performance counters because all the cores in multi core processors are considered, the performance counters being used do not individually have high effect with power consumption and it estimates the power consumption for each core that can be used for real time scheduling of each core to be under power envelope.<ref name="Real time power estimation"/>

====Adaptive power estimation model using performance counters====

Most models like the above do not have the capability to measure power consumption at a component or subsystem level. '''DiPART''' (Disaggregated Power Analysis in Real Time) developed by Professor M. Srivastava, Y. Sun, and L. Wanner at University of California, Los Angeles enables this capability to estimate power consumption based on hardware performance counters and using only one power sensor for the whole system.<ref name="Low-cost Estimation of Sub-system Power"/> Models are required to estimate power consumption based on performance counters. These models correlate the data for different performance counters with power consumption and static models like above examples (First-order and Piece-wise linear) have different estimation errors due to variations across identical hardware.<ref name="Low-cost Estimation of Sub-system Power"/> DiPART is a solution to this problem because it is a self-adaptive model that can be calibrated once and be applied across different platforms.

The linear estimation model for DiPART requires a power sensor capable of acquiring dissipated power consumption and current measurement at run time. There are different embedded sensors like Atom-LEAP system <ref name="The Atom LEAP Platform">{{cite journal|last=Singh, and Kaiser|first=Digvijay, and W J.|title=The Atom LEAP Platform For Energy-Efficient Embedded Computing|date=2010-05-26|month=June|url=http://escholarship.ucop.edu/uc/item/88b146bk}}</ref> or Qualcomm’s Snapdragon Mobil Development Platforms <ref>{{cite web|title=Qualcomm. Snapdragon MSM8660 Mobile Development Platform. Available at:|url=https://developer.qualcomm.com/}}</ref> that can do the job for DiPART. One single power sensor can be used to calibrate the subsystem level estimation model DiPART.<ref name="Low-cost Estimation of Sub-system Power"/>

Total power of the system is the summation of the power consumption by each subsystem shown in equation 5.

<math>{{P}_{system}}={{P}_{CPU}}+{{P}_{RAM}}+{{P}_{Disk}}</math> (5)<ref name="Low-cost Estimation of Sub-system Power"/>

For each subsystem, power performance counters are being used. For CPU power, ten performance counters are required as follows: Task counts, Context Switch counts, CPU Migration counts, Page Fault counts, Cycles counts, Instruction counts, Branches counts, Cache Refer counts, and Cache Miss Counts. Then a linear model is used to compute the total power of CPU and coefficient values are computed with a liner regression algorithm using performance counter data and monitored power consumption data.<ref name="Low-cost Estimation of Sub-system Power"/>

<math>{{P}_{CPU}}=\left[ \propto ,\beta ,\ldots \gamma \right]*Vecor\text{ }of\text{ }CPU\text{ }performance\text{ }Counters+{{\lambda }_{constantCPU}}</math> (6)<ref name="Low-cost Estimation of Sub-system Power"/>

The above performance counters can also be used for RAM power consumption model and the memory coefficient vector and the constant value is also computed during training phase with performance counter data and monitored power consumption data.

<math>{{P}_{RAM}}=\left[ \text{ }\!\!\Delta\!\!\text{ },\text{ }\!\!\Gamma\!\!\text{ },\ldots \text{ }\!\!\Theta\!\!\text{ } \right]*\text{ }Vector\text{ }of\text{ }Performance\text{ }Counters+{{\lambda }_{constantRAM}}</math> (7)<ref name="Low-cost Estimation of Sub-system Power"/>

Disk power consumption model is based on input counter and output counter correlated with Input/Output events counters.

The same approach is taken as for CPU and RAM to estimate the coefficient and constant for disk power during training phase.<ref name="Low-cost Estimation of Sub-system Power"/>

<math>{{P}_{Disk}}=\left[ \varphi ,\chi \right]*\text{ }Vector\text{ }of\text{ }Disk\text{ }performance\text{ }counter+{{\lambda }_{constantDisk}}</math> (8)<ref name="Low-cost Estimation of Sub-system Power"/>

During training the total power measured from the sensor is subtracted from the initial CPU, RAM, and Disk power model predication. Then 10% from the delta result is taken to compensate in individual subsystems CPU, RAM and disk models. This iteration will continue until estimation error for total system power is smaller than some threshold, or it hits the specified number of iterations. During this training process with some number of iteration process each subsystem model gets adjusted accordingly base on the delta percentage. Once the subsystems are trained the total system does not need to be trained.

The CPU, RAM, and Disk power model modification and system-level variation is required if the total delta is not less than 10%. The iteration process will continue until the individual subsystem power model prediction gets close to the monitored total power. When subsystem power consumption model has been trained the total system level power consumption model does not need to train again for the same system.

This method is beneficial compared to static models because of its adaptability to the variations among different systems even with exactly the same hardware. The experimental results show that estimated errors are high before training the DiPART, and that the error decreases as the number of iteration increases.

One major issue with this model is the dependency on power sensors to measure the total power. The other issue is the number of performance counters being used for DiPART model. These performance counters might not be available for all processors. This method was also used for CPU, RAM and disk subsystem but there are other subsystems that need to be considered in total power consumption. The main problem with adding more subsystems will be the adaptive mechanism because as the number of subsystems increases, the accuracy and training speed will decrease.<ref name="Low-cost Estimation of Sub-system Power"/> Another issue is that the CPU, Disk and RAM are also not perfect and have some non-linearity part that was not considered in this method.

===Dynamic Thermal Management===

As the Integrated Circuit (IC) technology size is getting smaller in nanometer scale and more transistors are put together in that small area, the total power and temperature on chip are also increasing. The high temperature on the chip, if not controlled, can damage or even burn the chip. The chip high temperature also has impacts on performance and reliability.<ref name="Efficient thermal simulation">{{cite journal|last=Hang|first=Li|coauthors=Pu Liu ; Zhenyu Qi ; Lingling Jin ; Wei Wu ; Tan, S.X.D. ; Jun Yang|title=Efficient thermal simulation for run-time temperature tracking and management|date=31 October 2005|doi=10.1109/ICCD.2005.46}}</ref><ref name="Fast thermal simulation">{{cite journal|journal=Proceedings of the 2005 IEEE/ACM International conference on Computer-aided design |title=Fast thermal simulation for architecture level dynamic thermal management |last=Lie|first=Pu|coauthors=Zhenyu Qi, Hang Li, Lingling Jin, Wei Wu, S. X. -D. Tan, Jun Yang|year=2005|url=http://dl.acm.org/citation.cfm?id=1129693}}</ref> High chip temperature causes more leakage power consumption, higher interconnect resistance and slower speed of transistors.<ref name="Efficient thermal simulation"/> Therefore Dynamic Thermal Management (DTM) is required for high performance embedded systems or high-end microprocessors. Thermal sensors are also not perfect for the job because of their accuracy and long delay to capture the temperature. The DTM idea is to detect and reduce the temperature of hot units spots in a chip using different techniques like activity migration, local toggling, dynamic voltage and frequency scaling.<ref name="Efficient thermal simulation"/>

A new method was developed by H. Li, P. Liu, Z. Qi, L. Jin, W. Wu, S.X.D Tan, J. Yang at University of California Riverside based on observing the average power consumption of low level modules running typical workload.<ref name="Efficient thermal simulation"/> There is a direct correlation between the observation and temperature variations. This new method was a solution to replace the old technologies such as on-line tracking sensors on the chip like CMOS-based sensor technology that are less accurate and requires hardware implementation.<ref name="Dynamic thermal">{{cite journal|last=Brooks|first=D.|coauthors=Martonosi, M.|title=Dynamic thermal management for high-performance microprocessors|date=7 August 2002|doi=10.1109/HPCA.2001.903261|url=http://dx.doi.org/10.1109/HPCA.2001.903261}}</ref>

This method is based on observing the average power in a certain amount of time which determines the temperature variations. This idea can be implemented with a fast run-time thermal simulation algorithm at architectural level.<ref name="Efficient thermal simulation"/> This method also presents a new way to compute the transient temperature changes based on the frequency domain moment matching concept. The moment matching concept is basically said that the transient behaviors of a dynamic system can be accurately described by a few dominant poles of the systems.<ref name="Efficient thermal simulation"/> The moment matching algorithm is required to compute the temperature variation response under initial temperature conditions and average power inputs for a given time.<ref name="Efficient thermal simulation"/> This method also follows circuit level thermal RC modeling at the architectural level as described in reference.<ref name="Compact thermal modeling">{{cite journal|last=Huang|first=Wei|coauthors=Mircea R. Stany, Kevin Skadronz, Karthik Sankaranarayanan|title=Compact thermal modeling for temperature-aware design|journal=2004|date=April 2004|url=http://www.cs.virginia.edu/~techrep/CS-2004-13.pdf}}</ref> The unit temperature variation during run-time is because of the irregular power trance generated by each unit in their architectural blocks.<ref name="Efficient thermal simulation"/> This power input is consistent of DC and small AC oscillation. It was also shown and proven that most of the energy in the power trace concentrates on the DC component. Therefore the average power can be described as a constant DC input to thermal circuit. After all a thermal moment marching (TMM) with initial condition and DC input is required to be implemented. The TMM model is as follows:

<math>Gx+Cx=Bu</math> (9)

G and C are conductive and capacitive circuit matrices, and x is the vector of node temperature.<ref name="Efficient thermal simulation"/> u is the vector of independent power source and B is the input selector matrix. This equation will be solved in frequency domain and the initial condition is required which will be the initial temperature at each node.<ref name="Efficient thermal simulation"/>
The main idea is to implement the TMM algorithm which provides better reliable on-line temperature estimation for DTM applications.

In summary, the TMM algorithm is much faster than the previous work in this area to estimate the thermal variation because this method is using frequency domain moment matching method. The other work (like HotSpot) uses the integration method where it needs all previous points to obtain the temperature at certain running point. This will make the simulation time longer.

This work can also be improved by computing the average power real-time using performance counters. This method can be added to the above models using performance counters to estimate on the fly temperature variation as the programs are getting executed.

===PowerBooter and PowerTutor===

This power model technique was developed by collaboration between L. Zhang, B. Tiwana, Z. Qian, Z. Wang, R.P. Dick, Z.Mao from University of Michigan and L. Yang from Google Inc. to accurately estimate power estimation online for Smartphones.<ref name="Accurate online power">{{cite journal|last=Zhang|first=Lide|coauthors=Birjodh Tiwana, Zhiyun Qian, Zhaoguang Wang, Robert P. Dick, Zhuoqing Morley Mao, Lei Yang|title=Accurate online power estimation and automatic battery behavior based power model generation for smartphones|year=2010|doi=10.1145/1878961.1878982|url=http://dl.acm.org/citation.cfm?doid=1878961.1878982}}</ref> '''PowerBooter''' is an automated power model that uses built-in battery voltage sensors and behavior of battery during discharge to monitor power consumption of total system. This method doesn’t require any especial external measurement equipment. '''PowerTutor''' is also a power measurement tool that uses PowerBooter generated data for online power estimation. There is always a limitation in [[Smartphone]] technology battery life span that HW and SW designers need to overcome. Software designers don’t always have the best knowledge of power consumption to design better power optimized applications therefore end users always blame the battery lifespan. Therefore, there is a need for a tool that has the capability to measure power consumption on Smartphones that software designers could use to monitor their applications in real-time. Researchers have developed specific power management models for specific portable embedded systems and it takes a huge effort to reuse those models for a vast variety of modern [[Smartphone]] technology. So the solution to this problem is PowerBooter model that can estimate real-time power consumption for individual [[Smartphone]] subsystems such as CPU, LCD, GPS, audio, Wi-Fi and cell phone communication components. Along with PowerBooter model an on-line PowerTutor utility can use the generated data to determine the subsystem level power consumption. The model and PowerTutor utility can be used across different platforms and [[Smartphone]] technologies.

This model is different from the other models discovered because it relies only on knowledge of the battery discharge voltage curve and access to battery voltage sensor which is available in all modern Smartphones.<ref name="Accurate online power"/> The basic idea for this model technique is to use battery state of discharge with running training software programs to control phone component power and activity states. Each individual [[Smartphone]] component is held in a specific state for a significant period of time and the change in battery state of discharge is captured using built-in battery voltage sensors.<ref name="Accurate online power"/> The first challenging idea is to convert battery voltage readings into power consumption. This is determined by state of discharge (which is total consumed energy by battery) variation within a testing interval captured by voltage sensors that will eventually drive the following equation.

<math>P*\left( {{t}_{1}}-{{t}_{2}} \right)=E*(SOD\left( {{V}_{1}} \right)-SOD\left( {{V}_{2}} \right))</math> (10)

Where E is the rated battery energy capacity and SOD (Vi) is the battery state of discharge at voltage Vi and P is the average power consumption in the time interval t1 and t2. The state of discharge can be estimated using look up table where the relationship between present voltage and SOD is captured. Determining the energy is also an issue because the energy is changing as the battery gets old. The new batteries have the total energy written on their back but the value can’t be true for all time. It can estimate the energy at highest and lowest discharge rate to decrease the error. The internal resistance also has significant impact on the discharged current. To decrease the effect of internal resistance all the phone components can be switched to their lowest power modes to minimize the discharge current when taking a voltage reading. Finally, this method uses a piece-wise linear function to model the non-linear relationship between SOF and battery voltage.

The above battery model can be all automated with 3 steps which are described in.<ref name="Accurate online power"/> In conclusion, this method is beneficial because all Smartphones can use this method and for new Smartphones this model needs to be constructed only once and after automating the process there would be no need for any extra equipment to measure power consumption. Once the model is generated automatically or manually the PowerTutor utility can use the data to estimate power consumption in real time. Software engineers can use this utility to optimize their design or users can use this tool to make their decision about buying applications based on the power consumption.

The main issues are in computing the energy which adds up to accuracy of the power model. Another issue is also considering the internal resistor to read the voltage. This can be resolved in newer versions of Smartphones that provide current measurement instead of voltage. The above model needs to be modified using the current measurement.

'''Appscope''' <ref>{{cite web|last=Yoon, Kim, Jung, Kang, Cha|first=Chanmin, Dongwon, Wonwoo, Chulkoo, Hojung|title=AppScope: Application Energy Metering Framework for Android Smartphones using Kernel Activity Monitoring|url=https://www.usenix.org/sites/default/files/conference/protected-files/yoon_atc12_slides.pdf}}</ref> and '''DevScope''' <ref>{{cite journal|last=Jung, Kang, Yoon, Kim, Cha|first=Wonwoo, Chulkoo, Chanmin, Donwon, Hojung|title=DevScope: a nonintrusive and online power analysis tool for Smartphone hardware components|year=2012|doi=10.1145/2380445.2380502|url=http://dl.acm.org/citation.cfm?doid=2380445.2380502}}</ref> are similar work to estimate [[Smartphone]] power consumptions.

===Run- time modeling and estimation of operating system power consumption===

The operating system (OS) is the main [[software]] running on most computing systems and contributes a major component in dissipating power consumption. Therefore, operating system model was developed by T. Li and L.K John from University of Texas at Austin to estimate the power consumption by OS that helps power management and software applications power evaluation.<ref name= "PC3"/>

It’s been computed that software execution on hardware components can dissipate a good portion of power consumption.<ref>{{cite web|title=Intel Power Gadget Software Tool at:|url=http://software.intel.com/en-us/articles/intel-power-gadget-20}}</ref> It’s also been shown that the choice of algorithm and other higher level software code decisions during the design of software could significantly affect system power. Many of these software applications rely on operating system; therefore, overlooking the estimated power consumption by OS could cause huge error in energy estimation. Estimating OS power consumption could help software designers optimize their code design to be more energy efficient. For example, software engineer; can observe the power consumption when using different compiling techniques to handle TLB misses and paging.<ref name="Accurate online power"/> A good OS model needs to have the following properties to be good enough for thermal or power management tools. The model needs to be highly reliable, fast, and it also should have run-time estimation capability that does not increase overhead. The model should be simple and easily adoptable across different platforms.

The purposed run-time power estimation requires a first order linear operation on a single power metric, reducing estimation overhead.<ref name="Accurate online power"/> The Instruction per Cycle (IPC) can be used as the metric to characterize the performance of modern processors. In paper <ref name="Accurate online power"/> shows how various components in the CPU and memory systems contributes to the total OS routine power. Data-path and pipeline structure along with clocks are consuming the most power. A linear model can be derived from IPC that tracks the OS routine power. A simple Energy equation <math>E=P*T</math> can be used to estimate a given piece of software energy consumption, where P is the average power and T is the execution time of that program.

The challenging part is to compute the average power P for each individual routine of operation system. One can use the correlation between IPC and OS routine average power or hardware performance counters can be used. The profiling method (data gathered from benchmark testing) can also be used to predict the energy consumption. The linear power model in <ref name="Accurate online power"/> is as follows:<math>{{P}_{OS}}={{K}_{1}}*\text{ }IP{{C}_{OS}}+{{K}_{0}}</math>. This is a simple linear model that shows a strong correlation between IPC and OS routine power. In this approach profiling is also required to generate data needed to build the model. After the model is generated for one system, then it is not needed again for the same system.

===Virtual Machine Power Metering and Provisioning===

Joulemeter is a proposed solution by A.K.Feng Zhao from Microsoft Inc. and N.Kothari from University of Southern California, Los Angeles and A.A. Bhattacharya from Indian Institute of Technology to measure virtual machine power which cannot be measured directly in hardware.<ref name="Virtual machine power">{{cite journal|last=Kansal|first=Aman|coauthors=Feng Zhao, Jie Liu, Nupur Kothari, Arka A. Bhattacharya|title=Virtual machine power metering and provisioning|year=2010|doi=10.1145/1807128.1807136}}</ref> This method is used for power management for virtualized data centers. Most servers today have power metering and the old servers use power distribution units (PDUs). This method uses those individual power meters to save significant reduction in power provisioning costs.

This method uses power models in software to track VM energy usage on each significant hardware resource, using hypervisor-observable hardware power states.<ref name="Virtual machine power"/> Joulemeter can also solve the power capping problem for VMs which will reduce power provisioning costs significantly. The largest power consuming subsystems in computer servers are the processor, memory and disk. Servers also have idle energy consumption which sometimes can be large, but it is static and it can be measured. Power models are presented for each of subsystems CPU, memory and disk in reference <ref name="Virtual machine power"/> in detail. This power model is the core technique for Joulemeter. Figure 4 in reference <ref name="Virtual machine power"/> shows the block diagram of Joulemeter where System Resource & Power Tracing module reads the full server CPU, disk and power usage. The VM resource tracking module tracks all the work load using hypervisor counters. The base model training module implements the learning methods described in <ref name="Virtual machine power"/> as well as refinement module. The energy calculation module finally takes the out of base model training module and model refinement module to output the VM energy usage using the energy equations described in reference.<ref name="Virtual machine power"/>

The benefits of this method are safe isolation of co-located workloads, enabling multiple workloads to be consolidated on fewer servers, resulting in improved resource utilization and reduced idle power costs. Joulemeter can also be used to solve the power capping problem for VMs which will saved significant amount of power provisioning costs in data centers.

==Direct Power measurement==
One can use different types of sensors to gather voltage, current, frequency or temperature and then use those data to estimate power consumption.

===Low Power Energy Aware Processing embedded sensor system===

The LEAP (Low Power Energy Aware Processing) has been developed by D. McIntire, K. Ho, B. Yip, A. Singh, W. Wu, and W.J. Kaiser at University of California Los Angeles to make sure the embedded network sensor systems are energy optimized for their applications. The LEAP system as described in reference <ref name="The low power energy">{{cite journal|last=McIntire|first=Dustin|coauthors=Kei Ho, Bernie Yip, Amarjeet Singh, Winston Wu, William J. Kaiser|title=The low power energy aware processing (LEAP)embedded networked sensor system|year=2006|doi=10.1145/1127777.1127846|url=http://dl.acm.org/citation.cfm?doid=1127777.1127846}}</ref> offers a detailed energy dissipation monitoring and sophisticated power control scheduling for all subsystems including the sensor systems. LEAP is a multiprocessor architecture based on hardware and software system partitioning. It is an independent energy monitoring and power control method for each individual subsystem. The goal of LEAP is to control microprocessors to achieve the lowest per task operating energy. Many modern embedded networked sensors are required to do many things like image processing, statistical high performance computing and communication. To make sure all of these applications are working efficiently a real-time energy monitoring and scheduling feature is required and LEAP can offer this feature for those systems.

LEAP (ENS) system was designed to offer high accuracy and low overhead energy measurement capability. LEAP enables energy aware applications through scheduling and energy profiling of high energy efficiency components including multiple wireless network interfaces, storage elements, and sensing capabilities.<ref name="The low power energy"/> The biggest advantage of LEAP system is its Energy Management and Preprocessing (EMAP) capability. The experimental results shows that the optimal choice of sensor systems, processor, wireless interface, and memory technology is not application dependent but it could be hardware allocation issue. EMAP has the capability to partition devices into many power domains with the capability to monitor, enable or disable power to each domain, as well as to respond to trigger events or conditions that restore or remove power in each domain. EMAP collects data periodically and transfers them to the host process and power management schedule is then provided by host processor to EMAP.

Figure 1 in reference <ref name="The low power energy"/> shows the LEAP architecture and EMAP architecture. The LEAP and EMAP are complex platforms which require hardware and software. All of the detailed design approaches are described in reference.<ref name="The low power energy"/>

In conclusion, LEAP differs from previous methods like PowerScope <ref name="PowerScope: a tool">{{cite journal|last=Flinn, and Satyanarayanan|first=J. and M.|title=PowerScope: a tool for profiling the energy usage of mobile applications|date=6 August 2002|doi=10.1109/MCSA.1999.749272|url=http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=749272}}</ref> because it provides both real-time power consumption information and a standard application execution environment on the same platform. As a result, LEAP eliminates the need for synchronization between the device under test and an external power measurement unit. LEAP also provides power information of individual subsystems, such as CPU, GPU and RAM, through direct measurement, thereby enabling accurate assessments of software and hardware effects on the power behavior of individual components.<ref name="Performance Computing with Graphic">{{cite journal|last=Mahsan Rofouei, ThaStathopoulos, Ryffel, Kaiser, and Sarrafzadeh|first=Mahsan, Thanos, William, Majid|title=Energy-Aware High Performance Computing with Graphic Processing Units|year=2008|url=http://static.usenix.org/events/hotpower08/tech/full_papers/rofouei/rofouei.pdf}}</ref>

===Power model validation through thermal measurements===

One of the challenges for HW or SW designers is to validate their simulation data with empirical data. They require some type of utility or tool to measure power consumption and compare with their simulation data. One of these methods to capture real time data to validate power or thermal models is an infrared measurement setup developed by F.J. Mesa-Martinez, J.Nayfach-Battilana and J. Renau at University of California Santa Cruz. Their approach is to capture thermal maps using infrared cameras with high spatial resolution and high frame rate. Then a genetic algorithm finds a power equation for each floorplan block of processor that produces the capture thermal map to give detailed information about power breakdown (leakage and dynamic).<ref name="Power model validation">{{cite journal|last=Mesa-Martinez|first=Francisco Javier|coauthors=Nayfach-Battilana, Joseph; Renau, Jose|title=Power model validation through thermal measurements|journal=ACM SIGARCH Computer Architecture News|date=9 June 2007|volume=35|issue=2|pages=302|doi=10.1145/1273440.1250700|url=http://dl.acm.org/citation.cfm?doid=1273440.1250700}}</ref> They also developed an image processing filter to increase the thermal image accuracy. The biggest challenge for this approach is to obtain a detailed power map from the thermal measurements. There is no direct mapping between measured information and power. A genetic algorithm was developed described in reference <ref name="Power model validation"/> that iterates multiple thermal traces and compares them with the results from thermal simulator to find the best power correlation.

The first step is to measure the temperature using IR camera and within the oil coolant that flows over the top of the chip surface, the detailed setup information is described in reference.<ref name="Power model validation"/> Oil is chosen because of ease in modeling and accuracy. The infrared cameras must be calibrated to compensate for different material thermal emissions, lens configurations, and other factors in reference.<ref name="Power model validation"/> A second filter is also applied to compensate for the optical distortion induced by lens setup. A very accurate thermal model is required in this approach to account for effects of the liquid cooling setup accurately. The model equations are described in reference.<ref name="Power model validation"/>

Designers can use this method to validate their simulation or optimize their design especially because this method provides the breakdown information about leakage and dynamic power consumption. This method is also helpful in chip packaging design, heat sink, and cooling system. This method also shows designers which part of floorplan blocks propagates heat faster or slower.

==Conclusion==

Estimating power consumption is critical for hardware, software developers, and other computing system users like Internet companies to save energy or to optimize their HW/SW to be more energy efficient. It is also critical because one can use the available resources accordingly. Simulators are only good during design but their estimation also needs to be verified. Simulators in general have high errors due to manufacturing of hardware components. Power meters measure power consumption for the whole system but does not give detailed breakdowns about dissipated power so designers can optimize their application or hardware. This paper analyzed different methods that researchers have discovered in recent years to resolve some of the issues above.

==References==
{{Reflist}}

[[Category:Energy consumption]]

Respiratory minute volume

2013-12-01T18:52:18Z

134.190.155.206:

The '''Akhmim wooden tablets''' or '''Cairo wooden tablets''' (''Cairo Cat. 25367'' and ''25368'') are two [[ancient Egypt]]ian wooden writing tablets. They each measure about 18 by 10 inches and are covered with plaster. The tablets are inscribed on both sides. The inscriptions on the first tablet includes a list of servants, which is followed by a mathematical text.<ref name="Peet">T. Eric Peet, The Journal of Egyptian Archaeology, Vol. 9, No. 1/2 (Apr., 1923), pp. 91-95, Egypt Exploration Society</ref> The text is dated to year 38 (it was at first thought to be from year 28) of an otherwise unnamed king. The general dating to the early [[Egyptian Middle Kingdom]] combined with the high regnal year suggests that the tables may date to the reign of [[Senusret I]], ca. 1950 BC.<ref>William K. Simpson, An Additional Fragment from the "Hatnub" Stela, Journal of Near Eastern Studies, Vol. 20, No.1 (Jan 1961), pp. 25-30</ref> The second tablet also lists several servants and further contains mathematical texts.<ref name="Peet"/>

The tablets are currently housed in Cairo's [[Museum of Egyptian Antiquities]]. The text was reported by [[Georges Émile Jules Daressy|Daressy]] in 1901 <ref>Daressy, Georges, Catalogue général des antiquités égyptiennes du Musée du Caire, Volume No. 25001-25385, 1901.</ref> and later analyzed and published in 1906.<ref>Daressy, Georges, "Calculs égyptiens du Moyen Empire", in Recueil de travaux relatifs à la philologie et à l'archéologie égyptiennes et assyriennes XXVIII, 1906, 62–72.</ref>

The first half of the tablet details five multiplications of a ''[[hekat (volume unit)|hekat]]'' unity (64/64) by 1/3, 1/7, 1/10, 1/11 and 1/13. The answers were written in binary [[Eye of Horus]] quotients, and exact [[Egyptian fraction]] remainders, scaled to a 1/320th factor named ''ro.'' The second half of the document proved the correctness of the five division answers by multiplying the two-part eqotient and remainder answer by its respective (3, 7, 10, 11 and 13) dividend that returned the [[ab initio]] hekat unity, 64/64.

In 2002 [[Hana Vymazalová]] obtained a fresh copy of the text from the Cairo Museum, and confirmed that all five two-part answers were correctly checked for accuracy by the scribe that returned a 64/64 hekat unity. Minor typographical errors in Daressy's copy of two problems, the division by 11 and 13 data, were corrected at this time.<ref name="Vymazalova, H pp. 27">Vymazalova, H. "The Wooden Tablets from Cairo: The Use of the Grain Unit HK3T in Ancient Egypt." Archive Orientallai, Charles U., Prague, pp. 27–42, 2002.</ref> The proof that all five divisions had been exact was suspected by Daressy, but was not proven in 1906.

==Mathematical content==
===1/3 case===
The first problem divides 1 ''hekat'' by writing it as 1/2 + 1/4 + 1/8 + 1/16 + 1/32 + 1/64 + (5 ''ro'')(which equals 1) and dividing that expression by 3.
* The scribe first divided the remainder of 5 ''ro'' by 3, and determined that this was equal to (1 + 2/3) ''ro''.
* Next the scribe finds 1/3 of the rest of the equation and determines it is equal to <math>1/4 + 1/16 + 1/64</math>.
* The final step in the problem consists of checking that the answer is correct and the scribe multiplies <math>1/4 + 1/16 + 1/64 + (1 + 2/3) ro</math> by 3 and shows that the answer is (1/2 + 1/4 + 1/8 + 1/16 + 1/32 + 1/64 +) (5 ''ro''), which he knows is equal to 1.

In modern mathematical notation we might say that the scribe showed that 3 times the ''hekat'' fraction (1/4 + 1/16 + 1/64) is equal to 63/64 and that 3 times the remainder part ((1 + 2/3) ''ro'') is equal to 5 ''ro'', which is equal to 1/64 th of a ''hekat'', which sums to the initial hekat unity (64/64).

===The other fractions===
The other problems on the tablets were computed by the technique. The scribe used the fact that 1 ''hekat'' = 320 ''ro'' and divided 64 by 7, 10, 11 and 13. For instance in the 1/11 computation the division of 64 by 11 gave 5 with a remainder 45/11 ''ro''. This was equivalent to (1/16 + 1/64) ''hekat'' + (4 + 1/11) ''ro''. Checking the work required the scribe multiplied the two-part number by 11 and showed the result 63/64) + 1/64 = 64/64, as all five proofs reported .

===Accuracy===
The computations show several minor mistakes. For instance in the 1/7 computations <math> 2 \times 7</math> was said to be 12 and the double of that 24 in all of the copies of the problem. The mistake takes place in exactly the same place in each of the versions of this problem, but the scribe manages to find the correct answer in spite of this error since the 64/64 hekat unity guided his thinking. The fourth copy of the 1/7 division contains an extra minor error in one of the lines.

The fraction 1/11 computation occurs four times and the problems appear right next to one another leaving the impression that the scribe was practicing the computation procedure. The 1/13 computation appears once in its complete form and twice more with only partial computations. There are errors in the computations, but the scribe does find the correct answer. The 1/10 computation is the only fraction computed only once. There are no mistakes in the computations for this problem.<ref name="Vymazalova, H pp. 27"/>

==Hekat problems in other texts==
The ''[[Rhind Mathematical Papyrus]]'' contained over 60 examples of ''hekat'' multiplication and division in RMP 35, 36, 37, 38, 47, 80, 81, 82, 83 and 84. The problems were different since the hekat unity was changed from the 64/64 binary hekat and ro remainder standard as needed to a second 320/320 standard recorded in 320 ro statements. Some examples include:

* Problems 35-38 in the ''Rhind Mathematical Papyrus'' find fractions of the ''hekat.'' Problem 38 scaled one hekat to 320 ro and multiplied by 7/22. The answer 101 9/11 ro was proven by multiplyied by 22/7 facts not mentioned by Claggett and scholars prior to Vymazalova.'<ref name="Clagett">Clagett, Marshall Ancient Egyptian Science, A Source Book. Volume Three: Ancient Egyptian Mathematics (Memoirs of the American Philosophical Society) American Philosophical Society. 1999 ISBN 978-0-87169-232-0</ref>
* Problem 47 scaled 100 ''hekat'' to (6400/64) and multiplied (6400/64) by 1/10, 1/20, 1/30, 1/40, 1/50, 1/60, 1/70, 1/80, 1/90 and 1/100 fractions to binary quotient and 1/1320 (ro) remainder unit fraction series.
* Problem 80 gave 5 Horus eye fractions of the ''hekat'' and equivalent fractions as expressions of another unit called the ''hinu''.<ref name="Clagett"/> that were left unclear prior to Vymazalova. Problem 81 generally converted hekat unity binary quotient and ro remainder statements to equivalent 1/10 hinu units making it clear the meaning of RMP 80 data.

The ''[[Ebers Papyrus]]'' is a famous late Middle Kingdom medical text. Its raw data was written in ''hekat'' one-parts suggested by the AWT, handling divisors greater than 64.<ref>Pommerening, Tanja, "Altagyptische Holmasse Metrologish neu Interpretiert" and relevant pharmaceutical and medical knowledge, an abstract, Phillips-Universtat, Marburg, 8-11-2004, taken from "Die Altagyptschen Hohlmass" in studien zur Altagyptischen Kulture, Beiheft, 10, Hamburg, Buske-Verlag, 2005</ref>

==References==
<references/>

Other:
*Gardener, Milo, "An Ancient Egyptian Problem and its Innovative Arithmetic Solution", Ganita Bharati, 2006, Vol 28, Bulletin of the Indian Society for the History of Mathematics, MD Publications, New Delhi, pp 157–173. http://independent.academia.edu/MiloGardner/Papers/163573/The_Arithmetic_used_to_Solve_an_Ancient_Horus-Eye_Problem
*Gillings, R. Mathematics in the Time of the Pharaohs. Boston, MA: MIT Press, pp. 202–205, 1972. ISBN 0-262-07045-6. (Out of print)

==External links==
*{{MathWorld | urlname=AkhmimWoodenTablet | title=Akhmim Wooden Tablet}} Scaled AWT Remainders
*http://www.whonamedit.com/synd.cfm/443.html

{{DEFAULTSORT:Akhmim Wooden Tablets}}
[[Category:Ancient Egyptian society]]
[[Category:Egyptian fractions]]
[[Category:Ancient Egyptian literature]]
[[Category:Units of volume]]