GB2439104A

GB2439104A - Managing power on a computing device by minimising the number of separately activated timer events such that the device is powering up less often.

Info

Publication number: GB2439104A
Application number: GB0611903A
Authority: GB
Inventors: Lorin Mckay
Original assignee: Symbian Software Ltd
Current assignee: Symbian Software Ltd
Priority date: 2006-06-15
Filing date: 2006-06-15
Publication date: 2007-12-19
Also published as: WO2007144648A1; GB0611903D0

Abstract

Disclosed is a method of managing power resources on a computing device by minimising the number of separately activated timer events, such that the device is powering up less often. This is done by enabling the device to decide which timer events can occur concurrently and adjusting timer events on the device in such a way that those which can safely occur concurrently do occur concurrently. Components on the computing device may make requests for timer events in terms of ranges of acceptable times, in which the timer events are then triggered. The ranges of acceptable times which are passed by the components may be as maximum and minimum durations or minimum and maximum times, with the ranges having an allowable variation which may allow a timer event to be triggered earlier and/or later. The requests may be made for a periodic timer event and the device ensuring that the average period between instances of the timer event are constant. The device may use a default range for timer requests that do not specify a range. The device or any components may conserve power by entering a low power state whilst waiting for a timer event. The device may place the timer events in a first queue based on the earliest trigger time with a second queue of impending events based on latest trigger time.

Description

1 2439104

POWER MANAGEMENT IN A COMPUTING DEVICE

This invention relates to a method of reducing power consumption in a computing device.

The term computing device' includes, without limitation, Desktop and Laptop computers, Personal Digital Assistants (PDA5), Mobile Telephones, Smartphones, Digital Cameras and Digital Music Players. It also includes converged devices incorporating the functionality of one or more of the classes of device already mentioned, together with many other industrial and domestic electronic appliances.

Much of the functionality available on such devices depends on accurate timings; as well as timing constraints which are apparent to the users of such devices (for example, exposure times on camera and speed of playback on music and video) there are also timing requirements that are less obvious to the user but are of critical importance to the functioning of the device, such as the timing specifications included in the protocols used by devices with communications capabilities, such as mobile telephones.

It is common for the provision of these timings to be the responsibility of an operating system (OS). At the heart of any OS is a fundamental core of system software that controls the overall operation of the computer it runs on.

This system software is responsible for the management of the hardware -controlling and integrating the various hardware components in the system. It is also responsible for all the other software on the device, launching, scheduling and coordinating individual executable software components (such as applications, processes and threads) and providing them with various services that they all require. Timer functionality is one of the most important of these.

Operating system timer functionality is typically capable of concurrently utilising and organising a large number of timers and associated timer events requested by various other operating system components and application software. The completion of a timer (often known as a time-out) is an event that triggers a sequence of operations, the exact effect of which depends on the current state of the system and the program logic of the client software that requested the time-out.

Most operating systems have a set of Application Programming Interfaces (APIs) which allow timers to be set and timer events to be generated. The exact mechanism by which applications are notified of timer events varies between operating systems, depending on the way that a particular OS handles event notifications. Calibacks and various types of Inter-Process Communication (IPC) are commonly used for this purpose.

Timers are commonly used to implement various power management techniques on modern computing devices. After a certain period of inactivity, switching off specific components, such as displays and disk drives, can prolong their working lives. Other components, such as the Central Processing Unit (CPU) and certain types of memory, can be placed into low power modes, which may be provided with various levels of power conservation modes, such as sleep or standby. These measures enable the overall power consumption of the computing device to be considerably reduced without affecting its functionality in any significant way.

Such techniques of power management are especially important for the increasing number of computing devices that are mobile and battery-operated.

Effective management of power resources and power consumption on a device is critical for ensuring that power is not wasted, and that the user is provided with a reasonable and respectable amount of use out of one set of batteries or one charge.

However, it should be appreciated that power savings can also be applied to mains powered computing devices, and although of relatively small benefit when considering a computing device in isolation, can provide meaningful benefits to the planetary environment as a whole when considering the millions of devices in operation for significant periods of time every day.

When any electrical or electronic device has been placed in low power mode, it can only revert to a fuller operational status in response to some external event. The arrival of an externally generated signal, such as user input, represent one class of external event that can wake up an electrical device in low power mode. However, it is well-known that there is some considerable latency between the generation of the external event and the device becoming fully operational; for example, any person who has used a remote control to bring a CRT based television out of standby mode will appreciate that it takes time for the tube to warm up and become operational.

