Month: February 2010

There’s something on my ARM is the name of a talk I first gave at the Open Source Developers Conference in Brisbane, Australia, in December 2009. Since drafting this post I have given an updated version of the talk to LinuxSA, my local Linux Users Group.

In the talk, I gave an introduction to the software used in Chromium and some of the neater features present in the browser, followed by some information about the code I wrote as part of my Google Summer of Code project working on Chromium’s Linux port. Finally, I spoke about the ARM port of Chromium that I maintain and showed some power usage data I collected comparing Chromium to Firefox running on the BeagleBoard, the core of which is the OMAP3430, an ARM based system-on-chip. This page goes into some detail about the power usage setup.

Power usage

Method

Initially I was using a bench power supply with a digital ammeter borrowed off of local open source hardware hacker David Rowe. This method did not allow the automatic collection of data, relying on the visual inspection and noting of the readout from the ammeter. I also had to returnÂ the bench supply, so I desired a better method.

After perusing the BeagleBoard System Reference Manual,
I discovered the board has a 0.1Ω sense resistor (R6) on the 5V input power rail. The two pins of the resistor can be accessed via the pads at J2. See section 8.2.5 of the BBSRM for more information.

It should be noted that the resistance of the sense resistor has an error factor of 5% on the early revC models (C2), and I presume that it is a similar case for the revB, making the absolute numbers potentially inaccurate. The relative differences are still valid.

As described by a thread on the BeagleBoard mailing list, the revC version has this resistor connected to the TWL4030 IC, allowing it to be measured via I²C. As I only had a revB board available, I had to use an alternate method.

I removed a jumper from an old PCI card and attached it to J2. Using a cable from the reset switch of an old PC case, I attached it to a Arduino board.

The Arduino Diecimila contains an ATmega168 8-bit microcontroller. It also has a 10-bit analog input suitable for measuring the voltage drop across the Beagle’s sense resistor. The analog input can use a 5V or internal 1.1V reference, I chose the 1.1V reference as the measured voltage ranges from 0 to 50mV.

The Arduino was programmed to use the 1.1V reference and read from analog pin 0 every 15ms, and send the value down the serial port to a host PC. A python script, grabserial, was used to capture this output and write it along with a timestamp. This output was post-processed using pylab to smooth the data, and graphed using matplotlib.

Software

Firefox was installed from the Ubuntu Karmic repository, version 3.5.5. Chromium was built from top-of-tree using the Code Sourcery 2009q3 cross compiler, and linked against a Ubuntu Karmic rootfs. It was built with the following gcc options:

-march=armv7-a -mtune=cortex-a8 -mfpu=neon -mthumb -mfloat-abi=softfp

For more information on cross compiling Chromium, see the page I wrote at LinuxChromiumArm. The same rootfs as used for linking was placed on a class 4 SD card and booted using a 2.6.32-omap kernel.

Results

Cold start

The system must make do with 128MB of RAM, and a small swap file mounted on a very slow root file system. Chromium starts faster than Firefox, even in the low resource environment present on the BeagleBoard. The peak power draw is higher, however the area that Chromium’s use is above that of Firefoxes is much smaller than the area that Firefox is above Chromium.

Warm start

Chromium starts much faster than Firefox on warm start, and manages to get close to idle power draw before Firefox has reached it’s peak draw.

The steady state, where both are displaying their static home page, draw is similar for both browsers. The peaks that can be seen around the 40 second mark are suspected to be due to a timer expiring, causing the kernel to flush it’s page cache to disk.

Gmail load and idle start

When displaying a dynamic page Chromium does a btter job of staying idle. Again the peak power draw is higher for chromium, but it drops to a steady state and stays in that state for a long time. Firefox does not achieve an idle state after two minutes of zero user interaction.

Conclusion

These tests show that Chromium’s has the ability to get to idle quickly, and stay there whilst running a large web application. This is useful information byond the current data we have on load time and memory usage.

Further work

In my Summer of Code proposal I outlined the creation of a power aware buildbot, a system that would run a subset of Chromium’s page load tests, as well as a idle test, and graph the results so that improvements and regressions can be tracked as the code base is worked on. I intend to prototype this system, using the BeagleBoard along with a OLPC XO-1.5 pre-production machine. There is some evidence that ChromeOS engineers at Google have a setup doing power instrumentation.

A goal would be to show a shift in power usage, either up or down, over time, that can be attributed to code changes in the browser. A use of this information could be to correlate power usage against memory, other I/O, and CPU usage, to see which of these metrics affects power usage the most.

The OMAP3 system on chip consists of many small components that can be individually powered down. In my tests above, the kernel was not aware of these features, meaning there is potential for lower power usage, especially when idle. Re-running the tests with a power management enabled kernel may offer new insights into the systems behaviour.