n900 Battery Duration: Ogg vs. MP3

There have always been complaints about Ogg being more of a battery hog on the Nokia tablets compared to Nokia optimized MP3. I decided to measure the difference.

All tests were run on a preproduction n900 device that Nokia distributed at the Maemo Summit. The software is the Maemo5 41-10 release which was already installed in the device. I installed Ogg Support, gst-av, ffmpeg and OpenSSH. Otherwise the device is the default 41-10 release. WLAN connection was configured but not activated during the tests. A SIM card was in place only in the SIM idle test.

Before every test I charged the device, disconnected the charger once I noticed the green led, and rebooted the device. After the boot I started a simple script in the xterm. The script logged current time to a file, run “sync” command and slept 60 seconds after which it started the loop again.

Idle tests

I run two idle tests between the libvorbis and ffvorbis tests but I’ll introduce the idle results first.

First idle test was a generally idle device. I.e. it did have the default processes running but I didn’t start anything, except my logging script. During the test I did check a couple of times if the device was still on. The battery lasted for 93.8 hours.

According to Igor Stoppa, there’s a cellmo sw bug that makes current higher without a SIM card. Therefore I rerun the idle test with a SIM card inserted. During the test I received two phone calls which I hung up, I received two SMS messages and wrote one. At one point the notification led was blinking for 45 mins. The battery laster for 93.6 hours.

There’s probably a few hour error margin on those tests, so basically the battery lasted roughly a bit over 90 hours in both tests.

Powertop shows that after 60 seconds of showing the xterm with display blanked, the CPU is mostly in the highest C4 sleep state:


C# Ratio Avg/dura Frequency Ratio
C0 0.3% 600 MHz 0.0%
C1 0.0% 550 MHz 0.0%
C2 0.1% 1.1ms 500 MHz 0.0%
C3 0.2% 15.2ms 250 MHz 100.0%
C4 99.5% 2297.0ms    

Ogg vs. MP3

Now that we know how long the device will last when idle we can move to the actual results.

I run two sets of tests. First one was with the Ogg Support 1.0.5 from Extras and the second one with Felipe’s gst-av (2009-09-25) which is using vorbis decoder from FFmpeg (2009-09-07). I repeated both tests three times, running every other test with MP3 and every other with Ogg.

After restarting the device with a fully charged battery I started the logging script in the xterm, started the File Manager and clicked on the MP3 or Ogg file which then started playing that single file in a loop in the Media Player. Both files were encoded with variable bitrate 192kbps settings. Volume of the device was set to minimum and no headphones were connected.

This is what powertop shows while playing MP3 in Media Player compared to libvorbis:


MP3 libvorbis
C# Ratio Avg/dura Frequency Ratio
C0 37.9% 600 MHz 3.1%
C1 0.0% 0.2ms 550 MHz 1.1%
C2 7.0% 3.0ms 500 MHz 17.5%
C3 55.1% 8.0ms 250 MHz 78.3%
C4 0.0%    
C# Ratio Avg/dura Frequency Ratio
C0 70.1% 600 MHz 18.2%
C1 0.0% 0.1ms 550 MHz 0.0%
C2 4.7% 2.7ms 500 MHz 28.8%
C3 25.1% 7.8ms 250 MHz 52.9%
C4 0.0%    

Clearly while using libvorbis the CPU spents more time in lower sleep state and running with higher frequency. The following graph shows how this affects the battery. The battery lasts around 18 hours while playing MP3 but only around 11 hours while playing Ogg.

Battery duration: MP3 vs. libvorbis

Next numbers are with ffvorbis instead of libvorbis. Powertop shows that while using ffvorbis the time spent in different sleep states matches quite closely to the ones of MP3 usage:


MP3 ffvorbis
C# Ratio Avg/dura Frequency Ratio
C0 37.9% 600 MHz 3.1%
C1 0.0% 0.2ms 550 MHz 1.1%
C2 7.0% 3.0ms 500 MHz 17.5%
C3 55.1% 8.0ms 250 MHz 78.3%
C4 0.0%    
C# Ratio Avg/dura Frequency Ratio
C0 38.4% 600 MHz 2.1%
C1 0.0% 0.1ms 550 MHz 0.0%
C2 5.7% 3.1ms 500 MHz 13.2%
C3 55.9% 8.3ms 250 MHz 84.6%
C4 0.0%    

The similarity of the powertop numbers can be seen in the battery duration as well:

Battery duration: MP3 vs. ffvorbis

The average battery duration while using ffvorbis was slightly better than while using MP3 but probably well within the error margins. So basically they are equal when battery duration is concerned.