Computing devices, in common with other electrical and electronic devices, are subject to the same latency considerations when emerging from a low-power standby state. As well as user input, these devices can make use of programmed timer events to trigger a wake-up. However, in order to take account of latency, the OS controlling the computing device must begin processing some time before a client on the device requires the timer event, in order to ensure that the device will have become fully operational at the time of the required event. For example, it takes some time for the Phase Locked Loops (PLL5) and crystals used in the Central Processing Units (CPUs) and Application Specific Integrated Circuits (ASICs) that are fundamental to wireless communication devices such as mobile telephones to power up, stabilise and become operational. During this time, various parts of the computing device will be using power but completing no desired function.

It is therefore desirable to economise on the number of times that a computing device is brought out of low power mode, as power is wasted on each power-up cycle. Such economy may be achieved by ensuring that each time a device powers up, it is able to do as much as it can.

However, the timer APIs available in all current operating systems do not allow this to be done as effectively as they might. The client software typically provides the OS with either a length of time to elapse or a specific time of day after when it requires an event. All the OS can do to satisfy such a request is to schedule the time-out to occur as soon as possible after the elapsed time or absolute time.

In devices where there are many concurrent timers, there will be many timer events that are triggered closely together. This results in the various components in the computing device being repeatedly put into a low power state and subsequently returned to a fully operational state.

In the worst case, time-outs might be scheduled so closely together that it is not possible in the time available to enter a low power state; in this case the device is kept idle, using more power than is required but not completing any desired function. This would happen whenever an OS looked at the future list of timer events that were due, and determined that it did not make sense, in terms of power conservation, to go back to low power mode.

Ideally, it should be possible for multiple independently set timer events to be concatenated into one single timer event, thereby saving wasted power. Such a concatenation of timer events would mean that some might be triggered early while others might be triggered late. But, the existing timer APIs set a specific point in time at which a future timer event will be triggered, and this does not provide enough information for the OS to make a decision as to whether it is safe or practical to adjust the time at which a particular event will be triggered early.

According to a first aspect of the present invention there is provided a method of managing power resources on a computing device by minimising the number of separate timer events by a. enabling the device to decide which timer events can occur concurrently; and b. adjusting timer events on the device in such a way that those which can occur concurrently do occur concurrently.

According to a second aspect of the present invention there is provided a computing device arranged to operate in accordance with a method of the first aspect.

According to a third aspect of the present invention there is provided an operating system for causing a computing device to operate in accordance with a method of the first aspect.

Embodiments of the present invention will now be described, by way of further example only, with reference to the accompanying drawings, in which: Figure 1 shows an idle algorithm performed when a computing device in accordance with an embodiment of the present invention has completed all pending tasks and is determining if it should transition to a low power mode; and Figure 2 shows a wake up algorithm performed when a computing device according to an embodiment of the present invention transitions from a low power mode in response to a hardware timer/counter or an external event.

The present invention will now be described with reference to a computing device in the form of a mobile telephone. The operating system (OS) of such a device runs a telephony protocol stack together with a networking protocol stack and various other protocols; this is in addition to any user applications.

Therefore, in such a device there are likely to be many (tens of) timers of varying length set to trigger at different times, so devices of this kind are considered to be particularly suitable for implementing the present invention.

However, to describe many of these timers simply in terms of their length and the time at which they are set to be triggered would be incomplete. The protocol specifications which the timers are set to implement are actually rather more flexible and requiring varying degrees of accuracies. For instance, the Universal Mobile Telecommunications System (UMTS) specifies many of the timer values as needing to be accurate only to the degree of 10% or +10%/-0% The perception behind this invention is that if the OS timer functionality can be provided with knowledge of the accuracy requirements of client software, it would be able to schedule the various pending time-outs with enhanced precision so as to minimise the number of times the device or its various hardware components are put into a low power state, thereby reducing the overall power consumption of the device.

While this description is couched in terms of a mobile telephone, the invention can be applied to any timers on any computing device where the required degree of accuracy is known.

There are many methods of implementing the invention in its most basic form, but all of them have the same fundamental property that the OS is provided with a timing range for an event rather than a specific time at which the event should occur.

The following schemes are provided by way of illustration, and are not intended to limit the invention in any way. The programming idioms used are those of Symbian OS, the advanced mobile phone system from Symbian Ltd., but can easily be implemented using idioms from other operating systems such as WindowsTM, Java TM or Linux.

Timer functions in Symbian OS currently are of the form RTimer::After(TDuratjon aPer od)in which the parameter passed was a period of time, orRTimer::At(TTimeof]Jay aTime)in which the parameter passed was a specific time. Those calls can easily be retained in an OS implementing this invention, which would additionally add a set of RTimer: : Between () functions that might take any of the following forms: 1. RTimer: :Between(TDuratjon aMinPeriod, TDuration aMaxPeriod) in which two parameters are passed; a minimum period of time and a maximum period of time. The resulting timer event is therefore allowed to occur at any point between these limits.

