CubieTruck Perl performance

23.01.2014 22:57

Two months ago I bought a CubieTruck, one of the many cheap, bare-bone ARM-based computers that keep popping-up everywhere these days. My idea was to replace the aging x86 server that is running this website with something more power-efficient. So I was looking for a reasonably powerful board with a proper SATA interface and a decent amount of RAM. Raspberry Pi was out of the question, but the latest incarnation of CubieBoard with a dual-core 1 GHz ARM Cortex-A7, 2 GB of RAM, SATA 2.0 and Gigabit Ethernet seemed to fit the bill.

Unfortunately I could not find any reliable benchmarks I could use to estimate how ARM SoCs perform in comparison with my existing setup. So before I decided to migrate I took a while to do some performance tests and get to know this hardware.


The software setup I'm interested in benchmarking is somewhat archaic in these days of Node.js and NoSQL. I'm using Perl 5 with HTML::Template doing most of the heavy lifting (at least according to Devel::NYTProf profiler). Most parts are statically generated and some are dynamic using a handful of SpeedyCGI Perl 5 scripts. These are combined into a consistent website you see here with a somewhat convoluted Apache configuration using the threaded worker.

In the following benchmarks I'm comparing:

  • An AMD Duron at 700 MHz, 1.2 GB RAM running stock x86 Debian Squeeze. Root filesystem is mounted from an IDE hard drive.
  • A CubieTruck A20 running armhf Debian Wheezy and the kernel supplied for the CubieTruck Ubuntu Server installation. Root filesystem is mounted from an SD card.

Both machines were connected through a 100 Mb/s Ethernet switch to a laptop which was running the remote end of the benchmarks.

First, to see how fast the static part of the web site is generated, I ran the full (single threaded) HTML rebuild. I measured the required user space CPU time with the time utility. This is the fastest run of three on each machine:

AMD Duron CubieTruck
CPU time to rebuild static pages 45.3 s 61.8 s

Then, to check if network was operating at the bit rate I thought it was, I ran iperf to measure TCP throughput between the server and the laptop:

AMD Duron CubieTruck
iperf throughput test 94.0 Mb/s 94.5 Mb/s

Finally, I ran a suite of tests using the Apache benchmarking tool. I measured how many requests per minute a server can handle for different types of content and different number of concurrent requests. Numbers in parentheses show size of HTTP body (without headers).

CubieTruck requests per second for a static HTML page.

CubieTruck requests per second for a dynamic HTML page.

CubieTruck requests per second for an image.

CubieTruck requests per second for API call.

The site rebuild is somewhat disappointingly almost one-third slower than on a 10 year old PC. However the single threaded Apache performance is on par with it. In the case of more concurrent users the CubieTruck of course has an advantage because of an additional CPU core. Actually in both cases with static content CubieTruck managed to saturate the line when there was more than one concurrent request.

I tried to make these tests in a way that the slow SD card in the CubieTruck would minimally affect their outcome. All of data should fit into the buffer cache, which is why in the first test I only took into account the fastest run and only user space CPU time. However I now suspect that the SD card still affected the numbers somehow (the rebuild operation is the heaviest of the tests regarding filesystem I/O). I don't know for sure how kernel computes the time returned by the time utility.

These results are good enough that I can't dismiss CubieTruck based on performance. If a proper SATA drive wouldn't speed it up, I could probably parallelize the build process with not much work. That should cut down on time if it's really Perl performance on ARM that is slowing it down. On the other hand I'm having some other concerns about using CubieTruck as a personal server so I'm not completely decided yet about putting it on my rack.

Posted by Tomaž | Categories: Digital | Comments »

Moving a SSL certificate to a hardware token

05.01.2014 21:35

This is how you move a client side SSL certificate from Firefox to a hardware cryptographic token. It's something I do just rarely enough so that I have to look it up every time. And due to the chaotic nature of OpenSC documentation it's not easy to find all the steps. Here is a quick guide for future reference:

This assumes that OpenSC is already installed on the system and working correctly. I'm using a Schlumberger Cryptoflex USB token.

Cryptoflex works with 2048 bit RSA keys. I haven't tried larger ones.

First export the private key and certificate to a PKCS #12 file: Edit → Preferences → Advanced → Certificates → View Certificates → Your Certificates → Backup.

You can verify that it worked by:

$ openssl pkcs12 -in file.p12

Now insert the USB token or a smart card into the reader. You can inspect existing contents by:

$ pkcs15-tool -D

The Cryptoflex 32K doesn't seem to have enough memory for two key pairs, so you have to delete any existing content before uploading a new certificate. It might be possible to just delete individual files from the token, but I couldn't figure it out, so I just erase the whole device and setup everything from scratch.

First erase the token and setup the PKCS #15 structure on it. The default transport key offered by OpenSC works.

$ pkcs15-init --erase-card
$ pkcs15-init --create-pkcs15

Create a PIN and PUK entries on the token:

$ pkcs15-init --store-pin --auth-id 1 --label "My PIN"

Now upload the key you exported from Firefox to the token and protect it with the PIN you entered previously:

$ pkcs15-init -S file.p12 -f PKCS12 --auth-id 1

Verify that it has been written to the token correctly using pkcs15-tool -D. You can now remove the certificate from Firefox' software storage. You can do that from the certificate manager. You have to remove the token from the system first, because the Firefox' UI hides certificates in software storage if a hardware token is present.

Make sure you keep a safe backup of the file.p12 (and remember the passphrase). It should be impossible to retrieve the private key back from the hardware token so this is now your only way to recover it in case you want to move it to a new device in the future.

Some more background info is available on the old OpenSC wiki. It's not linked from anywhere right now because supposedly they have a new wiki, but a lot of documentation didn't make it there yet.

Posted by Tomaž | Categories: Code | Comments »

On forgetting passphrases

01.01.2014 19:57

If you're using encryption to protect your mail and personal files you might find this lesson useful. This goes double if you are (like me) trying religiously to avoid any holes or bit rot in your personal project archive. The gist of it is that you will sooner or later forget a password or a passphrase that you are not actively using.

Consider the case of changing your expired GPG key. If you forget the passphrase for the expired GPG key, you will lose access to your old encrypted mail. It seems obvious in hindsight, but I only realized that after finding out that after a few months of disuse I am unable to recall the old passphrase. I had to say goodbye to an (admittedly small) part of my mail archive.

On a similar note, an encrypted home directory on an old computer will soon be a bag of random bits after you switch to a new machine and change your user password. If forgetting old passwords used to be easy to circumvent (with init=/bin/bash and other venerable tricks), it's impossible now unless you can recall the keyboard sequence from muscle memory. I thoroughly clean out old hardware that leaves my hands. However if a laptop just ends up sitting in a drawer somewhere I'm usually sloppy enough that I often need to lift some old project files from a disused disk drive.

It's easy to avoid this problem once you know it exists. You can write the old GPG passphrase down somewhere or even remove it from the old secret key, depending how concerned you are about the content of old mail. Or you can keep the passphrases for old keys in sync with the new key. And move files you want to retain from old hardware. That saves it from stuck disk bearings as well.

Posted by Tomaž | Categories: Life | Comments »