Sustainability and it’s relevance to long term success in the mobile computing market

Circa October 2013:

The current generation of consumer electronics put an ever increasing amounts of integrated computer and radio network technologies into incredibly small and sophisticated packages. Mobile devices such as iPhones, Androids and tablet computers rely heavily upon modern battery technology built into small form factors to deliver the user experience to consumers. Despite the steady improvements in mobile computing power over the last half decade, there remains a substantial gap between the rate of evolution in technology in comparison to the capacities and efficiency of mobile battery components.

This void seems destined to grow wider in the future, short of a significant change in battery materials technology or greater rate of improvement in component efficiency. Design elements such as smaller and lighter form factors, high definition displays, dedicated graphics cores and an always on connectivity result in a constant load for devices that are expected to perform on par with entertainment desktop computers and video game consoles.

The intention of this article is to identify and discuss in brief the known factors contributing to smartphone / tablet battery drain in daily use. It will present some discussion regarding the need for the wireless / telecommunications industry to embrace more efficient, emerging network protocols as time progresses; it will also address the importance of improved sustainability of the environment with respect to materials technology used in manufacturing.

Today’s smartphones act as cameras, media centres, libraries, video game players, hubs for social media sites and are capable of performing a myriad of office tasks once reserved for desktop computing. For many users, mobile devices constitute a main mode of computing. In August 2013, Statista[1] reported than an increase in the volume of web traffic originating from mobile devices had a combined total of 17.4% of all worldwide web traffic, in comparison to 11.1% the year before. The mobile computing industry continues to see significant gains. This year, Apple sold 9 million units on opening weekend for the iPhone 5S and 5C in 2013, which was reported to be a ‘record for the number of phones sold in an opening weekend’. iPhone constitutes roughly two thirds[2] of Apple revenue. Android ships on a higher number of devices due to the diversity of manufacturers shipping the Android OS. This further serves to indicate a greater requirement for improved mobile energy efficiency as the portability of mobile computing is increasingly favoured over the restrictions of desktops. Several design elements are main contributors to battery drain on mobile devices. These are size and definition of displays, CPU performance and power limiting capability, connectivity and poorly written software.

The website www.displaymate.com states that “The power consumed byLCD displays is independent of the brightness and color distribution of the images – it only depends on the Brightness setting of the backlight that illuminates the LCD from behind…”

Manufacturers such as Apple spend considerable resources making their products more efficient and the iPhone is no exception. The iPhone 4 display consumes .42 watts at 100% brightness at peak white with a luminescence 2 of 541 cd/m. This is a decrease in consumption when compared to the previous model, the iPhone 3GS, which consumes 0.81 watts at 100% peak white brightness with a marginally lower luminescence of 428 cd/m2. This occurred despite an increase in pixel density and colour improvements.

Regardless of this particular example, it is simply wrong to assume that display efficiency will increase over time as a rule with LCD technology.

The market shift toward larger displays has a twofold effect, one upon the battery in the form consumption from backlight illumination method, and secondly upon the computing power required to drive the increase in resolution. This can be shown when noting the increase in consumption by the iPhone 5 display, which moved from a 3.5 inch screen to a 4 inch screen but maintained the same pixel density as the iPhone 4. It was tested by Display Mate to have a consumption of .71 watts at 100% peak white with luminescence of 551 cd/m2.

In these particular examples, a larger display consumes more power on a standardised test with similar light output, despite no change in overall pixel density. [3],[4], [5].

Since the introduction of Apple’s iPhone, screen size in the mobile industry has evolved toward a 1:1 ratio to device size. While manufacturers incorporate auto brightness controls to vary the light output to prevent waste of power, it’s apparent that backlit panels are significant contributors to battery drain. Larger devices tend to incorporate batteries with higher capacities to accommodate the increase in panel dimensions, but normally the internals are otherwise very similar to phones of similar specification. Display bezels are evidence of the need to make devices more resilient to impact and twisting forces.

Flexible screen technology promises to deliver edge to edge unbreakable displays with lower power demand, but manufacturers such as Samsung, LG, Sharp and Sony are yet to deliver beyond simple form factor changes and prototypes. [6].

As recently as a decade ago, much of the work on energy efficiency in CPU’s stated that the operating speed in cycles per second, and the number of transistors in a CPU had a simple linear relationship to power consumption.