2. RTimer::Between(TDuratjon aPeriod, TInt aVariation)in which two parameters are passed; a period of time and a percentage by which that period might be varied either higher or lower. The period passed is therefore a mean value and the resulting timer event is therefore allowed to occur at any point between the period as adjusted below the value passed by the percentage and the period as adjusted above the value passed by the percentage.

3. RTimer: :Between(T]Juratjon aPeriod, TInt aVariation, TBool aDirect ion) in which three parameters are passed; a period of time, a percentage by which that period might be varied, and a boolean where I indicates that the period is a maximum that can only be decreased and 0 indicates that the period is a minimum that can only be increased. This is a variation of version 2 above of RTimer: :Between 4. RTimer::Between(TTimeofDay aTime, TDuration aVariation) in which two parameters are passed; a specific time and a period of time (the variation period) by which it might be varied above or below that time. The resulting timer event is therefore allowed to occur at any point between the specific time minus the variation period and the specific time plus the variation period.

5. RT mer: :Between(TTimeOfDay aTime, TDuration aPeriod, TBool aDirect ion) in which three parameters are passed; a specific time, a period of time by which it might be varied, and a boolean where I indicates that the specific time is a maximum which can only be decreased and where 0 indicates that the specific time is a minimum and can only be increased. This is a variation of version 4 above of RTimer::Between.

The function prototypes listed above are intended to illustrate and not limit the invention; there are many variations which will be apparent to those skilled in the art. One alternative set of variations to RTimer and CPeriodic, which are two of the classes that system and application software use to access the Symbian OS timer functionality, may be as follows, in which additional functions provided to invoke this invention are indicated.

Modified RTimer API: class RTimer: public RHandleBase public: IMPORT C TInt CreateLocalQ; IMPORT C void CancelO; IMPORT C void After(TRequeststatus& aStatus, TTimelntervalMicroseconds32 anlnterval); IMPORT C void AfterTicks(TRequeststatus &aStatus, TInt aTicks); IMPORT C void At(TRequestStatus& aStatus,const TTime& aTime); IMPORT C void AtUTC(TRequestStatus& aStatus, const TTime& aUTCTime); IMPORT C void Lock(TRequeststatus& aStatus, TTimerLockSpec aLock); IMPORT C void Inactivity(TRequeststatus& aStatus, TTimelntervalseconds aSeconds); IMPORT C void HighRes(TRequeststatusg. aStatus, TTimelntervalMicroseconds32 anlnterval); II the following five functions provide timer ranges IMPORT C void At(TRequestStatus& aStatus, const TTime& aTime, TTimelntervalgeconds aEarlier); IMPORT C void AtUTC(TRequestStatus& aStatus, const TTime& aTimeInUTC, TTimelntervalseconds aEarlier); IMPORT C void After(TRequestStatus& aStatus, TTimelntervalMicroseconds32 aEarliest, TTimelntervalMicroseconds32 aLatest); IMPORT C void Inactivity(TRequeststatus& aStatus, TTimelntervalseconds aEarliest, TTimelntervalSeconds aLatest); IMPORT C void HighRes(TRequeststatus& aStatus, TTimelntervalMicroseconds32 aEarliest, TTimelntervalMjcroseconds32 aLatest) protected: IMPORT C CTimer(TInt aPriority); IMPORT C void ConstructLO; IMPORT C void DoCancel; private: RTimer iTimer; Modified CPeriodicl class CPeriodic: public CTimer public: IMPORT C static CPeriodic* New(TInt aPriority); IMPORT C static CPeriodic* NewL(TInt aPriority); IMPORT C.-CPeriodicO; IMPORT C void Start (TTimelntervalMicroSeconds32 aDelay, TTimelntervalMicro5econds32 alnterval, TCallBack aCailBack); // the following function provides timer ranges IMPORT C void Start (TTimelntervalMjcro5econds32 aDelay, TTimelntervalMjcro5econds32 alnterval, TTimelntervalMicrogeconds32 aVariation, TCallBack aCaliBack); protected: IMPORT C CPeriodic (TInt aPriority); IMPORT C void RunL(); private: TTimelntervalMjcroseconds32 ilnterval; TCallBacJc iCaliBack; It should be noted that all variations for implementing the invention on Symbian OS, together with all comparable implementations on other operating systems, share the same characteristic in that they convey to the OS a range of acceptable values for scheduling a timer event rather than a specific time.

