Using the Fedora ARM remix on the raspberry Pi, I couldn’t help but noticing how slow it was. I thought it was due to the Pi’s weak hardware, but since I accidentally corrupted my root filesystem on the Pi, I decided to try Raspbian for a change.
I was surprised to discover Raspbian seems way more responsive and, well, faster than Fedora, so I decided to investigate.
In this post I will benchmark Raspbian and Fedora ARM Raspberry Pi Remix using various benchmarking suits. The setup is a single Raspberry Pi (not overclocked), a class 10 SD card for the root filesystem, with the 240MB memory split (240MB for RAM, all the rest for the GPU that I don’t use).
The first benchmark: sysbench CPU benchmark
On Raspbian:
sysbench 0.4.12: multi-threaded system evaluation benchmark Running the test with following options: Number of threads: 1 Doing CPU performance benchmark Threads started! Done. Maximum prime number checked in CPU test: 10000 Test execution summary: total time: 498.8142s total number of events: 10000 total time taken by event execution: 498.7676 per-request statistics: min: 49.70ms avg: 49.88ms max: 74.58ms approx. 95 percentile: 50.81ms Threads fairness: events (avg/stddev): 10000.0000/0.00 execution time (avg/stddev): 498.7676/0.00
on Fedora:
sysbench 0.4.12: multi-threaded system evaluation benchmark Running the test with following options: Number of threads: 1 Doing CPU performance benchmark Threads started! Done. Maximum prime number checked in CPU test: 10000 Test execution summary: total time: 869.8395s total number of events: 10000 total time taken by event execution: 869.7930 per-request statistics: min: 86.74ms avg: 86.98ms max: 205.24ms approx. 95 percentile: 86.91ms Threads fairness: events (avg/stddev): 10000.0000/0.00 execution time (avg/stddev): 869.7930/0.00
Second benchmark: extracting the linux kernel mainline source code archive with tar and bzip2.
On Raspbian:
pi@raspberrypi ~ $ time tar -xf linux-3.6-rc7.tar.bz2 real 5m49.174s user 4m13.450s sys 0m40.020s
On Fedora:
[elad@raspi ~]$ time tar -xf linux-3.6-rc7.tar.bz2 real 8m25.091s user 4m25.350s sys 0m50.400s
Third benchmark: writing 500MB of random data to the SD card using dd. I do not expect any major difference here, but testing anyway doesn’t harm anyone.
On Raspbian:
pi@raspberrypi ~ $ time dd if=/dev/urandom bs=1M count=500 of=somefile 500+0 records in 500+0 records out 524288000 bytes (524 MB) copied, 466.911 s, 1.1 MB/s real 7m46.929s user 0m0.000s sys 7m29.870s
On Fedora:
[elad@raspi ~]$ time dd if=/dev/urandom bs=1M count=500 of=somefile 500+0 records in 500+0 records out 524288000 bytes (524 MB) copied, 482.279 s, 1.1 MB/s real 8m2.334s user 0m0.000s sys 7m52.840s
And now for some graphs: I have run PyBench and the Apache benchmark using the phoronix-test-suit.
I wonder why the test suite running on Fedora sees only 229MB of RAM while the test suite running on Raspbian sees 232MB…
Let’s take a look at the results:
On PyBench, Raspbian seems to be 1.37x faster
Again, Raspbian seems to be 1.25x faster.
Well, I don’t know much about ARM, but it seems to me Raspbian is just more optimized for the Pi, which is bad for me because I feel more at home managing a Fedora machine and not a Debian machine.
There is a reason for this, and it is exactly what you expect:
Raspbian is built as armv6 hard float, which is the ideal optimization for the Raspberry Pi hardware (and not much else). The current Raspberry Pi Remix builds use the existing Fedora armv5 soft float code, hence, not as fast!
The good news is that I think that the team working on the Raspberry Pi Fedora Remix are doing a rebuild of all the packages for armv6 hard float. I have no idea what the status is on that, but you might be able to get more details if you ask in #fedora-arm.
Yeah, I’ve suspected that is the reason, but Peter Robinson asked me to show performance data, so I did.
I’m not sure if the team is working on rebuilding all the packages for armv6, haven’t seen anything about it on the mailing list.
Along that line, I figure it would be useful to compare it to a Debian armel intallation.
Try:
debootstrap –arch=armel sid chroot-dir
and then chroot into that directory (bind-mount needd directories) and re-run tests. I figure it would be comparable to that Fedora build.
im just guessing here – it might be due to fedora compiling their binaries (and probably kernel too) to ARMv5 which used to be the default ARM cpu target, while your PI should be ARMv7 (and above) to use the NEON extension, THUMBv2, etc, which enhances the ARM cpu computing powers.
You can check it yourself, and if so, maybe fork Fedora for more advanced CPUs
After all, its just a matter of compiling the all damn repositories :p
Is fedora arm compile for hard float?
http://www.memetic.org/raspbian-benchmarking-armel-vs-armhf/
there are been some other optimisations in recent raspbian
http://www.raspberrypi.org/archives/2008
1) When extracting the kernel – do it several times in order for the file to be in Linux’s cache. Measure several times (3-5).
2) Don’t use /dev/random , instead use /dev/urandom: The difference is that when there is not enough entropy, random waits for it to be generated, and urandom returns a pseudo random number.
Also a good idea to remove disk IO, dd if=/dev/urandom of=/dev/null… This should be interesting (is the IO part of the kernel borked in Fedora…? or other optimizations…?)
3) Note that you are using different kernels… maybe that is the issue…? (I understand it’s hard to change the kernel on those things…)
4) Give links to the test applications please
Good job!
1) Noted
2) I have used /dev/urandom
3) not really, see Tom’s comment
4) sysbench was installed from the repositories (yum install sysbench and apt-get install sysbench). Phoronix test suite was downloaded from the upstream website at http://www.phoronix-test-suite.com/