Category Archives: Raspberry Pi - Page 2

Node.js Benchmark on Raspberry Pi (v1)

I have experimented a bit with Node.js and Raspberry Pi lately, and I have found the performance… surprisingly bad. So I decided to run some standard tests: benchmark-octane (v9).

Octane is essentially run like:

$ npm install benchmark-octane
$ cd node_modules/benchmark-octane
$ node run.js

The distilled result of Octane is a total run time and a score. Here are a few results:

                         OS             Node.js                   Time    Score
QNAP TS-109 500MHz       Debian        v0.10.29 (Debian)         3350s      N/A
Raspberry Pi v1 700MHz   OpenWrt BB    v0.10.35 (self built)     2267s      140
Raspberry Pi v1 700MHz   Raspbian       v0.6.19 (Raspbian)       2083s      N/A
Raspberry Pi v1 700MHz   Raspbian       v0.12.2 (self built)     2176s      104
Eee701 Celeron 900Mhz    Xubuntu       v0.10.25 (Ubuntu)          171s     1655
Athlon II X2@3Hz         Xubuntu       v0.10.25 (Ubuntu)           49s     9475
MacBook Air i5@1.4Ghz    Mac OS X      v0.10.35 (pkgsrc)           47s    10896
HP 2560p i7@2.7Ghz       Xubuntu       v0.10.25 (Ubuntu)           41s    15450

Score N/A means that one test failed and there was no final score.

When I first saw the RPi performance I thought I had done something wrong building (using a cross compiler) Node.js myself for RPi and OpenWRT. However Node.js with Raspbian is basically not faster, and also RPi ARMv6 with FPU is not much faster than the QNAP ARMv5 without FPU.

I think the Eee701 serves as a good baseline here. At first glance, possible reasons for the RPi underperformance relative to the Celeron are:

  • Smaller cache (16kb of L1 cache and L2 only available to GPU, i Read) compared to Celeron (512k)
  • Bad or not well utilised FPU (but there at least is one on the RPi)
  • Node.js (V8) less optimized for ARM

I found that I have benchmarked those to CPUs against each other before. That time the Celeron was twice as fast as the RPi, and the FPU of the RPi performed decently. Blaming the small cache makes more sense to me, than blaming the people who implemented ARM support in V8.

The conclusion is that Raspberry Pi (v1 at least) is extremely slow running Node.js. Other benchmarks indicate that RPi v2 is significantly faster.

Raspberry Pi (v1), OpenWrt (14.07) and Node.js (v0.10.35 & v0.12.2)

Since I gave up running NetBSD on my Raspberry pi I decided it was time to try OpenWrt. And, to my surprise I also managed to cross compile Node.js!

Install OpenWrt on Raspberry Pi (v1@700MHz)
I installed OpenWrt Barrier Breaker (the currently stable release) using the standard instructions.

After you have put the image on an SD-card with dd, it is quite easy to resize the root partition:

  1. copy the second partition to an image file using dd
  2. use fdisk to delete the second partition, and create a new, bigger
  3. format the new partition with mkfs.ext4
  4. mount the image file using mount -o loop
  5. mount the new second partition
  6. copy all data from image file to second partition using cp -a

If you want to, you can edit /etc/config/network while you are anyway working with the OpenWrt root partition:

#config interface 'lan'
#	option ifname 'eth0'
#	option type 'bridge'
#	option proto 'static'
#	option ipaddr ''
#	option netmask ''
#	option ip6assign '60'
#	option gateway '?.?.?.?'
#	option dns '?.?.?.?'
config interface 'lan'
	option ifname 'eth0'
	option proto 'dhcp'
	option macaddr 'XX:XX:XX:XX:XX:XX'
	option hostname 'rpiopenwrt'

Probably you want to disable dnsmasq, odhcpd and firewall too:

.../etc/init.d/$ chmod -x dnsmasq firewall odhcpd

OR (depending on your idea of what is the right way)

.../etc/rc.d$ sudo rm S60dnsmasq S35odhcpd K85odhcpd S19firewall

Also, it is a good idea to edit config.txt (on the DOS partition):


I don’t know if 1 is really a legal value, but it worked for me, and I had much more memory available than when gpu_mem was not set.

