LinuxBench

Asus Tinker Board, a First Look

At some point someone is going to make an ARM based home server, is this it?

I was intrigued when I heard ASUS was making a small ARM board. The Pi3 is an awesome little board, but I always felt the Pi boards were aiming lower than they could. A bit more RAM and slightly faster cores would be worth paying more for, and that seems to be what ASUS promises with their “tinker board.”

Opening the box reveals the board itself, an information sheet and a heatsink. The heatsink is quite sizable for a Pi sized board, perhaps a bit worryingly tall if you want to plug boards onto the expansion header which I guess is why it doesn’t come fitted. I didn’t buy the board to watch it thermally throttle, so straight on the heatsink went. My Pi3 has an old spare RAM heatsink on its SoC simply because, well, I had it kicking around not doing anything. This one looks way more serious, though nothing like the puppy you get on an Odroid C2.

There have already been a few OS images released for the tinker, for these tests I grabbed the latest linaro-jessie v14 and copied it onto a 16GB Sandisk Ultra SDHC card.

First Impressions

That SDHC card plugs it into the spring loaded card slot with a satisfying click. That seemed like a quality touch until I went to pick the board up and accidentally ejected the card with a not so satisfying click. If I had the board in a case then I suppose that wouldn’t be a problem. When buying the board it mentioned ability to handle 4K video, but on plugging the HDMI lead into my 1440p monitor I found the highest resolution I could get was 1080p. If I was after a 4K video player that would have annoyed me, checking the box it says the chip can decode 4K video and can display upscaled 1080p. Not impressed, but I can live with that.

Connecting to Wi-Fi was straightforward, and being Debian based I could use apt-get to update to the latest packages for everything. According to my USB power monitor the board is pulling 0.35A at idle, 0.45A with a keyboard and optical mouse plugged in.

The Contenders

The obvious board to compare against here is a Pi3, as that is the market leading product with the biggest following. The Pi3 has only 1G of RAM, and the cores are low end ones and so are in-order execution compared to the out-of-order A17 cores on the Tinker Board. Asus claim up to twice the speed.

Also thrown into the mix is an old PC ITX board with an Intel Atom D510 on it. This is 4 thread rather than 4 core, also has 2GB of ram, but being a PC board it is running off an old laptop SATA drive. I bought a case & PSU for this machine, but otherwise it is just stuff I scrounged for free or had kicking around in the junk box. Just the case with included PSU was £45, PC stuff is expensive compared with a Pi.

Java Performance

One of the first things I thought of when I saw the tinker board was that it could work as a minecraft server. I have been asked about setting up a home server by plenty of people, a cheap solution would probably sell rather well. With only 1G of ram the Pi3 isn’t really up to the task, the one time I saw it tried it was unplayable, basically a chat server for people to say “laaaaag” on a lot.

So here was my first shock, and it wasn’t a good one. The Java implementation you get as standard is an old school bytecode interpreter, and that is so slow it is basically unusable. The Pi gets this right out of the box, and from my brief play once with an Odroid C2 it got this right as well.

[email protected]:~$ java -version
Picked up JAVA_TOOL_OPTIONS: -Dgnu.io.rxtx.SerialPorts=/dev/tty96B0
openjdk version "1.8.0_121"
OpenJDK Runtime Environment (build 1.8.0_121-8u121-b13-1~bpo8+1-b13)
OpenJDK Zero VM (build 25.121-b13, interpreted mode)

So, lets’s measure how bad that is. Download the buildtools for the Spigot Minecraft server, and time how long it takes to build. Once built, fire up the server and see how long it takes to generate the spawn point and complete start-up.

The supposedly slower Pi3 delivers a convincing win, more than a magnitude less time to wait. That raised the question of how hard it is to get the Oracle JVM that the Pi uses running on the Tinker, but out of the box this is what to expect.

Native CPU performance

Most forms of home server are more I/O than CPU intensive, with one obvious exception of setting up secure network connections which requires quite a bit of computational grunt. OpenSSL can measure this with a simple command:

openssl speed rsa2048 -multi 4

where we are interested in the signs per second column.


That’s 361.6 vs 159.4, showing that when the A17 core isn’t I/O bound it can really shift. Now out of the box the A53 on a Pi3 is only running in 32 bit mode and a 64 bit distribution could make a big difference, a test for another day perhaps.

I/O Bottlenecks

I often hear people complain about the Pi having a slow USB port with the networking hanging off it leading to slow network performance. Using a Pi as a hack about board it hasn’t even been a limitation for me, so until now I never measured it.


The disk transfer speed is from a usb3 Hitachi external disk drive, 10GB of data read using dd from /dev/sda to /dev/null and recording the final throughput figure from the dd command. It should be noted from a general usability point of view not only was the Pi3 faster on raw transfer but it recognised the NTFS factory format of the external drive and would happily mount it, the Tinker wouldn’t simply mount the drive from the desktop.

Flash file write was manuallly measured by timing a dd from /dev/zero into a file on a mounted USB flash drive, including a "sync" command at the end to make sure the data had gone onto the drive. This wasn't expected to be useful in itself, but other tests needed somewhere to write their output so I wanted to see at what point the flash drive became a limitation.

How about over the network?


These figures are for performing a wget of a file from a web server plugged into the same gigabit switch as the test machine, with the file being written to a SanDisk Ultra Flair USB3 flash drive. The Wi-Fi test was performed with the 500MB test file, though the throughput was low enough that the 100MB test was the same. The Atom board doesn't have Wi-Fi but it does have a SATA port so it was writing the file to its hard drive.

Now testing with a USB drive isn’t ideal, but that just highlights a basic problem with these small platforms, you have to save the data somewhere, you don’t really want to be using the microSD card as they tend to have pretty poor write endurance. The Atom board SATA port is a real win here, or it would be if the ancient D510 cores could keep up.

So this seems to be a case of choose your poison, the Tinker bottlenecks on USB storage, the Pi3 is limited by a 100Mbit/sec Ethernet interface, the Atom tops out the CPU. I'm sure a modern Atom would do better here, but they cost way more.

Conclusion

The Tinker certainly feels like a well put together bit of hardware, but once you fire up the software the package feels unfinished. In comparison the Pi is a polished overall product with some real oddities. The graphics drivers have OpenGL ES, but not the plain OpenGL which home users are more likely to want. There seemed to be constant updates to the Mesa graphics libraries, perhaps with some digging OpenGL is possible. Java is hopelessly slow, perhaps with some digging the Oracle JVM can be installed. I tried to NFS mount my server from the Tinker, but there was no NFS support as standard.

Testing wasn't painless, after I had run the tests I updated the Tinker board again and on rebooting it crashed in very early boot. Unplugging the mouse and keyboard, cycling the power and then re-plugging the mouse and keyboard got me up and running again. The Atom had a similar problem, though this time probably because it is an obsolete platform rather than too new. At the start of the tests I updated the Fedora install as it was rather out of date. On updating from Fedora 23 to Fedora 25 the graphical desktop went away leaving me with a text login. I was going to remote into it anyway, but I wonder if the graphics driver for the old integrated graphics is obsoleted.

The Pi3 just worked. The problem with the Pi3 is that the platform is kind of stuck. Apparently the graphics part of the Pi has remained the same since the original Pi with just the CPU cores being updated, and that graphics core can only handle 1GB of RAM. That means a big platform change to get more RAM, and the Pi foundation believe 1GB is enough for anyone (think I have heard that before somewhere).

Is this the small server board I hoped for? Not yet, but it has the potential to become one if Asus can get their software up to the standard we are used to on the Pi.