All About Symbian - Nokia (S60) and Sony Ericsson (UIQ) smartphones unwrapped

Go Back   All About Symbian Forums > Symbian Based Devices > S60 (Series 60) > Nokia N95 and N95 8GB

 
 
Thread Tools Display Modes

  #1  
Old 01-12-2007, 08:51 PM
Menneisyys Menneisyys is offline
Registered User
 
Join Date: Oct 2007
Location: Europe
Posts: 433
Menneisyys is on a distinguished road
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:
  1. 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.
  2. 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.
  3. 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.

  #2  
Old 01-12-2007, 08:52 PM
Menneisyys Menneisyys is offline
Registered User
 
Join Date: Oct 2007
Location: Europe
Posts: 433
Menneisyys is on a distinguished road
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.

  #3  
Old 01-12-2007, 08:53 PM
Menneisyys Menneisyys is offline
Registered User
 
Join Date: Oct 2007
Location: Europe
Posts: 433
Menneisyys is on a distinguished road
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:
  1. MP3 and WMA (see next subsection) playback (using the wired factory headphones at 70%)
  2. The same via A2DP
  3. 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.

  #4  
Old 01-12-2007, 08:53 PM
Menneisyys Menneisyys is offline
Registered User
 
Join Date: Oct 2007
Location: Europe
Posts: 433
Menneisyys is on a distinguished road
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:
  1. Energy Profiler is unable to monitor CPU usage, only battery usage / temperature; this also means you canít track individual processes
  2. 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.

  #5  
Old 01-12-2007, 08:54 PM
Menneisyys Menneisyys is offline
Registered User
 
Join Date: Oct 2007
Location: Europe
Posts: 433
Menneisyys is on a distinguished road
3.2 Pros:
  1. 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.
  2. 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.
  3. 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.
  4. 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.)
  5. Much more frequent updates without a noticeable increase in CPU usage Ė acbTaskMan is definitely worse in this respect (because of operating system restrictions)
  6. 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.
  7. 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.)
  8. Has an excellent box plot / histogram mode, which acbTaskMan completely lacks. Two screenshots:




  9. 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.
  10. 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.
  11. 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:
  1. 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
  2. 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
  3. 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)

Last edited by Menneisyys; 04-12-2007 at 03:46 PM.

  #6  
Old 01-12-2007, 08:54 PM
Menneisyys Menneisyys is offline
Registered User
 
Join Date: Oct 2007
Location: Europe
Posts: 433
Menneisyys is on a distinguished road
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.

UPDATE (12/02/2007, later):
In HERE, I have been asked to do some additional Wi-Fi tests with file upload to pinpoint the difference between the 4mW and the 100mW transfer power settings. As Iíve done several tests like this in the past (see for example THIS), I at once knew what to do. I downloaded THIS free FTP client and, from the storage card, Iíve benchmarked uploading a 24M file to a computer in the same LAN as the Wi-Fi router the N95 connects to. In addition to the power charts, I've also used a stopwatch to measure the transfer time.

Iíve made two tests to be absolutely sure (with a reboot in between).

The first test:



About 2 metres (4 feet) away:

1st, 100 mW: crash after some 15M
2nd, 100 mW: 2:30
3rd, 4 mW: 2:54 (took slightly longer because the transfer, for some reason (an internal bug in the FTP client), stalled for some time.

About 6 metres, still the same room
4th, 4 mW: 2:30

Two walls in between:
5th, 4 mW: 2:45

Three walls in between:
6th, ~3:00

Second (after a reset, still at 4 mW):



The same as the three case above: stopped after transferring 130k
2nd: client crashed after transferring 17.5M (this FTP client likes crashing...)

As can be seen, there isnít much difference between the 100mW and the 4mW case. With the latter, the N95 will still burn much more power than 4mW when the signal is weak (see the sixth case, with three walls in between, in the first screenshot and compare it to the cases of the same room / two walls). I donít even know whether thereís any sensitivity difference between the 100 mW and the 4 mW case Ė I havenít seen any. There isnít any difference in the power used / transfer times, thatís for sure.

UPDATE (12/03/2007): Iíve continued benchmarking the power usage with active network connections to find out the optimal selection of network usage. The following screenshot shows a continuous web browsing (with occasional Messaging POP3 downloads) with Opera Mini 4, using the lowest brightness level (& at night & opened and heavily used (for OM scrolling) slider; that is, the buttons were almost always lit), Bluetooth off (not that BT would have any effect on the outcome, it consumes so little power) over EDGE with weak and, according to the N95ís bars, highly (between 0 and 3 bars) fluctuating signal.



As can clearly be seen, even with such, fluctuating signal, the power consumption is very moderate; it averaged to 0.49 Watts, which corresponds to about seven and a half hours of continuous use. Again, note that all this shows a case of active use, tons of page downloads, scrolling, navigation. Taking this into account, the results are extremely good Ė and, of course, MUCH-MUCH better than the 3G case with a weak 3G signal. Iíll also publish similar, heavy-OM-use tests with strong EDGE (2.75G) and weak 3G signals so that you can see the difference Ė stay tuned.

UPDATE (12/03/2007, later):

As promised, Iíve continued running some real-world tests. Iíve continuously used Opera Mini 4 (and, at the beginning, Messaging Ė hence the longer power usage peak at the very beginning) for some 20 minutes under exactly the same (lowest backlight, dark environment, screen and keypad constantly illuminated with backlight, no BT, no other tasks) conditions as the previous weak-signal EDGE test. Iíve forced a UMTS-only connection with weak signal (fluctuating between 0 and 3 bars; sometimes reconnecting); that is, I didnít let the phone switch back to the 2G band (this way, I had some 6 or 7 reconnections because of the low signal). The results are as follows:



If you take a look at the running average (1.04W), you quickly realize that itís more than two times greater than the previous case with the weak EDGE signal. Yes, when the signal is weak, selecting 3G over 2G is a VERY bad choice (for data - exactly as with standard phone), unless you REALLY need the additional speed.

Iíll soon publish real-world Opera Mini usage test results with strong and stable 3G signal Ė stay tuned!

UPDATE (12/03/2007, again later): As promised, the new Opera Mini real-world usage results: 3.5G with strong signal (always switched to HSDPA for download); otherwise, exactly the same circumstances as in previous tests.



As can clearly be seen, while the situation is a bit better than in the case of weak signal, the total power consumption is almost exactly twice (0.97W) of that of the (weak-signal!) EDGE case. That is, your battery will deplete twice as fast as with 2G data connection even if you have very good 3G signal.

(Full CSV file HERE.)

UPDATE (12/04/2007):

More info on power consumption of constant (streaming) data connections

Iíve made some additional tests to find out whether the battery consumption depends on the actual transfer rate. For this test, Iíve used the just-released Nokia Internet Radio, with two stations. One of them is a low-quality, mono, 24 kbps one (Genre / News / Veluwe FM Putten); the other is a high-quality, stereo, 192 kbps (Language / Finnish / Bassoradio) station. This means the former can be played back over even a plain, slow GPRS connection and the latter can still be played back over an EDGE connection.

BY selecting two radio stations really differing in streaming speed, my main goal was to find out whether the power consumption of the modem is proportional to the streaming speed.



(all these figures with A2DP enabled; without A2DP, theyíre all about 220 mW lower)

This chart proves the following: the power usage is totally independent of the actual data rate and only depends on the technology (2G vs. 3G) used. In this regard, thereís no difference between GPRS and EDGE modes Ė they consume the same power. This is certainly very good news: after all, EDGE can be acceptably fast (unless your wireless operator doesnít provide you with the maximum speed available Ė some of them, unfortunately, go this way).

This also means if you either listen to low-speed (generally, up to 30 kbps) radio stations (not available as a higher-speed stream) even playable over GPRS connections OR you have EDGE and you donít listen to radio stations over 192 kbps, you most probably can safely fall back to using 2G to save some 600 mW, which means you can greatly improve the battery life of your handset.

VERDICT: All in all, if a 2G connection is able to reliably stream a given radio station, force your handset to operate in 2G mode. Donít forget: EDGE connections can still be able to play most, if not all, radio stations. Try extending your battery life!


(guys and gals, sorry for having to slice it up into several parts Ė the forum settings only allow for posting 10k-long posts at a time.)

Last edited by Menneisyys; 04-12-2007 at 03:46 PM.
Ads

  #7  
Old 01-12-2007, 09:05 PM
seki's Avatar
seki seki is offline
Registered User
 
Join Date: Apr 2007
Posts: 971
seki is on a distinguished road
Beer Many thanks!

Terrific and comprehensive report! Probably deserves a technical sticky status.

  #8  
Old 01-12-2007, 09:24 PM
Hih Hih is offline
Registered User
 
Join Date: Jul 2003
Posts: 131
Hih is on a distinguished road
Great review and tips. Thanks a lot for your hard work.

  #9  
Old 01-12-2007, 09:32 PM
rottie's Avatar
rottie rottie is offline
Registered User
 
Join Date: Dec 2003
Location: London,UK
Posts: 287
rottie is on a distinguished road
Ok, but it's a pain to change the network settings to 3G everytime one wanna check something on the net.

Good article, but didn't really show anything new. Well, everyone knew 3G drains more battery life than 2G, weak signal is worse than good signal, wired headset uses less than A2DP etc.

But I do appreciate the effort put in proving it!

  #10  
Old 01-12-2007, 10:10 PM
Menneisyys Menneisyys is offline
Registered User
 
Join Date: Oct 2007
Location: Europe
Posts: 433
Menneisyys is on a distinguished road
Quote:
Originally Posted by rottie View Post
Ok, but it's a pain to change the network settings to 3G everytime one wanna check something on the net.

Good article, but didn't really show anything new. Well, everyone knew 3G drains more battery life than 2G, weak signal is worse than good signal, wired headset uses less than A2DP etc.
Well, it has some interesting, quantitive and pretty revolutionary results; for example, it shows 3G doesn't consume more power if and only if there's a good signal (as opposed to the case of bad signal) and that, contrary to what many N95 users think (and also recommend), Bluetooth doesn't really increase the battery consumption.

Of course, I agree the majority of this stuff isn't anything new to most N95 users

  #11  
Old 01-12-2007, 10:14 PM
Menneisyys Menneisyys is offline
Registered User
 
Join Date: Oct 2007
Location: Europe
Posts: 433
Menneisyys is on a distinguished road
Quote:
Originally Posted by rottie View Post
Ok, but it's a pain to change the network settings to 3G everytime one wanna check something on the net.
It indeed is. However, if the 3G signal where you are is good and you always exit the apps that use your 3G connection as soon as possible (also meaning you don't run Messenger-like apps for hours), you won't really see any battery life degradation.

Alternatively, you may want to consider switching to Opera Mini as the main browser - it's very fast even over a slow GPRS connection.

  #12  
Old 01-12-2007, 10:33 PM
rottie's Avatar
rottie rottie is offline
Registered User
 
Join Date: Dec 2003
Location: London,UK
Posts: 287
rottie is on a distinguished road
Quote:
Originally Posted by Menneisyys View Post
It indeed is. However, if the 3G signal where you are is good and you always exit the apps that use your 3G connection as soon as possible (also meaning you don't run Messenger-like apps for hours), you won't really see any battery life degradation.

Alternatively, you may want to consider switching to Opera Mini as the main browser - it's very fast even over a slow GPRS connection.
Are you suggesting that one should suffer using GPRS on HSDPA ENABLED phone to save battery???
I do have a power socket at home to charge it, you know?

And if I'd want a slow internet browsing I'd buy an iPhone...

Last edited by rottie; 01-12-2007 at 10:36 PM.

  #13  
Old 02-12-2007, 12:30 AM
regimorales regimorales is offline
Registered User
 
Join Date: Aug 2003
Posts: 48
regimorales is on a distinguished road
This is an excellent report! I'm surprised that blue tooth being on or off makes very little difference in battery consumption. I always thought that leaving blue tooth on (and discoverable) drained the battery a lot faster than normal.

  #14  
Old 02-12-2007, 06:44 AM
Menneisyys Menneisyys is offline
Registered User
 
Join Date: Oct 2007
Location: Europe
Posts: 433
Menneisyys is on a distinguished road
Quote:
Originally Posted by rottie View Post
Are you suggesting that one should suffer using GPRS on HSDPA ENABLED phone to save battery???

Not really - I meant you can have almost exactly the same page download speeds using GPRS (let alone EDGE) if you use Opera Mini than with Nokia Web / Opera Mobile over a HSDPA connection. Opera Mini 4 rocks.

BTW, if you do remember to exit Nokia Web / Messaging (and, thus, terminate the connection) after the session, you won't see much difference in battery life. It's on the long run (say, Internet connections active for more than a few minutes) that the vastly increased power drain of active 3G data connections "kick in" and severely degrade battery life.

  #15  
Old 02-12-2007, 06:51 AM
Menneisyys Menneisyys is offline
Registered User
 
Join Date: Oct 2007
Location: Europe
Posts: 433
Menneisyys is on a distinguished road
Quote:
Originally Posted by regimorales View Post
This is an excellent report! I'm surprised that blue tooth being on or off makes very little difference in battery consumption. I always thought that leaving blue tooth on (and discoverable) drained the battery a lot faster than normal.
Did you (or, anyone) test this in real life? With a removed SIM card & offline mode (so that nothing has any effect on the phone), the time for the battery to completely discharge.

There MAY be differences; it's just that they're not measurable, they're so minor.

Or, at least not measurable with this tool. I don't think this - the problems of the tool - is the case, however. With all my multimedia benchmarks, which I've also done using the "traditional" "let the N95 play some test WMA's / MP3's until the battery completely depletes", I've got exactly the same results as with running the tool.

Finally, keep in mind that microelectronics is continuously evolving. While a BT module in a, say, four-year-old phone may have had a noticable adverse effect on the battery life, current BT modules are far better in this respect. Not only on Symbian, but also on Windows Mobile and other mobile platforms - even dumbphones. (I've made a LOT of tests on Windows Mobile to find out the battery life of the phones with and without BT. The results also back up this.) Exactly like the IrDA "myths" with Windows Mobile, those old "rule of thumbs" ("deactivate BT whenever possible") are not necessarily true any more.
 

Bookmarks

Tags
acbtaskman, battery, energy, extending, life, n95, profiler, review, tips

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
First battery charge and battery life... tutti89 Nokia N71, Nokia N73 and Nokia N75 1 17-07-2008 06:15 PM
battery help n95 need advice thanks buxz777 Nokia N95 and N95 8GB 12 17-08-2007 10:19 AM
Battery life and the slider JimBob1971 Nokia N95 and N95 8GB 1 04-05-2007 03:54 PM
Battery Life of Nokia N91 nmittar Nokia N91, N91 8GB and Nokia 3250 2 30-06-2006 12:28 AM
Strange battery life cmatthee Nokia 9210 and 9290 10 27-08-2002 04:23 PM



All times are GMT. The time now is 03:47 PM.


vBulletin skins developed by: eXtremepixels
Powered by vBulletin® Version 3.8.0
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
Copyright Notes || Contact Us || Privacy Policy