It’s interesting to see how the situation changes in a year, will Nokia make better optimizations to their MP3 decoder than the community to the FFmpeg. These tests were run in a preproduction device with a pre-sales software. I’m sure the overall power management of the device will get (even?) better in the future software releases.

Addition (2009-11-17):

When using the speakers the n900 runs some “speaker protection algorithms” that take extra power. I repeated the ffvorbis test case with Nokia’s headset and here are the results:

Battery duration: ffvorbis with headphones

On the average the battery duration improved a bit over three hours.

Addition (2009-11-25):

I run the same tests (Ogg Support 1.0.5, no headset) for Flac:

Battery duration: libflac

n900 with a pre-sales w41-10 software can run Flac roughly 1.5 hours longer than MP3.

GCC options and floating point

There was (again) some discussion on #maemo about gcc options regarding VFP usage so I decided to make a simple test with different gcc options using the Maemo’s cs2005q3.2-glibc2.5-arm toolchain. Nothing new here for people already familiar with the floating point stuff.

In the test I compiled a very simple test code with different -mfpu and -mfloat-abi options, -O2 and -march=armv6 were given in all cases. The asm code is linked in the table. The code is a simple for loop which could be optimized to one round but based on the results it looks like the gcc didn’t do this kind of tricks.

Although you can ask the default options from the gcc I decided to test also without the options. The test was run on n810 and results are in the table below.

GCC none hard soft softfp
none 0m 31.11s
0m 31.01s
0m 0.00s
asm
-
-
-
asm
0m 31.24s
0m 31.00s
0m 0.00s
asm
0m 4.38s
0m 4.37s
0m 0.00s
asm
fpa 0m 30.64s
0m 30.54s
0m 0.00s
asm
5m 52.53s
0m 21.25s
5m 30.66s
asm
0m 30.57s
0m 30.55s
0m 0.00s
asm
5m 52.56s
0m 21.06s
5m 30.69s
asm
vfp 0m 31.09s
0m 30.99s
0m 0.00s
asm
-
-
-
asm
0m 31.08s
0m 31.00s
0m 0.00s
asm
0m 4.40s
0m 4.39s
0m 0.00s
asm

Looks like the default for -mfpu is vfp and the default for -mfloat-abi is soft.

There are three different values, one takes some seconds, one takes some tens of seconds and one takes some minutes.

This was expected as there are three different ways to do floating point math. In the slowest one the kernel emulates the fpu after cpu has run into undefined floating point opcode. This is extremely slow as there are a lot of context switches. A faster way to do the floating point math without the hardware is to let the gcc to compile the floating point math to the binary itself (and something in libgcc?). The fastest way is to use the VFP hardware.

N800 and GCC options

I was a a bit surprised to hear that Nokia doesn’t compile the Maemo stuff with any ARMv6 specific GCC options. According to someone in IRC the gain is insignificant compared to increased size (and thus booting time) when not using thumb mode.

I decided to test this out and compiled a bunch of packages with -mcpu=arm1136j-s -mfpu=vfp -mfloat-abi=softfp GCC options and without -mthumb.

The performance tests included measuring rootfs booting time, gtk-perf, cairo-perf, encoding and decoding with theora and decoding with vorbis. Memory comsumption was not measured, even though it should have been. None of the tests were made with scientific accurance and there can be errors in the tests, although zuh double checked most of the tests. There aren’t much details here, but I should have them written down, so ask if you have any questions.


thumb

I took some of the gtk, hildon, glib, xlib, etc libraries and binaries that were compiled with -mthumb and compared the sizes. The sizes increased 23% in average, the minimum increase being 8% and the maximum 30%.

Booting time was calculated by measuring the time between setting the clock in /etc/init.d/rcS and running the last init.d script. This is not very accurate since processes are started to background etc. The booting time increased roughly 8% (2 seconds on my MMC).

Encoding with theora was a bit of a surprise. The encoding time with theora compiled with no GCC options and with –disable-float was even slightly faster than with floats and the mentioned ARMv6 GCC options. Decoding with theora seemed to be roughly 5% faster with the new options.

The biggest practical difference in this test came with vorbis decoding. Decoding with ARMv6 options took only 30% of the time when compared to no options.

Gtk-perf doesn’t cover many widgets but hopefully shows the direction of the performance differences. The improvement was around 14%.

Cairo-perf doesn’t give one nice number to for making hasty conclusions, but the improvements varied from 1.05x to 7x, while the average was 1.8x. cairo-perf-diff-files reported over 800 speedups and two slowdowns.

zuh writes about memory comsumption, thumb mode swithing, gtk-perf and cairo-perf in more detail in Movial‘s syslog.

For me the disk space isn’t an issue and I don’t boot the device so often that the two second delay in bootup really matters. So, for me the little speedups are welcome. I can even tolerate the memory loss reported by zuh.