Node.js4 added 2015-10-03
For Node.js, check Node.js 4 builds.

Building Node.js v0.12.2
I downloaded and built Node.js v0.12.2 on a Xubuntu machine with an x64 cpu. On such a machine you can download the standard OpenWrt toolchain for Raspberry Pi.

I replaced configure and in the standard sources with the files from This Page (they are meant for v0.12.1 but they work equally good for v0.12.2).

I then found an a gist that gave me a good start. I modified it, and ended up with:

#!/bin/sh -e

export STAGING_DIR=...path to your toolchain...

export CSTOOLS_INC=${CSTOOLS}/include

export TARGET_ARCH="-march=armv6j"

#Define the cross compilators on your system
export AR="arm-openwrt-linux-uclibcgnueabi-ar"
export CC="arm-openwrt-linux-uclibcgnueabi-gcc"
export CXX="arm-openwrt-linux-uclibcgnueabi-g++"
export LINK="arm-openwrt-linux-uclibcgnueabi-g++"
export CPP="arm-openwrt-linux-uclibcgnueabi-gcc -E"
export LD="arm-openwrt-linux-uclibcgnueabi-ld"
export AS="arm-openwrt-linux-uclibcgnueabi-as"
export CCLD="arm-openwrt-linux-uclibcgnueabi-gcc ${TARGET_ARCH} ${TARGET_TUNE}"
export NM="arm-openwrt-linux-uclibcgnueabi-nm"
export STRIP="arm-openwrt-linux-uclibcgnueabi-strip"
export OBJCOPY="arm-openwrt-linux-uclibcgnueabi-objcopy"
export RANLIB="arm-openwrt-linux-uclibcgnueabi-ranlib"
export F77="arm-openwrt-linux-uclibcgnueabi-g77 ${TARGET_ARCH} ${TARGET_TUNE}"
unset LIBC

#Define flags
export CXXFLAGS="-march=armv6j"
export LDFLAGS="-L${CSTOOLS_LIB} -Wl,-rpath-link,${CSTOOLS_LIB} -Wl,-O1 -Wl,--hash-style=gnu"
export CFLAGS="-isystem${CSTOOLS_INC} -fexpensive-optimizations -frename-registers -fomit-frame-pointer -O2"
export CPPFLAGS="-isystem${CSTOOLS_INC}"
export CCFLAGS="-march=armv6j"

export PATH="${CSTOOLS}/bin:$PATH"

./configure --without-snapshot --dest-cpu=arm --dest-os=linux --without-npm

bash --norc

Run this script in the Node.js source directory. If everything goes fine it configures the Node.js build, and leaves you with a shell where you can simply run:

$ make

If compilation is fine, you find the node binary in the out/Release folder. Copy it to your OpenWrt Raspberry Pi.

Building Node.js v0.10.35
I first successfully built Node.js v0.10.35.

The (less refined) script for configuring that I used was:

#!/bin/sh -e

export STAGING_DIR=...path to your toolchain...

export CSTOOLS_INC=${CSTOOLS}/include
export GYP_DEFINES="armv7=0"

#Define our target device
export TARGET_ARCH="-march=armv6"
export TARGET_TUNE="-mfloat-abi=hard"

#Define the cross compilators on your system
export AR="arm-openwrt-linux-uclibcgnueabi-ar"
export CC="arm-openwrt-linux-uclibcgnueabi-gcc"
export CXX="arm-openwrt-linux-uclibcgnueabi-g++"
export LINK="arm-openwrt-linux-uclibcgnueabi-g++"
export CPP="arm-openwrt-linux-uclibcgnueabi-gcc -E"
export LD="arm-openwrt-linux-uclibcgnueabi-ld"
export AS="arm-openwrt-linux-uclibcgnueabi-as"
export CCLD="arm-openwrt-linux-uclibcgnueabi-gcc ${TARGET_ARCH} ${TARGET_TUNE}"
export NM="arm-openwrt-linux-uclibcgnueabi-nm"
export STRIP="arm-openwrt-linux-uclibcgnueabi-strip"
export OBJCOPY="arm-openwrt-linux-uclibcgnueabi-objcopy"
export RANLIB="arm-openwrt-linux-uclibcgnueabi-ranlib"
export F77="arm-openwrt-linux-uclibcgnueabi-g77 ${TARGET_ARCH} ${TARGET_TUNE}"
unset LIBC