Load was seen to increase with operating frequency, with factors such as operating voltage and computational load having never really been considered beyond the realm of ‘ideal’ conditions. Martin and Siewiorek’s, [7] work on battery capacity and memory bandwidth indicated that there is much more to it than that. It is now understood that measuring average power within ideal situations is barely adequate in determining how much work a device can complete given a particular sized or type of battery. Their work [7] shows that factors such as individual discharge rates, CPU speed, CPU operating voltage as well as the ratio of power consumed by other hardware components can greatly impact the amount of work a mobile computer can do between charges.

Their work suggests that when system performance and battery capacity are not ideal, they must be accounted for with a speed setting policy and dynamic architecture. Application feedback, cache registers and integrated feedback loops are paramount to setting the appropriate hardware and software conditions. The operating system needs to have an observational role in resource management and puts strong focus need for closeness to parity between cpu speed and ram / pipe speed in order to prevent wasted cycles during operations.

Today’s multicore mobile devices with independent graphics greatly reduce consumption due to their operating speeds and systems management processes.

Solid state development continues to evolve in line with Moore’s law [8] which is the observation that, over the history of computing hardware, the number of transistors on integrated circuits doubles approximately every two years.

A simple comparison of the latest and earliest cpu’s should suffice: In 2013, Apple introduced the A7, [9] a 64-bit processor with over 1 billion transistors, on a 28nm process capable of operating speeds up to 1.3Ghz.

Compare that to the first truly integrated CPU made, the intel 4004, [10]. It was a 4-bit processor capable of a maximum speed of 740khz, a little over 46,000 instructions per second. It was manufactured on a 10µm process with 2300 transistors on board [10].

Today, Moore’s law is as much a statement of the progress the industry made in the sixties, as it is a guiding line for silicone development. It very much sets a clear target for industry.

Moore’s Law represented visually. [9] A logarithmic plot of CPU transistor counts against dates of introduction.

One might wonder how there can be both a rapid increase in the number of transistors in a state of the art IC as well as improvements in usage times when considering the ongoing market push towards reduced form factors and weight.

This can be attributed partly to changes in battery density and type, as well as system design techniques to limit consumption. Reduced manufacturing process size leads to improvements in power consumption and loss improvement at the substrate. This is turn leads to reductions in peak active power and improved responsiveness when switching.

Modern devices are able to adjust clock speed according to load / configuration requirements. With the correct battery and memory configuration, we can further reduce the amount of time a CPU operates at peak power, the payoff being an increase in operating time for the device despite performance, graphical or feature improvements.

Chapter 3: Battery behavior and modeling 35

Pactive A: Reduce active power | C: Reduce active duty cycle | Power |time across active tidle | tcycle (f) | Pidle | B: Reduce idle power

Figure 3.10 Time | Dynamic power profile example. Modifications A, B, and C reduce the average power. reduced (C). Table 3.2 shows the results from Doyle’s model for the waveform

The waveform above shows a dynamic power profile of the computing 3.10. The waveform was simulated for three different values of initial average power, and load on a Lithium Ion battery. It indicates that a reduction in active power the desired reduction in average power for each case was 20%. As expected, reducing during high peak periods leads to greater energy savings than when reducing the active power (A) results in the greatest increase in battery life when the peak power is amount of power consumed at idle. Reducing the duty cycle always does better than reduction of idle power, but only for the lowest value of peak power. large. Reducing idle power (B) always results in the least increase in battery life. Reducing

It is a concept referred to by some as ‘race to sleep’. Martin [7], describes the the duty cycle (C) always does better than reducing the idle power and does as well as phenomenon by stating that “the major energy savings (from an increase in reducing peak power only for the lowest value of peak power). This can be explained for clock speed – power consumption benefit comes from from reducing the time to complete a computation, not from using the similar operations across the compute load in averages across the 10 second periods in Figure 3.9. Having a larger capacity to complete the load via transistor account accounts for the race to sleep phenomenon; in that it achieves more work quicker, settles to idle sooner, and achieves a longer duty cycle than compared to using lower power instructions. The peak power for their test cases typically than the loads with 1000 second periods: Reducing the duty cycle means that there is increases in peak demand, but the cycle count for the programs is reduced by a much largeramount, so that the overall energy consumption is reduced.”

