Getting started with Snappy Ubuntu Core on the Raspberry Pi 2

[UPDATE: Note that the version of Snappy described in this post is now obsolete – I have a new post describing a newer version which works better, and slightly differently.]

This post consists of a few notes which may be helpful for people trying to get started with Snappy Ubuntu Core on the new Raspberry Pi 2. First of all note that Ubuntu requires ARM7 so it won’t run on any model of Raspberry Pi prior to the Raspberry Pi 2 (model B), released February 2015.

The Ubuntu Core image can be downloaded from the Raspberry Pi downloads page, and written to uSD card in the usual way, just as you would a Raspbian image. From my Ubuntu laptop, I use a command like:

% sudo dd bs=1M if=pi-snappy.img of=/dev/mmcblk0

Be very careful to get the device name correct for of, as this command will completely trash the output device.

Once you have an image on a uSD card, you can insert it into your Pi 2 and boot it up as usual. If you have a keyboard and display hooked up you can log in on the console, but note that Ubuntu Core can be used headless from first boot via ssh. The default username and password are both ubuntu. I ssh in to my device with a command like ssh ubuntu@raspi08.home. Ubuntu Core uses the new containerised “snappy” system for managing packages, so “apt” doesn’t work. To get an idea of how snappy works, you can read through the snappy tour from Canonical, but note that much of this tour won’t actually work on the Pi 2 right now. Here’s a console session:

ubuntu@localhost:~$ snappy info
release: ubuntu-core/devel
ubuntu@localhost:~$ snappy versions
Part         Tag   Installed  Available  Fingerprint     Active  
ubuntu-core  edge  2          -          f442b1d8d6db3f  *              
This command needs root, please run with sudo
ubuntu@localhost:~$ snappy search docker
No matching packages found: docker

You will note that Docker isn’t currently available for Ubuntu Core on the Pi 2, though hopefully that will change soon. However, at the time of writing you may also find that the final command bombs with a certificate error. This turns out to be due to the fact that the system time is incorrect. You can verify this by running date. You can manually set it with a command like

sudo date -s "Sat Feb  7 09:57:32 GMT 2015"

where you paste in the output from running date on a system which does have the correct time. You can also automate this by instead using a command like

sudo date -s "`ssh username@linuxserver date`"

where username and linuxserver are replaced appropriately. At the time of writing there are very few Snappy packages available, but one useful package is webdm. You can search for it with snappy search webdm and install it with

sudo snappy install webdm

Running snappy info will confirm that it has installed correctly. This runs a web based package manager on port 4200, so, for example, I can connect to this from a web browser on the local network using the URL http://raspi08.home:4200/. This allows the browsing of available frameworks and apps.

There currently isn’t any app or framework for Java, but manually downloading and installing Oracle’s JDK8 for ARM works fine, and runs code at the same speed as using the JVM which ships with Raspbian. It would be very easy to package up the JDK8 as a Snappy app or framework, but I guess that there are licensing issues, so I’ll leave that to others to sort out! You can find out more about how Snappy works by reading Canonical’s snappy guides.

I quite like the Snappy system, and running Ubuntu Core on a Pi 2 is potentially a great way to learn about Cloud computing in a very cheap, simple and safe way. However, we need a few key apps and frameworks before it will become genuinely useful. Ubuntu Core certainly isn’t about to replace Raspbian as the main OS for the Raspberry Pi 2 any time soon.


Benchmarking MCMC codes on the Raspberry Pi 2


In the previous post I looked at running some MCMC codes in C and Scala on the Parallella. In that post I explained how the Parallella was significantly faster than the Raspberry Pi, and how it represented better “bang for buck” than the Raspberry Pi for computationally intensive MCMC codes. However, since that post was written, the Raspberry Pi 2 has been released. This board has a much better processor than the old Pi, and double the RAM, for the same price. This changes things, considerably. The processor is an ARM7 quad core. Each core is around twice as fast as the single core on the original Pi, and there are 4 of them. In this post I will re-run the codes from the previous post and compare against the Parallella.

Gibbs sampler in C

I’m using the new Raspbian image for the Pi 2. This includes gcc by default, but not the GSL library. This can be installed with sudo apt-get install libgsl0-dev. Then the file gibbs.c from the previous post will compile and run. On the Pi 2 this runs in around 75 seconds – very similar to the time on the Parallella, and around twice as fast as all of the previous Raspberry Pis.

Gibbs sampler in Scala

The Raspbian image ships with Oracle’s fast and efficient ARM-optimised JVM by default, so there’s no issue with installing Java at all. As usual, installing “sbt” is a simple matter of copying the launcher script (and jar) into your ~/bin directory. Then the Scala version of the Gibbs sampler can be run with a command like time sbt run > /dev/null. Again, it runs in around 4 minutes 40 seconds, just like on the Parallella. So, the ARM cores on the Parallella and the Pi 2 have very similar performance. However, the Parallella ARM chip has just two cores, whereas the Pi 2 is quad core.

Parallel Monte Carlo in Scala

Again, as for the previous post, I next ran the Monte Carlo example from this github repo. This gives output like:

$ sbt run
[info] Set current project to monte-carlo (in build file:/home/pi/src/git/statslang-scala/monte-carlo/)
[info] Running MonteCarlo 
Running with 1000000 iterations
Idiomatic vectorised solution
time: 6768.504487ms
Fast efficient (serial) tail call
time: 2473.331672ms
Parallelised version
time: 1391.2828ms