#Define flags
export CXXFLAGS="-march=armv6"
export LDFLAGS="-L${CSTOOLS_LIB} -Wl,-rpath-link,${CSTOOLS_LIB} -Wl,-O1 -Wl,--hash-style=gnu"
export CFLAGS="-isystem${CSTOOLS_INC} -fexpensive-optimizations -frename-registers -fomit-frame-pointer -O2 -ggdb3"
export CPPFLAGS="-isystem${CSTOOLS_INC}"
export CCFLAGS="-march=armv6"

export PATH="${CSTOOLS}/bin:$PATH"

./configure --without-snapshot --dest-cpu=arm --dest-os=linux
bash --norc

Running node on the Raspberry Pi
Back on the Raspberry Pi you need to install a few packages:

# ldd ./node => /lib/ (0xb6f60000) => not found => not found => /lib/ (0xb6f48000) => /lib/ (0xb6f34000) => not found => /lib/ (0xb6edf000) => /lib/ (0xb6f6c000)
# opkg update
# opkg install librt
# opkg install libstdcpp

That is all! Now you should be ready to run node. The node binary is about 13Mb (the v0.10.35 was 19Mb perhaps becuase of -ggdb3), so it is not optimal to deploy it to other typical OpenWrt hardware.

Final comments
I ran a few small programs to test, and they were fine. I guess some more testing would be appropriate. The performance is very comparable to Node.js built and executed on Raspbian.

I think RaspberryPi+OpenWrt+Node.js is a very interesting and competitive combination for microservices!

NetBSD on a Raspberry Pi

Update 2015-12-03:According to a reader comment (below), NetBSD for RPi has matured significantly since I wrote this post. That sounds great to me! But I have not tested yet.

As a long time Linux user I have always had some kind of curiosity about the BSDs, especially NetBSD and its minimalistic approach to system design. For a while I have been thinking that perhaps NetBSD is the perfect operating system for turning a Raspberry Pi into a server.

I have read anti-BSD rants like this “BSD, the truth“, and I have also appreciated pkgsrc for Mac OS X. I felt I needed got get my own opinion. It is easy to have a romantic idea about “Old Real UNIX”, but my limited experience with IRIX and Solaris is not that positive. And BSD is another beast.

For the Raspberry Pi (Version 1, Model B) it is supposed to be possible to run both (stable) NetBSD 6.1.5 and (beta) NetBSD 7.0. It seemed, after all, that the beta 7.0 was the way to go.

At first it was fine

I followed the official instructions and installed NetBSD 7.0. I (first) used the (800MB) rpi.img. I set up my user:

# useradd zo0ok
# mkdir /home
# mkdir /home/zo0ok
# chown zo0ok:users /home/zo0ok
# usermod -G wheel zo0ok

Then it was time to configure pkgsrc and start installing packages.

The Disk Problem
I did a quick check to see how much available space I have, before installing stuff. To my surprise:

# df -h
Filesystem         Size       Used      Avail %Cap Mounted on
/dev/ld0a          650M       623M      -5.4M 100% /
/dev/ld0e           56M        14M        42M  24% /boot
kernfs             1.0K       1.0K         0B 100% /kern
ptyfs              1.0K       1.0K         0B 100% /dev/pts
procfs             8.0K       8.0K         0B 100% /proc
tmpfs              112M       8.0K       112M   0% /var/shm

It seemed like the filesystem had not been (automatically) expanded as it should be according to the instructions above. So i followed the manual instructions to resize my root partition, with no success whatsover.

So I ran disklabel to see if NetBSD recognized my 8GB SD-card…

# /sbin/disklabel ld0
# /dev/rld0c:
type: SCSI
label: fictitious
flags: removable
bytes/sector: 512
sectors/track: 32
tracks/cylinder: 64
sectors/cylinder: 2048
cylinders: 862
total sectors: 1766560
rpm: 3600
interleave: 1
trackskew: 0
cylinderskew: 0
headswitch: 0           # microseconds
track-to-track seek: 0  # microseconds
drivedata: 0 