As a result there is less time for the concentration gradients to become pronounced, and consequently the concentration overpotential. But when the peak power is larger, reducing the duty cycle is imperative, and thus power management cues from within the system need to be adhered to as formed phi, internal feedback loops to govern the nature of operations and ensure that well inteded processes do not run rogue.

In mobile and wireless platforms, bad throughput and intermittent IP connectivity can also contribute greatly to the impact of mobile power consumption. In the current state of the art, reducing network interfaces to idle does not increase the battery life by as much as reducing the active power. This is due to to lost cycles due to network control flow problems borne of lossy protocols and sustained peak demand as opposed to situations and scenarios where network interfaces are expected to fall to idle. This results in wasted energy in mobile devices.

In extreme cases it can also lead to erroneous data charges. [11] Such has been observed in multiple academic studies despite the insistence from mobile carriers worldwide that ‘everything is fine, refer to device manufacturers” in the absence of closed feedback loops on the amout of data a device has used on the client end, commpared to errant charges when things go wrong relating to congestion or lack of control flow.

FIGURE: The column labeled “% difference from expected” refers to difference between the simulated network loads and real world scenarios where data control flow is interrupted at the physical layer but the service provider / MVNO continues to count the packets at the toll application.

In lay terms, during instances where a mobile application queries or streams data and suddenly is disconnected, there is a gap between what the end device reports and what the network reports, and tytpically, the end user pays the penalty without informed reporting or lack of a feedback loop between the device and network for cellular metering.

So when an end user experiences a drop in connectivity due to congestion, lost packets, interference or otherwise there is a direct impact upon the device battery life life and the factor by which the power was reduced.

This is directly attributed to network congestion or or drop in signal gain. Because currently there is little to no difference between the behaviour of the currently employed transport protocols whether transfer occurs across wired networks or radio networks, when a client experiences periods of loss or poor connectivity, work cannot continue on a given request until a connection is re-established or the application / client restarts.

When cryptography across SSL, network interface traffic loops and radio signal gain combine, the impact on the device network idle is measurable, impacts operating voltage and thus lowers the total amount of runtime, both in continuous bursts and as a total aggregate of device uptime.

With current protocols, the risk of a restarted connection over wired networks is acceptable and negligible due to the fact that the likelihood of packet loss is inherently small. Wired networks are robust. They generally serve devices that are not bound by the limited battery capacities of smartphones and tablets.

Wireless networks on the other hand are lossy in nature. Between physical obstructions, weather, domestic appliances, neighbouring networks occupying similar bandwidths or channels and power line noise, the potential for loss on wireless is extremely high.

Thus, in situations where a device is thrashing a respective network connection to complete a task, it is not only wasting cycles in resending requests for data, but it will typically increase cellular or wifi radio power in order to recover the failed network connection. [12], [14]] If you consider the concept of Martin’s ‘race to sleep’ phenomenon as it applies to local computations, in the context of wireless radio; unresolved packet queries and poor connectivity have the potential to result in as much power consumption as rouge software can upon graphics or central processing.

As such, emerging technology needs to be embraced by the networks industry and by device manufacturers to refine wireless protocol for devices employed in dynamic coverage regions.

Work by Peng, Mobicon [12] specifically refers to the impact of lost data packets upon cellular data performance and potential to impact billing in extreme cases.

This work is infomative in that it is also indicative of how the use of a protocols developed for wired networks may not be ideal for the wireless industry. By investigating the impact of loss of throughput with respect to billing. Peng highlights an important requirement for an adaptive change in protocol or the introduction of end device feedback loop.

Multipath tcp [12], [13], is one potential solution to the wireless packetloss problem. It is a backwards compatible TCP extension that enables usingmultiple network paths between two end systems for a single TCP connection, enabling an increase in performance and reliability. In mobile computing it permits efficient switching between cellular and wifi networks without disrupting the work flow of an application. Early work by Plunkte, Eggert and Kiukkonen evaluates energy models for mobile devices handling queries between regional performance changes.

Early evidence indicates that multipath tcp may serve to address reliability issues in network coverage, provide improved responsiveness in online queries and provide improved throughput and energy efficiency in wirelessly dynamic environments. Other work [14] suggests that even for applications such as VOIP and Skype, MPTCP has potential to minimise disruption to services while in transit between coverage areas.

Perhaps implementation over 4G will yield better power results in real world settings over current experiments with 3G; the question with this early experimentation remains about what can be done to maintain power efficiency during switching periods. Tested 3G hardware had longer than expected times to return to idle.