Here again we see that the single threaded versions run in a similar time to the Parallella (and around twice as fast as the old Pis), but that the parallelised version runs significantly faster on the Pi 2 than on the Parallella (due to having 4 ARM cores rather than 2).


For my test MCMC codes, the cores on the Pi 2 are around twice as fast as the single core on the old Raspberry Pis, and a similar speed to the cores on the Parallella. However, multi-threaded codes run faster still, due to there being 4 cores on the Pi 2 (versus 2 on the Parallella and one on the old Pis). Furthermore, the Pi 2 is the same price as the old Pis (which are still being sold), and around a quarter of the price of the cheapest Parallella. So for standard single and multi-threaded codes running on the ARM cores, the Pi 2 wins hands down in terms of “bang for buck”, and is sufficiently quick and cheap that it starts looking like a credible platform for building cheap clusters for compute-intensive jobs like MCMC. Now to be fair to the Parallella, really the whole point of it is that it has a multi-core Epiphany co-processor that I’ve not been using or factoring in to the discussion at all so far. That said, the Pi 2 is so much cheaper than the Parallella (not to mention, less “fragile”), that I suspect that even for codes which effectively exploit the Epiphany chip it is unlikely that the Parallella will outperform the Pi 2 in terms of “bang for buck”. Now “bang per watt” is another matter entirely, and the Parallella may well outperform the Pi 2 in that regard if efficient use can be made of the Epiphany chip. But development time costs money too, and it’s really not clear that it’s going to be easy for me to run my multi-threaded Scala codes effectively on the Epiphany chip any time soon. So the Pi 2 currently looks like a real winner from my personal perspective.

Setting up a Minecraft server on a Raspberry Pi

I’ve recently set up a Minecraft server on a Raspberry Pi. There’s lots of information on line describing how to do this, but I still had some problems, in part due to a lot of information on-line being out-of-date, in part due to the fact that running a Minecraft server is right on the limit of what a Pi is capable of, and in part due to the fact that I don’t really know much about Minecraft…

Just to be clear, this is about running a Minecraft SERVER, not the game client. The game client doesn’t work well on the Pi, as it doesn’t have enough memory. There is a special game client for the Pi, the Minecraft Raspberry Pi Edition, which is free, and programmable, but is creative mode only, and has no monsters. That is not what this post is about. You can run a server on the Pi (for free) which you can use from a standard game client (which is not free). That is what this post is about.

Useful on-line information I found useful includes the Gamepedia tutorial, this Forum thread, and this how-to-geek article. It is worth having a quick read through these before continuing.

It is important to understand that there are lots of different Minecraft servers out there, most of which are Java based, but not all. There are potential advantages to not using the standard vanilla Mojang reference server, as some servers are lighter weight, and hence could potentially run better on the Pi. However, lots of servers “out there” are not compatible with the latest (1.7.x) versions of the game client, so it’s probably best to get the vanilla server up and running first, before exploring other possibilities. Note that I’m assuming a Revision 2 Model B Pi with 512MB RAM. I don’t imagine that you will have a good experience with 256MB RAM. You should use raspi-config to allocate as little RAM as possible to the GPU, and you should overclock the Pi as much as you dare.

The Mojang server is a Java server, so you need a fast JVM installed on the Pi. The OpenJDK JVM is too slow – you need the Oracle JVM. Lot’s of info on the web refers to Oracle’s developer preview of Java 8, but that isn’t necessary now, as Oracle’s Java 7 is now a standard part of Raspbian. So just install that:

sudo apt-get update
sudo apt-get install oracle-java7-jdk

Use java -version to make sure it has worked. Then just pull the server jar, stick it into an appropriately named directory, and run the server from that directory with a command like:

java -Xms256M -Xmx384M -jar minecraft_server.1.7.2.jar nogui

The first time you run this it will take an age (possibly up to half an hour). Subsequent starts will be much quicker (15 seconds). Once it is up and running, try connecting to the address/name of the Pi from the machine you usually use for running the Minecraft game client. If the connection fails due to a protocol error, this usually means that the server is too old to cope with the latest version of the game client, so you need to find a new server. If it fails due to a timeout, then it means that your Pi isn’t running fast enough. Tweak settings. Overclock more, etc. There are various settings in the “server-properties” file that you can tweak to improve the speed at which the server runs. Disabling “nether” and dropping the view distance down (to, say, 5) seem to be particularly effective. Again, you can find out more about this by googling around. My current server-properties looks like this:

#Minecraft server properties
#Sat Nov 30 14:23:39 UTC 2013
motd=Pi server

If you’ve never set up a server before and are having trouble, it may be easier to set things up on another machine and then copy things across to the Pi when you get it working. I actually got mine up and running on a fast Ubuntu laptop first, which saved a lot of time.

I’m still running the Mojang server. It’s generally fine, but gives lots of warnings about “Not keeping up”, and riding horses doesn’t really work very well. If anyone has suggestions for another server that will work as a swap-in replacement and run better on the Pi, please do leave a comment. I’d be interested in something that runs a bit faster, and copes better with riding horses, smashing blocks, etc. But my kids will not be pleased if they have to re-build their world…