Last time around we took a look at the new $45 Beagle Bone Black (BBB) board which has a 1GHz ARM Cortex-A8 CPU with 512Mb of RAM and 2Gb of eMMC flash memory. This time we’ll see how fast that little machine is.
First, to the eMMC flash. This 2Gb of storage is one of the differences between the BBB and the Raspberry Pi machine. Bonnie wants to create files which are twice the size of the available memory on the system to avoid disk caches from interfering with the benchmark. Unfortunately, the BBB has 512Mb of RAM and with a default Angstrom installation. I only had about 500Mb of free space on the eMMC. So I had to use the second set of parameters to force files only up to 200Mb in size to be created.
user@bbb:~/test$ /sbin/bonnie++ -f -m bbb-emmc -d `pwd` Writing intelligently...Can't write block. Bonnie: drastic I/O error (write(2)): No such file or directory user@bbb:~/test$ /sbin/bonnie++ -f -m bbb-emmc -s 200 -r 100 -d `pwd`
Sequential output was about 4.2Mb/s, rewrite at about 4.5Mb/s, and sequential input at 206Mb/s. The input figure is very likely to be incorrect because the entire file could be cached in memory. For comparison, the ODroid-U2 quad core ARM machinegot around 16Mb/s for sequential output and 12Mb/s for rewrite on it’s eMMC flash. Random create and delete on the BBB came to 10k and 6k files/s respectively. This was on an ext4 filesystem using the mount options: rw,relatime,data=ordered.
Openssl speed test
I compiled openssl 1.0.1e on the BBB which took 21.5 minutes to complete. The ODroid-U2 quad core ARM can compile the same code in 4 minutes using all of its cores and a desktop Intel 2600K in slightly less than 1 minute. Unfortunately I was using different versions of gcc on both platforms.
BBB: gcc version 4.7.3 20130205 (prerelease) (Linaro GCC 4.7-2013.02-01) ODroid-U2: gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 Fedora-18: gcc (GCC) 4.7.2 20121109 (Red Hat 4.7.2-8)
The openssl speed test only uses a single core on a machine. This doesn’t matter for the BBB, but on the ODroid-U2 there were three cores effectively going to waste during the test. Comparing the BBB to the ODroid-U2 openssl speed benchmarks we can see a range of 50 to 75 percent the speed of one core.
77% 1024 byte aes-256 cbc 73% 1024 byte md5 67% 1024 byte sha1 50% 1024 bit RSA sign 52% 1024 bit RSA verify
2d graphics and Web browsing tests
To test 2d graphics performance I used version 1.0.1 of the Cairo Performance 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.
BBB fps desktop 2600k/nv570
at 720p two screns.
gears 26 140
chart 2 16
fish 4 188
gradient 10 117
flowers 1 170
For testing Web browsing performance, I used Firefox on both machines and ran the Octane Javascript benchmark. The Intel 2600K sets the top performance as expected with 9667 overall. Next up the ODroid-U2 came in at 1411 and the BBB at 367 which is 26 percent the performance of ODroid-U2. For most of the individual tests the BBB was 30 percent the speed of the ODroid-U2. Exceptions such as EarleyBoyer, NavierStokes, and Raytrace saw the BBB back in the 13 to 14 percent the performance of the ODroid-U2.
Tinkering with ports
The Beagle Bone Black is a great little machine for anyone who wants to tinker with hardware. The collection of ports on offer to connect with other hardware is wonderful and you get to interface with the hardware you are tinkering with from a full Linux system. Having a full Linux system running the show means you can hook up very cheap small LCD screens and make them available as a normal frame buffer. Or run cron jobs to prod some hardware at intervals of your choosing, saving images or collected data right to the BBB eMMC and making it available over the Web.
Using some cheap LCD panels might take a bit more tinkering to get going with the BBB than on Arduino. Using a LCD from Arduino usually involves including a library to drive that hardware and compiling a program to upload to the Arduino. Your program uses whatever API the library that drives the LCD offers to show information. On the other hand, for Linux you might want the kernel itself to expose the screen as a normal frame buffer which might require you to recompile your kernel and possibly merge patches into your kernel source.
However on the BBB once you have the framebuffer setup, all of the lower level details like communicating over the Serial Peripheral Interface Bus (SPI) bus are abstracted from your application. You can then concentrate on making your Qt/QML, EFL, GTK, or Cairo application. As long as your application targets the resolution of your chosen display there shouldn’t be much porting of the user interface code from a Desktop Linux display to the LCD display which runs over SPI on the BBB.