It is worthy to note that current observations are determined from near perfect or ‘ideal’ proxy setups. Implementation of multi path tcp is a rarity in servers on the internet, though given the interest in the protocol this will change.

There is much work to be done to determine the most efficient form of implementation and the adoption of an agreed standard. Ars Technica reported in Septermber 2013 that the latest class of Apple’s mobile operating system, iOS 7 uses the first commercially recognised form of multi path tcp at the device; when performing queries with it’s virtual assistant Siri, iOS 7 establishes a cellular connection in the background to reduce Siri response times in the event of wifi failure and vice versa. [13].

Google use a similar protocol concept between servers to facilitate fast query processing but Apple’s implementation appears different in that it aids performance in the event of a failover at the level of end device connectivity, rather than halving the workload between two or more remote servers in response to a query.

Rogue applications are also a source of wasted cpu cycles. They can directly effect usage times by preventing the CPU and cellular radios from falling into idle mode. This can occur within mobile operating systems despite applications having specific rules of governance according to the type of services they provide.

Of note is the Facebook integration for iOS. [15] It has been reported online that Apple’s own developer tool for observing application performance indicates that the Facebook application would start at intervals of approximately 20-30 seconds, for a period of 10-15 seconds per session.

An insight such as this prompted personal investigation due to my own perceived battery problems since iOS 6. Assessing active connections on my own devices by way of a third party app System Status [18] determined that iOS was connecting to Facebook over an encrypted connection during similar intermittent periods. Removing the Facebook app from active memory did not impact it’s behaviour. Independent of login credentials being in entered settings and regardless of whether or not the application was installed on the device in question, the device would attempt to login with an encrypted connection to www.facebook.com. It is worth noting that Facebook is not installed on freshly manufactured iOS devices, nor is it installed after a software restore. It is an optional install. After reporting my individual findings to a Senior Advisor at Apple Care, with subsequent escalation to their engineering support network – I was informed that the observed behaviour formed part of Facebook’s integration with iOS; more specifically to do with ensuring a pre established connection for integrated sharing options. They reported that under local analysis the impact for the session and network layer functions was negligible but with my own observations across battery life in the 4S I used as a daily driver, I held doubts. They were appreciate of the feedback.

FIGURE: A screenshot taken from the OSX app Instruments, an Apple developer tool. Here it shows increased uptime of Facebook app regardless of it’s application state. [15]

I comntinued to question the suitability of iOS’s behaviour in this instance. Repetitive encrypted connection attempts to Facebook continued to occur over any available wireless connection, even when the application was not active in memory. Uninstalling the app didn’t change this behaviour. I suggested that this aspect of OS integration may need to be refined in order to resolve reported battery issues that have plauged iOS users since the introduction of iOS 6 [19].

The annual release of iOS in 2012 brought Facebook integration into the operating system. Battery life issues have been common across the board with iPhone users since, some in the forum community attribute battery life issues directly to the prolific use of social media applications such as Facebook. With an understanding of the concepts that have been demonstrated earlier, I make the presumption that the iPhone cellular radio may not be afforded the opportunity to fall back into an idle or low power mode over 3G due to the frequency of occurrence of the aforementioned ‘loop’.

Worthy of note is the fact that with broadcom the encryption protocols over 3G consumes more power than encryption protocol performed over wi-fi. Of equal importance is the fact the encryption algorithm employed to create the session with facebook.com also carries a power cost at the CPU.

On this basis I suggest that repetitive cycling may contribute to battery problems in this particular instance. [16]

While rapid enhancements continue to put more power in our pockets, it is apparent that there is still much more work to be done in refinement of data transmission protocol and component power consumption. Being on the cusp of high efficiency, flexible display technology means that there may not be much room to move regarding display efficiency in the near future without generational gains in efficiency.

Likewise, we are expected to reach the end of the period where we can meet the demands of Moore’s law and it’s effect on industry. [9] As manufacturing processes get smaller and smaller, we may soon reach a real world limit regarding efficiency of solid state power consumption.

Therefore in the short to medium term, emerging network technologies may hold the greatest potential to increase power efficiency and throughput in mobile.

The fact that emergent protocols such as multi path and coded tcp [17] may be successfully implemented on existing infrastructure puts the onus squarely on industry to ensure adequate research is undertaken and the most efficient standards be implemented, financial incentives aside.