8 partitions:
#        size    offset     fstype [fsize bsize cpg/sgs]
 a:   1381536    385024     4.2BSD      0     0     0  # (Cyl.    188 -    862*)
 b:    262144    122880       swap                     # (Cyl.     60 -    187)
 c:   1766560         0     unused      0     0        # (Cyl.      0 -    862*)
 d:   1766560         0     unused      0     0        # (Cyl.      0 -    862*)
 e:    114688      8192      MSDOS                     # (Cyl.      4 -     59)

Clearly, NetBSD thought this SD-card was 900MB rather than 8GB, and this is why it failed to automatically resize it.

The sysinst install
I was anyway not very comfortable with getting a preinstalled/preconfigured 800MB system with swap and everything, so I formatted the 8GB SD card with my digital camera (just to be sure the partition table did not contain anything weird), downloaded (6MB) rpi_inst.img and wrote it to the SD card.

NetBSD installation started properly, and I was looking forward to install over SSH. According to the instructions I was supposed to start the DHCP somehow. But DHCP seemed on (the RPi got an IP) but SSH was off, so I installed using keyboard.

Quite immediately I was informed that NetBSD failed to recognise the “disk geometry” properly. I tried the SD card in Linux which reluctantly reported that it had 166 heads and 30 sectors per track (it sounds like nonsense). So I gave this information to the NetBSD sysinst program and now the SD card seemed to be 7.5GB.

Then followed a long and confused period of time when I tried to be smart enough to come up with any working partition scheme that NetBSD could accept. The right procedure was:

  1. Choose entire disk
  2. Confirm to delete the (required) 56MB dos partition
  3. Partition, pretending to be unaware of the need of a dos partition
  4. Magically, in the end, it added the dos partition

I am clearly stupid. There are no words for how confused I am about the a:, c: and e: partitions (that seems to reuse the DOS naming, but for other purposes), the empty space, the disk labels, the BSD partitions inside a (non existing) primary partition.

Anyway, just after I gave up and then gave it a final try I convinced sysinst to install. Then came a phase of choosing download paths, which clearly was non-trivial since I installed a Beta, and I am fine with that.

Installation went on. In the end came a nice menu where I could configure stuff. I liked it! (I wish I knew how to start it later). It managed to get my network settings from DHCP (except the GW), but it failed to configure and test the network itself (despite it had downloaded everything over the network just a few minutes ago). I configured a few other things, I restarted, network was working and I was happy… for a while.

I configured pkgsrc, and it seems ALL other systems where pkgsrc exist have been blessed with the pkgin tool, except NetBSD where you are supposed to do all the job yourself. Well, I added the PKG_PATH to the .shrc (of my user, not root) and enjoyed pkg_add.

(not) Compiling NodeJS
I want to install node.js on my NetBSD Raspberry Pi. It is not in pkgsrc (which is it for Mac OS X, but whatever) so I had to build it myself. I am used to building node.js and I was looking forward to fix all the broken dependencies. If I had ever gotten there.

I downloaded the source and started unpacking it… it is about 10000 files and 100MB of data. My SD card (a SanDisk Ultra, class 10) is not super fast, dd-ing the image to it earlier wrote at a speed of 3MB/s. The unpacking speed of node.js; roughly 1 file per second. I realised I need a (fast) USB-drive or a faster SD card, so I (literally) went out to town, bought a fast USB drive (did not find the SD card I wanted) and a few other things. When I came back more than 8000 files had been extracted and less than 2000 remained. I started reading about how to partition and format a USB drive for NetBSD, and at some point I inserted it in the Raspberry Pi. A little later I noticed my ssh sessions were dead, and the RPi had restarted. It turns out what reality was worse than the truth in “BSD, the truth”:

[…] the kernels of the BSDs are also very fault intolerant.

The best example of this is the issue with removing USBs. The problem appears when USBs are removed without unmounting them first. The result is a kernel panic. The astounding aspect of this is that this problem has been exhibited by all the major BSD variants Free, Open, Net and DragonflyBSD ever since USB support was implemented in them 5 to 6 years ago and has never ever been fixed. FreeBSD mailing lists even ban people who dare mention about it. In Linux, such things never and happen and bugs as serious as this gets fixed before a release is made.