It should also be noted that this invention is quite distinct from those operating systems that allow the granularity of timers to be specified, where the variation in the event is an unpredictable consequence of an inaccuracy in the clock being used.

That this is so can be seen by considering the type of algorithm that an OS implementing this invention might choose when scheduling events. It has been stated above that the OS is passed an acceptable range of times for queuing events. When a timer event is requested, the OS checks to see if there are any other timer requests whose range, or value in the case of a request made with RTimer::After() or RTimer::AtO, overlaps with the range passed to it. Where overlaps are detected, the OS schedules all the timer events to trigger at the same time, thereby avoiding the need to waste energy by transitioning to and from low power modes.

An example of idle and wake up algorithms performed within an operating system of this invention are shown, respectively, in Figures 1 and 2. The algorithm of Figure 1 is performed when the computing device has completed all pending tasks and must determine if it should transition to a low power mode. The algorithm in Figure 2 is performed when the computing device transitions from a low power mode in response to the hardware timer/counter or an external event.

The algorithms of figures 1 and 2 are provided as examples for illustrative purposes only; there are many other ways to implement the queuing of the requests and many algorithms for deciding which time-outs group and complete together, which will be apparent to those skilled in the art.

Other range APIs can be introduced to handle repeating periodic timers (heartbeats or tickers). These APIs are arranged to ensure that an average period is maintained between calls. A suitable function would be: RTimer: :Repeating(TDuratjon aPeriod, TInt aVariation TDuration aMaxPeriod, TDuration aMinPeriod) Each repeating event is scheduled by the preceding event; a static variable associated with the class in which the TDuration aPeriod parameter can be stored would enable each instantiation of RTimer::Repeating to look up the time it had actually been triggered, compare it to the mean time that it would have been triggered had there been no adjustment, and set aMaxPeriod and aMinPeriod for the subsequent call accordingly to maintain the average tick.

An OS introducing this invention could, for legacy clients using RTimer::After() or RTimer::At() functions, assume a small variation (5% to 10%). Any components using the legacy calls should be tested thoroughly to ensure that they still functioned.

The principal advantage of this invention over the known methods of operating computing devices is that it enables devices to consume less power.

For mains-powered devices, this use of less energy for many hundreds of thousands of devices assists in reducing consumption of fossil fuels and global warming. Additionally, powering down components of computing devices can in many cases extend their functioning life.

For battery-powered devices, especially mobile ones, there is considerable additional utility value in this invention as it permits them to function for longer on a single set of batteries or on a single charge.

Although the present invention has been described with reference to particular embodiments, it will be appreciated that modifications may be effected whilst remaining within the scope of the present invention as defined by the appended claims.

Claims

Claims: 1. A method of managing power resources on a computing device

by minimising the number of separate timer events by a. enabling the device to decide which timer events can occur concurrently; and b. adjusting timer events on the device in such a way that those which can safely occur concurrently do occur concurrently.

2. A method according to claim I in which components on the computing device make requests for timer events in terms of ranges of acceptable times and in which the timer events are then triggered on the device at any point within the range of acceptable times.

3. A method according to claim 2 in which the ranges of acceptable times are passed as a. maximum and minimum durations; or b. minimum and maximum times.

4. A method according to claim 2 in which the ranges of acceptable times are passed as either durations or times with an allowable variation which may a. allow a timer event to be triggered earlier; or b. allow a timer event to be triggered later; or c. allow a timer event to be triggered either earlier or later.

5. A method according to claim 2 in which a request is made for a periodic timer event and in which the computing device ensures that the average period between instances of the timer event are constant.

6. A method according to any one of the preceding claims in which the computing device is enabled to assume a default range for timer requests that do not specify a range.

7. A method according to any one of the preceding claims in which either the computing device or any components of the computing device are enabled to conserve power by entering one or more low power states whilst awaiting a timer event.

8. A method according to any one of the preceding claims in which the computing device maintains a collection of multiple impending timer events and in which the timer events have an associated range of potential trigger times.

9. A method according to any one of the preceding claims in which the computing device maintains a first queue of impending timer events based on the earliest trigger time together with a second queue of impending timer events based on the latest trigger time, and in which all the timer events are stored on both queues.

10.A method according to any one of the preceding claims in which the computing device maintains a queue of impending timer events and in which the timer event at the head of the queue is the one with the lowest latest trigger time and in which the remaining timer events in the queue are stored in order of their earliest trigger times.

11.A computing device arranged to operate in accordance with a method as claimed in any one of claims I to 10.

12.An operating system for causing a computing device to operate in accordance with a method as claimed in any one of claims I to 10