Any network infrastructure on which LTE connections are used quickly reaches its limits. The project in this article includes throughput tests; however, because LTE technology supports bandwidths of more than 100Mbps, my MacBook Air was ruled out, because it only has a 100Mb USB Ethernet adapter. The various Raspberry Pis, with 100Mbps interfaces, are not fast enough either, so my task was to find an affordable alternative that ran Linux.

Two single-board computers (SBCs) were on my shortlist: the CubieTruck [1] and the Wandboard [2]. Both small PCs have newer versions – the CubieTruck is the third generation of the Cubie family [3], and versions of the Wandboard also exist with more CPU (performance and cores) and more RAM; both boards offer Gigabit Ethernet. However, I couldn't find a retailer offering the Wandboard, so I finally decided on the CubieTruck (Figure 1).

Figure 1: The CubieTruck has a credit card-sized footprint, much like the Raspberry Pi, but is significantly more powerful. (© http://www.cubieboard.org)

CubieTruck

Figure 2 shows the CubieTruck package: The board comes with a small, ultrathin heat sink, a SATA cable for connecting hard drives, an OTG cable, a USB cable, a power cable, and a case or mounting plate; the microSD card and the console cable, which proved very valuable for experiments with self-made kernels, come separately.

Figure 2: The CubieTruck board with a microSD card (front), the SATA and console cable (back), and the housing (right).

Because the CubieTruck has 4GB of built-in NAND memory, the microSD card is not really necessary, but it is especially helpful for network monitoring. Today, 4GB is not overly expensive, and the built-in NAND memory is comparatively slow.

The system features two USB 2.0 ports, HDMI, and digital optical and analog audio ports, as well as a VGA port. The CubieTruck also features an infrared receiver, an OTG port that can also be used to supply power, Bluetooth 4.0, and 802.11b/g WiFi. The 2GB of RAM and a dual-core Allwinner A20 CPU, which runs at a maximum 1GHz, ensure sufficient processing power. Finally, the board provides freely programmable GPIO pins, as well as a UART port, although you need a TTL cable for this.

Performance

To get an idea of the performance of the CPU compared with a Rasp Pi, I experimented a little with the openssl speed command, which offers benchmarks for all kinds of encryption and hash algorithms. The rsa1024 parameter tells it to generate 1024-bit RSA key signatures and check them.

The Cubie managed 158 signatures and 2,800 verifies per second compared with the Rasp Pi's 120 signatures and 2,010 verifies. The difference is even more significant given that the Cubie only used one core for this test. Calling the command twice simultaneously on the Cubie returned double these values.

In the case of SHA1 hashes, the Cubie managed to hash almost 5,000KBps for 16-byte input, compared with 2,300KBps for the Pi. The bigger the input, the smaller the difference; however, at 8,192 bytes, the Cubie managed 48,000KBps compared with 40,000KBps for the Pi. Here, too, the Cubie used only one core.

Installation

Initial installation is carried out on the internal NAND memory using a tool called PhoenixSuit [4] via the OTG cable. Budding CubieTruckers need to press a button on the board when powering on so that the board boots to FEL mode. The NAND memory then acts like a USB hard drive, so the image ends up on the card.

If you use an SD card, you can write the operating system to the card from your computer using dd, as for the Pi. In the default boot order, CubieTruck first tries the SD card slot and then the NAND memory.

Arch Linux was used for the tests; the CubieTruck starts a customized version of the U-Boot bootloader after you initialize the hardware in the first step. This offers the possibility of interrupting the boot process through the serial console so that you can use other kernel versions or parameters.

Linux development for the Allwinner CPUs is unfortunately lagging behind current development. Arch Linux uses the tree developed by the linux-sunxi community [5], whose latest version is 3.4.90. Several attempts to build a kernel resulted in a booting system, but I was unable to get the Ethernet interface to work with more recent kernels.

A bug in the default configuration of the Arch distribution kernels required a config option change. To do this, I had to use the Arch build system and manually customize the kernel configuration that comes with the sources. You can download suitable Arch builds via the

git clone https://github.com/archlinuxarm/PKGBUILDs

command.