Fact is, NetBSD 7.0 Beta for RPi, crashes, immediately, when I insert a USB drive.

This actually did not make me give up. I really restarted the system with the USB drive inserted, with the intention of treating my USB drive as a fixed disk and not inserting/removing it unless I shut the RPi down first. This was when I did give up: deleting the 16GB dos partition and creating a NetBSD filesystem was just too difficult for me. Admittedly, my patience was running out.

More on memory card performance
I found this very interesting article (linked to, by the Gentoo people, of course). Without going into details; clearly a Raspberry Pi with an SD card root filesystem needs a filesystem and block device implementation that works well with actual SD cards. This is not trivial and this means doing things very differently from rotating media.

I did the same unpacking of the node.js source on Raspbian (I installed Raspbian on exactly the same SD card as I used for NetBSD): 22 seconds (tar: 18s, sync 4s), compared to 3h for NetBSD.

In theory, NetBSD would be a beautiful fit for the Raspberry Pi. The ARMv6 is not supported by standard Debian. Raspbian comes with a little “too much” for my taste (it is not a real problem), and it does not have the feeling of “Debian stable”, but more some “inoffical Debian test” (sorry Raspbian people – I really appreciate your job!).

I have wondered why Noobs does not come with NetBSD… but I think I know now. And, sometimes I am surpised that Linux seems to work better than Mac OS X, perhaps now I know why.

My romantic idea that NetBSD would be perfect for the RPI was just plain wrong. Installing NetBSD today made me remember installing Slackware on a Compaq laptop in 1998.

Perhaps I will give Arch a try. Or put OpenWRT on the RPi.

Owncloud client on Raspbian

I found that Raspbian comes with a very old version (1.2 something) of the Owncloud client. I found no prebuilt more up to date versions, so I built one myself:

$ sudo apt-get install cmake qt4-dev-tools build-essential
$ sudo apt-get install libneon27 libneon27-dev qtkeychain-dev
$ sudo apt-get install sqlite3 libsqlite3-dev libsqlite3-0
$ tar -xjf mirall-1.6.1rc1.tar.bz2
$ mkdir mirall-build
$ cd mirall-build/
$ cmake ../mirall-1.6.1rc1

The owncloud client is now in the bin folder.

Note: I took the commands above from my history, so there is a slight risk of a mistake. Also, I might have installed other packages before, that I am not aware of are not required for owncloud. Feel free to give feedback!

It is quite useful to put a Raspberry Pi with a USB-drive in someone elses home, and let it syncronize your files. That way, you have an off-site backup for worst case scenarios.

Installing Citrix Receiver on Raspberry Pi (Raspbian)

Update 20150222:The new RPi2 has an ARMv7 processor. It should run standard officially supported Citrix Receivers. I have not tested this myself.

It is obviously tempting to try to use a Raspberry Pi as a thin client. Often, that means a Citrix client, that requires Citrix Receiver (a closed source program available from Citrix in binary form only).

The problem
Raspbian is very much a normal Debian system. Citrix Receiver usually works nicely on Debian, and Citrix provides ARM binaries. But that would be too easy.

There are two ARM binaries available from Citrix (Receiver 13.0, the current)

  1. ARMEL – for ARM cpus without floating point support
  2. ARMHF – for ARM cpus with floating point support AND at least ARMv7

The Raspberry Pi is based on an ARMv6 WITH floating point support. This means that the ARMHF binary can never run, since ARMv6 lacks instructions required by ARMv7. But it also means that the ARMEL version can not run on Raspbian (although it could work on a Raspberry Pi with another OS).

There are different strategies to this problem: fixing the OS, or fixing the Citrix client.

RPi Thin Client Project
There is a nice effort called RPi Thin Client Project. The version from 2013-11-28 runs everything in ARMEL (without Hardware Float). The good thing is that it actually runs Citrix Receiver on a Raspberry Pi, and the performance of the Receiver itself is quite decent. However, it is based on Debian Unstable, and as I started updating and installing packages it did not work very well. Also, the RPi is not very fast even with Hard Float working, and without Hard Float everything except the Citrix client is very slow.

I see there is now a new Hard Float release of the RPi Thin Client project (2014-06-10), but as far as I can see it does not include Citrix Receiver (feel free to correct or update me!).

