Tablets go large: Samsung is reportedly doing a 12-incher. Apple is also looking into larger tablets. Is this a trend? [Read more]
Editor’s Note: This is the fourth article in a new series by SUSE community marketing manager Brian Proffitt for Linux.com called “Reality Check” that will take a look at Linux in the real world. For more in this series see OpenStack is Not the Next Linux, 5 Linux Features You Want in Your Company and Defining the True Success of Linux.
Intel x86 processors have long dominated the computing market, but a not-so-new competitor will soon be giving Intel a run for its money in server space: ARM processors.
“Traditional” computing devices like laptops, desktop computers, and servers have been powered by Intel or Intel-licensed processors for 30-odd years, and plenty of operating systems can run on machines with these chips, including Linux, Windows and Mac OS X.
ARM processors, on the other hand, are not made by just one company like Intel. Instead, ARM develops only the core architecture and licenses it to any hardware maker that wants to use the design to make its own processors. Because of the way it is designed, ARM processors use very little power, which makes them perfect for personal electronic devices where battery resources must be frugally maintained.
But all of these vendors licensing ARM and building their own version of the processor has led to a serious fragmentation problem. An ARM processor or system-on-a-chip (SoC), a piece of hardware that essentially miniaturizes all the components to make an SoC a stand-alone computing device, will carry the fingerprints and design used by each ARM vendor. That means software that runs on one ARM SoC may not run on another ARM SoC.
Last fall, this situation started to change, when the Linaro Enterprise Group banded together some big newer players in ARM space, including AMD, Facebook and HP, working together to try to unify the fragmented ARM processors enough to create a new class of made-for-server ARM chips.
The cloud is one of the big drivers for making ARM servers so attractive. One of the obvious (yet sometimes missed) points about the cloud is that you need a lot of hardware to make it go. In hardware that is Intel-powered, that means power and heat.
The average Intel server processor pulls in something like 80 watts of power just to run. But a multi-core ARM SoC draws only about 4 watts of power. That’s a whole system on a chip, too, not just the processor. Less power means less resistance and less heat. Less heat means less money wasted on cooling and more capability to compress ARM-based systems together.
That’s why ARM is getting a lot more attention from hardware vendors, software vendors and really big cloud computing users. And Linux distributions, too. If ARM architected hardware is going to be more prevalent in the cloud, then it makes sense that Linux should be able to run atop such machines.
openSUSE, for instance, has a dedicated ARM team, which releases an ARM version of openSUSE 12.2 last November, and is currently working on a 12.3 release.
openSUSE for ARM is almost there! We are currently getting ready for our 12.3 release which will work on the devices listed below. Almost all of the usual openSUSE distribution (>5000 packages) builds and runs on all the ARM hardware we have tested it on so far. The team can take advantage of the openSUSE Build Service to cross-compile almost all of openSUSE’s 5000+ packages to run on either the armv7hl or armv5tel architectures.
Fedora is also working on their own ARM versions of their software, which Red hat has said are specifically aimed at the server space.
This is not an abandonment of Intel’s business, not by any means—they’ve got their own low-powered chips and systems on a chip that can’t be ignored. But ARM is going to be a presence in server land, and they can’t be brushed aside, either.
The good news, especially for data center and cloud deployment teams, is that all of this competition for low-power server business will be bringing lower power bills and less cooling costs for facilities, and a whole lot of scalability.
Progress with Linux on ARM will make sure apps will run no matter what architecture you decide to use. To share your thoughts on Linux and ARM, check out the tagged section of SUSE Conversations.
In the previous article we took a look at the Texas Instruments OMAP5432 board. This time we will focus on the performance of those A15 cores, the SATA interface, internal flash, and how much difference the hardware video decode makes.
H264 1080p video decode using the video decode hardware on the OMAP5432 required only about 17 percent of one CPU core to decode Big Buck Bunny. Video playback remained fine when the window was resized and other windows overlayed on top of the video playback window. Using Totem to playback instead of a raw gst-launch command line increased the CPU from 17 to 35 percent spikes on one CPU core. Trying to do H264 decode purely in software using mplayer and two cores didn’t work at real-time playback speeds. Hopefully ffmpeg/mplayer will gain support for the video decode hardware of the OMAP5 in the future.
The Octane Javascript benchmark takes advantage of multiple cores of a CPU when available. The top score from past ARM boards in the series is the ODroid-U2, which is a quad core 1.7Ghz ARM Cortex-A9. The OMAP5432 is a dual core ARM Cortex-A15. The board I used was in the early release stage, so instead of running at 1.5Ghz it was only clocked at 800Mhz. That clock restriction is likely to be lifted in September. The ODroid-U2 got 1411 while the OMAP5432 at 800Mhz got 1914 overall. It is interesting how well the slower-clocked, dual core machine did against the quad-core ODroid-U2. For comparison an Intel 2600K desktop CPU got 9667 overall.
A closer comparison of the Octane performance of the OMAP5432 at 800Mhz to the Intel 2600K at it’s stock speed settings is shown below.
The OMAP5432 has 2Gb of RAM and 4Gb of internal flash. Normally bonnie++ wants to create files that are twice the size of the system’s RAM so that disk caching doesn’t interfere with the benchmark. Because the internal flash was only 4Gb I limited the size of files created by bonnie++ with the command shown below. Sequential output was around 11.5Mb/sec and read came in at 496Mb/sec which was obviously heavily cached due to limited file sizes and not a real-world figure. The internal flash could muster 3270 seeks/sec.
bonnie++ -f -m omap5432flash -s 1000 -r 500 -n 0 -d `pwd`
The SATA port on the OMAP5432 was next to be benchmarked. An ext4 filesystem was created with default parameters and mounted with default parameters. The near default bonnie++ command shown below was used to perform the benchmark. I used the 120Gb model of the SanDisk Extreme range of SSD for testing. These drives can be had for around $100. About 66Mb/sec could be written to the SSD and 131Mb/sec read back from it with 8558 seeks/sec performed.
bonnie++ -f -m omapsandisk120 -d `pwd`
To test 2d graphics performance I used version 1.0.1 of the Cairo Performance Demos. There are many individual tests in the Cairo demos: the gears test runs three turning gears, the chart runs four line graphs, the fish is a simulated fish tank with many fish swimming around, gradient is a filled curved edged path what moves around the screen and flowers renders rotating flowers that move up and down the screen. For comparison I used a desktop machine running an Intel 2600K CPU with an NVidia GTX 570 card which drives two screens, one at 2560×1440 and the other at 1080p. I’ve also included the performance of the GK802 running at 1080p and BeagleBone Black running at 720p. Clearly the 2D performance in cairo is currently not seeing any special optimizations on the OMAP5432.
Compiling openssl took around 7.5 minutes on the OMAP5432, about 8.5 minutes on the GK802 quad core Freescale i.MX6 machine, and around 1.5 minutes on an Intel 2600K CPU.
The single core openssl speed test showed similar results for ciphers and digests with the OMAP5432 performing at or below the BeagleBone Black for these single core tests. RSA signature performance of the OMAP5432 was significantly above the Beagle but still well below the ODroid-U2. Even though the OMAP5432 was clocked at 800Mhz it could still perform more than 1/3 more RSA signatures than the 1Ghz BeagleBone Black. At slightly under half the clock rate to the ODroid-U2 (1.7Ghz) the OMAP5432 performed about 2/3 the amount for RSA signatures per second. If the performance scales linearly, when the OMAP5432 is clocked at it’s native 1.5Ghz it should get about 410 on the RSA graph, which is about 25 percent faster than the ODroid-U2.
The OMAP5432 was able to obtain a higher Octane score than the ODroid-U2 even though it has half the number of CPU cores and ran them at a lower clock rate. Video playback in a mainstream player like Totem wasn’t much of a tax on the main cores of the CPU at all. Adding a SATA port to the board allowed seek and read speeds (130+Mb/sec) on a good size disk that can not be achieved through microSD cards. While some expensive microSD cards offer 90Mb/s transfers you might be paying $50 for 16Gb of storage in that form factor and speed. Looking at other A15 boards might provide some insight into the performance of openssl speed testing on that CPU design and how the compile might be optimized for that CPU. We would like to thank SVTronics for the OMAP5432 EVM review hardware.
Read other reviews in this series:
Getting Started With the BeagleBone Black: A 1GHz ARM Linux Machine for $45
BeagleBone Black Part 2: Linux Performance Tests
