|
5000+ Posts? I Should OWN This Site!
Join Date: Jun 2007
Posts: 5,067
|
|
REVIEW & TIPS: extending the battery life on the N95; acbTaskMan vs. Energy Profiler
It was almost two years ago that I�ve published an article in the paper version of Smartphone & Pocket PC Magazine on increasing the battery life on Windows Mobile devices. (Note that, should you be interested in the whole series of similar tips and later (again, Windows Mobile-only) articles, this article is only one of the several. See for example THIS blog category for some more.) Now that I�ve, thanks to "Beck" from the sprites & bites blog, become a proud owner of a N95, I thought I would write an article on how you can do the same on the Nokia. (A shameless plug: I heartily recommend the sprites & bites blog if you're interested in desktop console gaming (currently, it officially discusses the MS Xbox 360, the Nintendo Wii and the PS3))
I not only shed lights on the secrets of extending the battery life of the N95, but also scrutinize how the just-released V20 firmware version behaves and review the brand new Nokia Energy Profiler (runnable on all S60v3 FP1 models) too. Finally, while doing the latter, I�ll also compare Energy Profiler to acbTaskMan, the, currently, best Windows Mobile profiling tool to do the same. By this, I help both Windows Mobile and Symbian users and developers, most importantly, those of acbTaskMan and Energy Profiler, respectively. All this in order to make their products even better � after all, both these apps have unmatched features and goodies not available in the other. Let me point out, for example, that in my previous combined WinMo & Symbian review of Palringo was also much more useful for Windows Mobile users than a single-operating system review because, as was noticed, the Symbian version of the same program supported a rudimentary logging (history), as opposed to the Windows Mobile version. Emphasizing this and, consequently, pushing the developer to implement the same on Windows Mobile is very important. These two-operating system reviews are, therefore, very useful in this respect. Tw� many birds with one stone, yeah 
1.1 Target audience
As with some of my later articles (see for example my Palringo review as another example), I publish exactly the same article for both Windows Mobile and Symbian (more closely, Nokia N95) users. The article can be appealing for both types of audience for the following reasons:- while the case studies (and the battery life tests) have been run on the Nokia N95-1 (with the latest, v20 firmware version), the results can be easily generalized for Windows Mobile. An example of this is the 3G vs. pre-3G power consumption I�ve dedicated several articles to (see for example THIS and THIS). Now, Windows Mobile users can also see it�s true what I�ve stated: it�s always preferable to shut down unused, stalling data connections whenever possible (particularly if they�re 3G) and it�s preferable to be connected to a pre-3G network than to a 3G one if you don�t (currently) need the special features (UMTS / HSPA data, video phoning etc.) of the latter. The numeric results (which, again, are almost exactly the same on Windows Mobile devices) clearly show I was right. This is one of the reasons Windows Mobile users should read this article / check out the results.
- still as far as Windows Mobile users are concerned, users of acbTaskMan will want to pay special attention to the chapters explaining the differences between Nokia�s solution to that of acbTaskMan. Nokia�s app has several advantages over acbTaskMan which, hopefully, will also be introduced in the latter. After all, acbTaskMan is the de facto system meter tool used by most Windows Mobile fans, hackers, programmers and reviewers. Finally, I also provide some new information on acbTaskMan itself; for example, I thoroughly elaborate on the excellent logging capabilities of the latter versions. I still haven�t done this because when I reviewed the program, it still had no logging support.
- if you�re a Nokia N95 user, you will find answers to a lot of questions. And, hopefully, you won�t be angry with me because I also refer to Windows Mobile. It�s far easier for me to maintain only one copy of my article than two entirely different versions, one meant for Symbian users (not mentioning WinMo at all) and one for Windows Mobile users (eliminating strictly N95-related and, to Windows Mobile, not applicable contents). Even the size of this article is pretty much prohibitive when it comes to making two different derivative subversions of it, let alone the additional work needed to synchronize the updates upon subsequent enhancements (which I frequently do to my previously published articles).
1.1.1 Why this can be important?
Benchmarking applications or the operating system / the hardware, as a tech writer, leading blogger and Best Software Awards 2007 Manager for Smartphone & Pocket PC Magazine, has always been very important for me. If you take a look at my past (and future) articles, you see I�ve always paid special attention to battery life. I�ve always recommended apps that consume the least power. An example of these articles is Everything you will ever need to know about the power consumption of Pocket PC audio players. It lists the power consumption of each and every Windows Mobile multimedia player. This isn�t without reason: selecting the right setting, the right app can result in really extended battery life.
As an end user, you may also want to strive for finding the apps and settings resulting in the best possible battery life. Therefore, you�ll also welcome an app and tips that does exactly this.
1.1.2 The (Symbian) history of system metrics apps
On Symbian S60v3rd, so far, there haven�t been comparable utilities � that is, an app that does show the current power usage of your handset. There was only one utility, opda.net.cn�s CPU Monitor 1.10 for Series60 3rd, which I�ve found absolutely useless when assessing battery usage. The sole reason for this is that, it seems, the CPU usage figures it provides have (almost) nothing to do with the real battery drain. For example, when you play back MP3�s using the wired headset (with moderate sound volume), it displays 3% CPU usage � and it does exactly the same when using A2DP. However, if you do use A2DP, the battery life will be severely degraded, compared to the case of using the wired factory headphones � or, even the case of the built-in, great stereo speakers of the N95 (unless you listen to music at the greatest possible volume on the latter).
This is diametrically opposed to the case of Windows Mobile, where you can easily estimate the battery life degradation caused by, for example, enabling A2DP. There, the CPU usage figure acbTaskMan, used in the CPU usage mode, presents can reliably be used to estimate battery life. Note that you can also make acbTaskMan display the current battery drain (if it�s compatible with the given handset in this mode � it isn�t with several TI OMAP-based models like the Wizard); then, it becomes pretty similar to the (only) mode Energy Profiler offers.
1.2 Nokia�s brand new Energy Profiler to the rescue!
Now that we�ve seen CPU Monitor 1.10 is absolutely useless for estimating the battery life differences between Symbian apps (as opposed to acbTaskMan, running (solely) in CPU usage tracking mode, on Windows Mobile), you will definitely welcome Nokia�s new Energy Profiler application. It helps not only app developers, but also end users wanting to find out how the different options, settings (for example, the different Wi-Fi transmit levels) affect battery life.
It�s available for download HERE. I really recommend playing with the hotkeys, controls a bit (even in a full random approach) and re-returning to the built-in help (in addition to the online one) so that you find out all these features. There are a lot of them and you�ll want to learn them all. I also recommend going through my case studies, which clearly show how even a non-developer can make use of it to reduce battery drain � or, for that matter, NOT to believe urban legends like �disabling Bluetooth dramatically increases battery life�.
It has, compared to acbTaskMan on WM, a slightly steeper learning curve. (Assuming you only run the latter in current displaying mode and don�t make use of the CPU usage chart module at all.) This is simply because it has far more, great features and a lot of hotkeys to master (as opposed to the strictly menu & context menu-based usage & the complete lack of features like running average and breakpoints of acbTaskMan). Again, you�ll want to master them all in order to be able to measure the battery life estimation as easily and reliably as possible.
Note that it only runs on S60v3 FP1 (and later, future) models. This means it will NOT run on �plain�, older S60v3 models. Bad news for owners of older models.
2. Case studies and recommendations for N95 owners
Now, let�s do some serious work: let�s examine how much power the N95 takes � all this with Energy Profiler, packed with screenshots and a LOT of myth busting and useful advice!
Note that you can zoom in/out both the time (X) and the Watts (Ampers / Volts / temperture) (Y) axis in both applications. In acbTaskMan, you need to do this via Display / Timescale (where you can select between 2, 5, 10, 15, 30 minutes, 1, 3, 6, 12 and 24 hours. In Nokia�s app, by using the # and * phone buttons, you can do exactly the same. I�ve extensively used this when presenting the screenshots below; this way, it was, for example, possible to squeeze even half-hour-long tests into one screenshot.
Pay special attention to the running averages in the with white vertical bars separated regions � in most cases, they give you a pretty much perfect average of the measured power consumption.
2.1 Backlight levels
First, let�s take a look at the power usage of the different backlight levels. In the following screenshot, the lowest and the highest settings are depicted. The battery consumption of the lowest backlight level starts right at the beginning (the running average showing the 0.27W of the case of enabled backlight); the second, with the highest backlight, after the second vertical bar (restart). There, the running average doesn�t show the power consumption of the backlight (but an average between the next section), which was around 0.61W. The backlight timeout was set to 15 seconds in order to make the backlight power consumption metering as reliable as possible (as opposed to, say, an 5 second timeout).
As can clearly be seen, the highest setting increases the power usage by about 0.48 Watts (0.61-0.13 W), while the lowest with about 0.14W (0.27-0.13 W). This also means that, especially with the lowest setting, you won�t have a high battery drain when always enabled � that is, don�t set the display timeout to, say, 5s, and, then, just try to make out what�s on the screen using an external light.
(BTW, these results are pretty similar to what I�ve measured on Windows Mobile devices � see for example THIS. On older, Intel Xscale 27x-based non-phone devices with much bigger screen (requiring proportionally more power to be backlight), the highest backlight level resulted in a much higher power consumption. The lowest backlight level, on the other hand, doesn�t generally have dire consequences and high battery drain. That is, you can always let the backlight on your WinMo devices too and don�t wear out your eyes staring on the screen with no backlight at all. This is particularly useful on the, currently, most widely used 2.8� touchscreen-based HTC(-manufactured) models. The sole reason for this is the legendarily bad outdoor visibility of all these screens.)
2.2 Wi-Fi power setting levels
Second, let�s take a look at the Wi-Fi power level setting. Many recommend decreasing the Wi-Fi transmit power level from the default 100 mW to the lowest 4 mW to save some battery. (This can be done in Tools / Settings / Connections / Wireless LAN / Options / Advanced Settings (answer Yes) / TX Power Level as can be seen in THIS screenshot.) Let�s see whether this indeed results in any battery saving (or not).
In this test, first, before the white (restart) bar at ~4:35, I quickly downloaded a page with Nokia Web and, then, just let it sit there; all this in 100 mW mode. As you can see, the Wi-Fi transmission caused a constant ~0.65W (see the ~0.8W regions; I�ve subtracted the base power usage of the phone with the lowest brightness level; that is, about 0.14W); this region is, of course, packed with some short peaks.
The 4 mW transmission power case starts at the white (restart) bar at ~4:35. As can be seen, the peaks and the constant ~0.8W power usage at the beginning quickly decreases to ~0.27W (that is, the usual power usage of the phone without any task running, with minimal backlight), which, then, decreases to about ~0.14�~0.15W when the 15-sec backlight setting times out (and the backlight switches off). This is very rarely interrupted with a quick power peak, which costs exactly the same battery in both the 100 and 4 mW case.
This all means there doesn�t seem to be ANY difference between the two settings.
2.2.1 Searching for Wi-Fi networks
Let me also quickly elaborate on the CPU usage of staying on the Standby screen and making the N95 continuously search for Wi-Fi networks:
The above screenshot shows two entirely distinct phases. The first is taken after stopping to browse in Nokia Web (but still staying connected by not terminating the browser), which was over Wi-Fi. The lack of any excessive power consumption clearly shows that no scanning is taking place when the Standby screen is invisible. (Of course, you can also override this default behavior if you deem it useful; see Menu / Tools / Settings / Connection / Wireless LAN / Show WLAN Availability to change this.)
The second was quickly returning to the Standby screen and rescanning for networks. The three distinctive peaks in the second half of the screenshot show three quick, consecutive scans for these networks.
2.3 Multimedia playback, A2DP and the power Energy Profiler itself takes
2.3.1 MP3
Now, let�s take a look at the power consumption of the following activities:- MP3 and WMA (see next subsection) playback (using the wired factory headphones at 70%)
- The same via A2DP
- How much power Energy Profiler itself consumes � that is, is it worth sending it in the background or let the screensaver �kick in� as quickly as possible
The following screenshot depicts all these cases and is, therefore, VERY informative:
After the first bar (note that this shot is made with a zoomed-out timescale; this is why the �0� mark doesn�t start right at the left), you can see the quick drop in battery usage because of the 5-sec timeout of the lowest backlight level. After 55 additional seconds (I�ve set the screensaver to kick in after a minute), there�s another change: the power consumption further decreases as Energy Profiler no longer draws on the screen / scrolls it. Drawing on the screen, no matter how well a particular application is written / optimized, will always consume SOME power. As can be clearly seen in the screenshot, the difference is about 10-20 mWatts � not much; but you can still take this into account when using Energy Profiler and striving for the best and most reliable result possible. That is, either set (Settings / General / Personalization / Display / Power Saver time-out) the screensaver timeout to as low as possible � for example, to 5 seconds -, or, alternatively, send Energy Profiler into the background to stop it consuming additional power because of the constant screendraws & scrolls. As can also be seen, in the latter case (no backlight, no active screen drawing by Energy Profiler but the screen saver �kicking in�), MP3 playback (via the headphones) consumes about ~0.45W.
Incidentally, in the upper right corner of the screen, you can see �7:58� as the estimated battery life with the given current � that is, with 0.45W. This pretty much corresponds to my previous v20 battery life tests done with wired headphones and WMA�s. See THIS (cross-posted to HERE) for more info on these previous tests.
Now, let�s take what effect A2DP has on the multimedia playback. Quite a big, actually: about 230�250 mW (~0.70 - ~0.45W), as can clearly be seen in the screenshot.
2.3.2 WMA
Let�s repeat the same for WMA, which involves a little bit higher CPU usage than MP3, which is also evident if you browse my old (v12) battery life test results:
As can clearly be seen, wired headphone-based playback consumes, in general, 0.49W (0.04W more than with MP3), while the same figure with active A2DP is ~0.72W. As the second (A2DP) part has the focus, its projected total battery life is printed in the upper right corner (5:04 � again, it�s almost exactly the same that I�ve measured with my full tests); with the wired case, 7:31 is shown, which is a bit lower than the battery life (7:55) I�ve measured, but is still close.
2.3.3 Another example of CPU Monitor�s being unreliable; MPEG-4 video playback with RealPlayer and CorePlayer
Finally (in this multimedia-related section), just an example of how unreliable the results of CPU Monitor 1.10 are. In my past articles (see for example THIS) I�ve already mentioned that, with A2DP enabled, I�ve measured a ~40% relative CPU usage increase (meaning a ~15% absolute increase) with the built-in RealPlayer and even more with the current beta2 of CorePlayer. I�ve even depicted the former case with the following screenshot:
Here, the CPU usage (as reported by CPU Monitor) of the video playback without A2DP is visible under the �eRA� substring of �FreeRAM� in the centre; the playback with A2DP enabled under the � 20� to the right of it. As can be seen, according to CPU Monitor, enabling A2DP should result in a massive power consumption increase.
Now, let�s see what Energy Profiler reports of this case.
The first half of the test is taken with A2DP enabled; the second half with it disabled. I�ve played a high-quality VGA-resolution video recorded with the built-in camera. As can clearly be seen, the A2DP case consumes only a BIT more energy. Don�t be mislead by the single average (which shows a bit bigger power consumption for the non-A2DP case); it�s, when also taking into account the starting and ending regions, which, unfortunately, took quite a lot of time because I needed to switch to (and, at the end of the video clip, from) RealPlayer all the time. It, however, isn�t THAT big � actually, for some reason, MUCH lower than with the MP3 / WMA cases above. I, frankly, don�t understand why this is taking place.
I�m pretty sure the real CPU / power usage is somewhere between the values reported by Energy Profiler and CPU Monitor. This would also explain why there�s a noticeable (about 28%) frame drop increase in CorePlayer (see my related test results) while benchmarking the VGA resolution DivX (MPEG-4 Part 2) video playback with middle video quality. (CorePlayer still doesn�t support the hardware multimedia decoder capabilities of the 3D & media accelerator part of the TI chipset; this is why it can�t decode full VGA videos in real-time when running in high-quality mode.)
2.4 Bluetooth
Now, the evergreen question of Bluetooth: should you leave it on, should you make it at least non-discoverable or should you switch it off whenever possible. The following screenshot (in the first part, BT was on and discoverable; in the second half, it was off) clearly shows there is very little (almost unmeasurable) difference:
Incidentally, this is what I�ve measured on most (but in no way all!) up-to-date, modern Windows Mobile phones (NOT phone-less models � they have sometimes much worse results as can be seen in HERE) as well. See for example THIS and THIS for more info if interested on the (almost negligible) additional power consumption of the HTC Universal / Wizard.
2.5 Active (but stalling) data connections: 3G vs. pre-3G
Let�s also take a look at the additional power usage of constantly maintaining an active connection to the server. For this test, I�ve used both a 2.(7)5G (EDGE) and a 3(.5)G UMTS connection; EDGE being the first in the screenshot, UMTS the second. (Note that while my network is HSDPA-capable, HSDPA is only actively used when transferring data. This is why I�m only speaking of UMTS when referring to stalling connections.
The different sections are as follows: very good (full bars) 2G signal; between 0 and 3 bars fluctuating (that is, in general, weak) 3G signal; strong (6 bars) 3G signal, again very good (full bars) 2G signal and, finally, a bit weaker 2G signal. The projected battery life, in this order: 20:30, 6:40, 12:59, 26:35 and 16:08.
The results are pretty staggering: when there is an active connection to be maintained, 3G produce far worse results than 2G, even when the signal is strong. (And, when it�s weak, the results are downright disastrous). This means you should NEVER EVER leave for example any messaging or mailer app running in the background for an extended time. Messenger apps like Fring will just chew through your battery in no time if you leave your handset in 3G mode! ALWAYS switch back to 2G if you plan to continuously run always-connected apps! (This is true on both the Symbian and Windows Mobile platforms.) To do this, go to Programs / Tools / Settings / Phone / Network / Network Mode as can be seen in HERE. Note that if your N95 is a branded one, you may NOT see �UMTS� on the list. Nevertheless, it shouldn�t bother you: �Dual mode� instructs the handset to use 3G whenever possible, while GSM always forces it to stay at 2G networks. For Windows Mobile users, you MUST read THIS article on how you can switch the easiest way.
Note that I�ve also exported this report as a CSV file; it�s available HERE.
2.6 Power consumption difference between standard (non-data) 3G and 2G connections
Seeing the disastrous results (otherwise common to ALL mobile devices � not just the N95) in the previous section, you might also want to ask whether constantly leaving 3G without an active connection will result in any problem. To answer this question, I�ve continued making some serious tests and come up with the following test result screenshot:
The first half of this shows the case of a very good (6 bars � the maximum is 7) 3G signal; the second shows a pretty bad one (again, fluctuating between 1 and 3 � placed in exactly the same place as with the previous case when an active data connection was maintained). (The full battery life estimation with the second, non-focused area is 21:17).
The results are really interesting. While there�s no measurable difference between the 3G and the 2G connection in the case of a very good signal (both are around 0.08�0.09W), this isn�t the case with the case of a bad one, where the 3G connection itself (even without being connected) results in power usage peaks.
To be absolutely sure this is typical for 3G but not that big a problem under 2G (when the latter operates on weak(er) signal), I�ve repeated the test with a much lower (3 bars but not fluctuating, unlike the 3G one) 2G signal. The results are much better and there are no visible anomalies or power peaks. This is shown in the following screenshot:
(The first half of the chart shows a non-connected state; the second shows a stalling 2.5G (this time, GPRS, not EDGE) data connection with Messaging.)
Hope you�ve found this section instructive; now, let�s move on to the direct comparison between acbTaskMan and Energy Profiler.
3. Compared to acbTaskMan on Windows Mobile...
3.1 Cons:
- Energy Profiler is unable to monitor CPU usage, only battery usage / temperature; this also means you can�t track individual processes
- It�s not possible to subtract the additional battery usage caused by Energy Profiler itself from the full usage. While Energy Profiler consumes really little battery, this could still have been implemented � for example, by just subtracting a predefined constant from the figure.
Let me point out again that the battery life estimations have been VERY close to the actual battery life I�ve measured (see my past v20 firmware articles) so this isn�t really an issue � unlike on Windows Mobile, where you MUST pay attention to the power consumption of acbTaskMan itself, as long as you don�t run it in the slowest mode.
3.2 Pros:
- Energy Profiler has excellent exporting capabilities: Excel file, only the current view, all the screenshots etc. Opposed to this, acbTaskMan is �only� able to export a(n, otherwise, VERY detailed) Excel-compatible CSV log file; it has no, for example, built-in screenshot taking / exporting or exporting the entire series of measurements as a series of screenshots (an example directory list shot is HERE).
Nevertheless, acbTaskMan�s file logging capabilities are, as has already been pointed out, just great. It contains (almost) the same information as that of Nokia � and, of course, also the memory usage and detailed (!) process information (process name, CPU usage and, with a selected, �charted� process, its memory usage) in the order of their CPU usage. (That is, it doesn�t log all processes, only the ones with the highest CPU usage � and, of course, the selected one).
I�ve made a screenshot showing Excel rendering these results. I�ve set acbTaskMan.exe to be the charted app; this is why its name, CPU and memory usage are visible in columns F, G and H. Column I and J contains the process that uses the biggest CPU time in the system; in the first half of the logging results, it�s the same acbTaskMan.exe. With the second half, on the other hand, when I activated Pocket Controller on the desktop, PCCommLoader.exe �kicked in� with a much higher CPU usage and, consequently, became the process listed in I and J, �shifting� acbTaskMan.exe, which remained the second most CPU time consuming app, to the K and L columns. Incidentally, the power column (E) is also worth checking out: when I started Pocket Controller and the CPU usage skyrocketed (from 4-5% to around 40%), the power usage also became serious: from around 50mA to around 410 mA.
- it also measures Voltage and temperature, not only Amperage. This means more reliable total power requirement analysis, independent of the (remaining � don�t forget it somewhat decreases and, consequently, the Amperage somewhat increases with a (slightly) depleted battery) voltage of the battery.
I don�t, however, consider this to be a major flaw with acbTaskMan. If you do your tests with a 100% topped up battery, the actual voltage of the battery won�t count much as you can assume the voltage of the battery is almost the same and you can, therefore, pretty much rely on the simple Amperage results.
- Running average computed from the latest restart / marker. It can be VERY useful. acbTaskMan, unlike its (free) predecessor, acbPowerMeter, doesn�t have any similar feature.
Speaking of the old acbPowerMeter, it did averaging (see for example THIS screenshot), but lacked the running total � the numeric value of the current power consumption.
- When an external charger is attached, the background of the chart will be changed to grey as can be seen in THIS screenshot. acbTaskMan doesn�t support this. (On WM, attaching the charger will also really increase the current measured by the tool as can be seen in THIS screenshot, showing a total of 600 mA, as opposed to the non-charging state.)
- Much more frequent updates without a noticeable increase in CPU usage � acbTaskMan is definitely worse in this respect (because of operating system restrictions)
- Adding markers any time (with both long-pressing 5 or quickly restarting (2 or menu) the measurement).
This not only helps with identifying a certain area in the timeline, but is also a tremendous help with calculating the running average (see the second bullet above).
As an example to show the importance of the former feature, let me refer to one of my older articles on using acbTaskMan, which has several screenshots of the app. For example, while explaining the following one:
as I couldn�t use markers, I had to rely on the readers� ability to correctly identify the 100/80/20% cases (see the explanation right under the first screenshot in section �2.1 The filesys throttler � benchmarks� in the original article), which isn�t guaranteed with, say, a newbie. Then, just inserting (vertical) markers to the points when the activity started, it�d be much easier to refer to the �first�, �second� and �third�, easily-visible markers.
As far as the power average is concerned, it is totally recomputed for the section started to be (re)computed when you insert a new marker anywhere, while keeping the old average. This can be of extreme help when you need absolutely the most reliable results. An example of the latter is clearly visible in the following screenshot:
Here, there�re two running averages displayed; the first starts about 1:59; the second at 2:29. The first average shows 4.63 Watts (showing � along with the grey background � that the device was on charger); the second 3 Watts (showing the mean between the previous 4.63 Watts and 0.7 Watts; the former having somewhat more weight because of the time of the measurement). The average results� being stored is a real gift and can prove very useful when, otherwise, it�d be very complicated to correctly estimate the average power consumption over a given time.
- Supports sliding over the window � can prove useful when, for example, you want to hide what happened in the last seconds (you can�t be quick enough to stop measurement without this not being reflected in the power usage) not to confuse the readers. This is impossible with acbTaskMan � with the latter, you can�t slide the view and, consequently, can�t hide the last seconds. (Fortunately, as acbTaskMan, generally, uses a far lower sampling frequency, quickly pausing it via Menu / Pause, in general, doesn�t result in a visible and/or annoying CPU usage / power consumption increase.)
- Has an excellent box plot / histogram mode, which acbTaskMan completely lacks. Two screenshots:
- Definitely lower CPU usage than acbTaskMan, unless you switch the latter to even (annoyingly) slower sampling (Display / Update Speed: Low or, to really reduce the CPU usage to ~1.5% (on 624 MHz / PXA 270), X-Low) on the latter.
- The timescale is much more usable in Nokia�s app than in acbTaskMan. In the latter, there�re only two time points: �X Min./Hour(s) Ago� and �Now�. Of course, the file-based logging will still have a precision depending on the global frequency set in Display / Update speed.
This means you can even identify seconds in Nokia�s app. In acbTaskMan, you will need to consult the log file for this.
- Much better built-in help than in acbTaskMan � much easier to get a grasp of how the app should be used (example screenshots: 1 2 3). Also, the online docs is far more informative than that of acbTaskMan.
UPDATE (12/02/2007):
1. Make sure you check out THIS HoFo, THIS and THIS AAS and THIS The Register threads.
2. in the meantime, I�ve continued testing, mainly for three reasons:- HERE (do check it out � there are a lot of information there; note that you should read the entire thread BEFORE drawing conclusions from any post!), �Stewart Atkins� stated he had five (5) Watts (!!!) of power usage during video playback, which corresponds to about 50 minutes of total battery life
- in the same thread, �Jasmine� stated Nokia�s app itself burns �about a third of a watt�, which I in no way think is right
- and, still in the same thread, one of the developers, �MikaK� stated using the 5s mode results in the most accurate measurements (as opposed to the default, 0.25s sampling)
For this test, I�ve run some serious benchmarks with CorePlayer, the leading desktop & mobile cross-platform (Palm / Windows Mobile / Symbian) video player. I�ve used the built-in benchmarking utility, playing back a 640*480 DivX video stream at medium quality.
The video played back is the second episode of �Battlefield Scandinavia�. It starts with a very demanding, high-rate, wildly animated computer animation (causing dropped frames even at this Medium quality on the current, still non-hardware-decoder-based version of CorePlayer on the N95); the next part has far less animation (mostly zooming in/out of maps). The vast difference needed to decode the first part (as opposed to the second) will also be visible in the chart.
The following screenshot shows four cases (the first two aren't separated!):
These are as follows:
1. default, benchmarked playback with speakers
2. the same with A2DP (to see whether there�s any additional battery drain � there doesn�t seem to be, but the benchmark results still drop by about 27%, from 112 to 88% showing there is still something taking up some CPU cycles)
3. speaker-based playback again (just like with bullet 1)
4. still a speaker-based playback but, now, with a 5-sec sampling rate
As can clearly be seen, there isn�t any notable difference between the results � the 5-sec sampling rate in no way decreases the total power usage. This is also reflected in the benchmark results returned by CorePlayer itself: it�s ~112.5% in all the three non-A2DP cases, decreasing to ~88% with A2DP enabled. Without any kind of benchmarking running in the background, it�s still around ~112.5%, which clearly shows the additional CPU usage introduced by Energy Profiler is negligible. This is definitely very good news.
Finally, again, it seems you don�t need to switch to 5s sampling either - frankly, I don't get why MikaK instructed the folks to do so.
|
Hybrid Mode