Unofficial Citrix Client
On a blog hosted by Citrix, there is an unofficial Citrix Receiver available for download. Obviously Muhammad Dawood has access to the real Receiver source code and he is allowed to compile it and distribute unofficial binaries. If you follow his instructions (install Raspbian as usual, then install Citrix Receiver with his special setup-script) you will get a Hard Float Citrix Receiver on a normal Raspbian system. Very nice! I am running it and it works very well, and I am much looking forward to an official/supported version.

The setup script modifies /boot/config.txt, mostly to overclock the RPi to maximize performance. My RPi did not accept it and refused to start. The good thing is that you can remove the SD card from the RPi and edit the config file with another computer. I only have ONE active line in my /boot/config.txt:


…and you can probably change/remove that line too. I have an old 1280×1024
LCD display, that I connect via an Apple HDMI->DVI adapter, and a DVI-DVI cable. The display is comes up at correct resolution (although lxrandr can not run).

Other ideas
I was thinking about decompiling/recompiling one of the official ARM binaries. After reading a bit about it I gave up without thinking about trying. It probably violates any license agreement too.

Perhaps it could be possible to run some official binary (ARMEL, ARMHF or even x86) using QEMU user mode. Probably the performance would be completely unacceptable.

On Raspbian pages I read that theoretically it is possible to run ARMEL applications on Raspbian using Linux/Debian multi-arch, but there seems to be some hacks made in Raspbian, and this multi-arch probably practically unrealistic.

I recommend go with the inofficial/unsupported binaries from Citrix for now. Lets hope Citrix embraces this some day.

Raspberry Pi findings

I have had the opportunity to play around a bit with a Raspberry Pi lately. Here follows a few findings that perhaps can be helpful to someone.

Composite Video
The Raspberry Pi supports Composite Video. I failed to make the installer display anything at all using Composite Video, for Rasbian and Noobs. With Noobs, I know that it started and did something (becuase the SD card partitions were changed), but I dont know exactly what. With Rasbian, I dont know if I just failed to produce a bootable SD card.

Raspbmc worked perfectly over Composite Video though! So even if Raspbmc was not my first choice, it ended up being what I first played on with.

HDMI Video
I tried the Raspberry Pi Thin Client Project. Works perfectly on HDMI->DVI@1600×1200. So I guess most DVI displays can work fine with an HDMI->DVI-cable.


  • You can disable XMBC editing startup conditions in /etc/init/xbmc.conf
  • Raspbmc comes with a firewall setting that blocks incoming traffic from outside its own subnet. You can fix this with iptables -F, or for more persistant change, edit /etc/???
  • Static IP is easiest configured via XBMC… /etc/network/interfaces does not seem to work properly, but perhaps my mistake

Raspberry Pi Think Client Project
Where I work, the Citrix Receiver (12.2.3) that comes with RPi-TC, does not work. Applications crashes (The X Request 62.0 caused error:…) quickly. However, I installed 13.0 from Citrix, and opened the Citrix Applications via the web browser – that works fine. But wfcmgr seems missing from 13.0 – I havnt found out what replaces it.

RPi-TC is slow – at the point of being unusuable for anything real. Except for the Citrix client and Remoted desktop client – those work quite fine, and that was the point anyway! Iceweasel is slow. I thought about installing Chromium, but no immediate success with that. Perhaps it is my memory card that is slow.

Noobs / Raspbian
When creating a memory card for Noobs in Linux:

  • fdisk: create one big partition with partition type “c”
  • mkfs.vfat: no need to use any arguments/flags except /dev/mmcblk0p1 (or whatever is your memory card)

With an HDMI cable Noobs and Raspbian works well. Now that I have seen Noobs that is what I recommend anyone to try first. And Raspbian seems fine.

For use as a desktop computer, the Raspberry Pi is in need of an accelerated X server – which will come, perhaps not in the form of an X server at all, but Wayland/Weston. You can try Weston in the latest/current Raspbian, but you can only run a terminal application (unless I have failed to understand something here). It looks very promising, but not useful for anything real at the moment. There is an fb-turbo-Xserver that is now standard, and it is a bit better than the old fb-Xserver that I used when this post was originally written.