Present day operating systems and device drivers can be refined to change component behaviour in light of these new protocols and improvements in performance can be obtained from current generation of devices.

It is becoming increasingly evident that current methods of transport control fail the client / application model of delivery during periods of packet loss over wireless. Newer protocols have shown potential to result in rapid improvement of reliability while preventing the need for worldwide hardware restructure. Herein lies much potential for sustainability of the environment.

The benefits could ultimately reduce the consumption of vital raw elements used in manufacturing solid state architecture as well as make gains in the reduction of electrical running costs.

The replacement of battery technology in older hardware as it evolves over time is an initiative that needs to be undertaken from the level of the manufacturer right through to the community. Right now we simply throw too much away.

What is to prevent us from putting evolved batteries into older hardware as they come about, if simple changes in protocol can achieve performance and power efficiency increases that most users desire?

Time will tell. Truth is that many of the elements used for IC / component construction are non-renewable, and perhaps limited in light of the increasing rate of production as worldwide demand increases. As a society, we already take this technology for granted.

Scott Cathery.

Cathery | I am an independent Actor, Writer, Voiceover and have aspirations in systems architecture. My opinions are my own, and are not endorsed by any brands that I mention in my written work. Thank you for stopping by my corner of the internet. More to come.

LIMITED REFERENCES (partial share due to archive data loss :-/ )

1) http://mashable.com/2013/08/20/mobile-web-traffic/

2) http://www.businessinsider.com.au/iphone-profit-2012-8

3) http://www.apple.com/au/batteries/iphone.html

http://www.displaymate.com/iPhone_4_ShootOut.htm

4)http://www.displaymate.com/iPhone_3GS_ShootOut.htm

5)http://www.displaymate.com/Smartphone_ShootOut_2.htm

6)http://news.cnet.com/8301-1035_3-57607171-94/what-you-should-know-

about-flexible-displays-faq/

7) The Impact of Battery Capacity and Memory Bandwidth on CPU Speed-

Setting: A Case Study

Thomas L. Martin, Daniel P. Siewiorek

http://www.cs.cmu.edu/~tlm/papers/islped99_8_2.pdf

http://www.cs.cmu.edu/~tlm/diss_final_3.pdf

in his thesis “Balancing batteries, Power and Performance: System Issues in

CPU Speed-setting for Mobile Computing”.

8) Moore’s Law definition; http://en.wikipedia.org/wiki/Moore’s_law

9) http://en.wikipedia.org/wiki/Apple_A7

iPad air revision, A7 processor review; http://www.anandtech.com/show/7460/

apple-ipad-air-review/2

10) Intel 4004; http://en.wikipedia.org/wiki/Intel_4004

11) “Can we pay for what we get in 3G data access?” Peng, Tu, Li, Lu, UCLA

http://metro.cs.ucla.edu/papers/mobicom12-peng-accounting.pdf

12) “Saving mobile device energy with Multipath TCP”, Plunkte, Eggert and

Kiukkonen; http://eggert.org/papers/2011-mobiarch-mptcp-saving-energy.pdf

http://arstechnica.com/apple/2013/09/multipath-tcp-lets-siri-seamlessly-switch-

between-wi-fi-and-3glte/

13) Free MPTCP implementation and various demonstrations. http://

mptcp.info.ucl.ac.be

14) http://en.wikipedia.org/wiki/Multipath_TCP

Exploring Mobile/WiFi Handover with Multipath TCP Passch. Detail, Duchene,

Raiciu, Bonaventure; 13) http://inl.info.ucl.ac.be/system/files/cell06-paasch.pdf

15) http://www.cultofmac.com/229781/battery-draining-too-fast-lately-

facebook-apps-may-be-at-fault-says-developer/

16) p986, TLS and energy consumption on a Mobile Device: http://users.tkk.fi/

~siekkine/pub/siekkinen11tls.pdf

17) Modeling Network Coded TCP throughput: A simple model and it’s

validation. Kim, Medard, Barros. http://www.mit.edu/~medard/papers2011/

Modeling%20Network%20Coded%20TCP.pdf

18) System Status at iTunes.com; https://itunes.apple.com/us/app/system-status-

activity-monitor/id401457165

19) Facebook integration into iOS 6; http://howto.cnet.com/

8301-11310_39-57507505-285/understanding-facebook-integration-on-ios-6/