We’ve already seen how to setup NanoPi NEO with Ubuntu Core, and while it’s mostly designed as an IoT node, for example to control relays over Ethernet or the Internet, I’ve still decided to see how it would perform under load by running Phoronix benchmarks, and then network and storage (micro SD card provided by FriendlyARM). It’s a small board, so we should expect it to heat a lot under load, especially it does not come with an heatsink by default. Also bear in mind that performance may dramatically change depending on the software implementation, and for the test, I’m using the company’s Ubuntu Core firmware.
Before start the benchmark, I noticed that QTe-Demo was running in the background, probably because it was used on their other board with video output or LCD. but it’s taking some CPU usage, and is absolutely not needed here.
To disable it, edit /etc/rc.local, and comment out one line as follows:
|
1 |
#/opt/QtE-Demo/run.sh& |
I also planned to install RPi-Monitor, which is very easy to install in armbian, but I could not find a quick way for the Ubuntu core image, so I skipped it for now, instead manually checking the temperature.
Let’s install Phoronix Test Suite:
|
apt install php5-cli php5-gd wget http://phoronix-test-suite.com/releases/repo/pts.debian/files/phoronix-test-suite_6.2.1_all.deb dpkg -i phoronix-test-suite_6.2.1_all.deb |
and run the benchmark against Orange Pi, Banana Pi, Raspberry Pi, etc… boards results.
|
1 |
phoronix-test-suite benchmark 1604204-GA-1604082GA37 |
Since it will take a while (4 to 5 hours) checking the terminal output while the benchmark is running may be informative:
Test Results:
368
320
304
301
292
295
Average: 313 Real C/S
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
John The Ripper 1.8.0:                                                              pts/john-the-ripper-1.5.1 [Test: Blowfish]                                      Test 1 of 7                                                                    Estimated Trial Run Count:    3                                                Estimated Test Run-Time:      5 Minutes                                        Estimated Time To Completion: 32 Minutes (08:13 UTC)                                Started Run 1 @ 07:41:35                                                        Started Run 2 @ 07:42:31                                                        Started Run 3 @ 07:43:28  [Std. Dev: 10.07%]                                    Started Run 4 @ 07:44:24  [Std. Dev: 9.58%]                                    Started Run 5 @ 07:45:21  [Std. Dev: 9.54%]                                    Started Run 6 @ 07:46:17  [Std. Dev: 9.10%]                                                                                                                Test Results:                                                                      368                                                                            320                                                                            304                                                                            301                                                                            292                                                                            295                                                                                                                                                        Average: 313 Real C/S    |
Phoronix will run the same test several times, and in theory, every iteration of the test should have roughly the same results, but in practice, modern processors do overheat, and either reduce frequency or cut the number of cores to keep the temperature below the (safe) junction temperature. The results here don’t look good, because they become slower overtime. A temperature check with an IR thermometer after one hour or so, shows the CPU is getting really hot.
We can also verify this in the command line by reading one of the temperature sensor:
|
cat /sys/class/thermal/thermal_zone1/temp 80 |
It’s hot, and the temperature tops at 80 C, and sometimes drops down to 76 C, before getting back to 80C, so the system is clearly throlling and the final results made that clear (ARMv7 rev 5 is NanoPi NEO without heatsink). Please also note that all 6 boards included below are using the same governor settings (interactive or ondemand). However, NaniPi NEO’s Ubuntu core Linux kernel is configured to run the RAM at the lower frequency to either decrease power consumption or heat generation.
Click to Enlarge
John the Ripper is a multi-threaded password cracker, and in theory NaniPi NEO should have about the same performance as Orange Pi One, but there’s clearly a massive drop in performance.
Click to Enlarge
Same thing for single threaded FLAC audio encoding, where NanoPi NEO is almost 50% slower than Orange Pi One, and about the same as Raspberry Pi 2.
So let’s check what happens is we had an heatsink. I glued the largish heatsink (for that board) by putting thermal paste on Allwinner H3 and the Samsung DDR3 SDRAM chip. It is not centered on the board because the Ethernet jack pins prevent this. You could add some thermal pads to work around this.
So let’s start again phoronix-test-suite to see if this improves anything:
|
1 |
phoronix-test-suite benchmark 1607218-GA-1605224GA81 |
Terminal output for the first benchmark:
Test Results:
461
456
438
Average: 452 Real C/S
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
John The Ripper 1.8.0:                                                            pts/john-the-ripper-1.5.1 [Test: Blowfish]                                    Test 1 of 7                                                                   Estimated Trial Run Count:   3                                               Estimated Test Run-Time:     5 Minutes                                       Estimated Time To Completion: 3 Hours, 40 Minutes (05:50 UTC)                     Started Run 1 @ 02:10:39                                                      Started Run 2 @ 02:11:35                                                      Started Run 3 @ 02:12:31 [Std. Dev: 2.68%]                               Test Results:                                                                     461                                                                           456                                                                           438                                                                       Average: 452 Real C/S                                                        |
We can see the results are both higher, and more stable, so that’s a good sign.
The heatsink temperature is about 54 C after around one or two hours.
But the CPU temperature is still high, and topping at 80 C from time to time:
|
cat /sys/class/thermal/thermal_zone1/temp 80 |
Nevertheless the final results are way better. I repeated the test with heatsink twice to some issue with uploading the results the first time…
Click to Enlarge
FLAC audio encoding is now just as good as on Orange Pi One.
Click to Enlarge
John the Ripper is still a bit lower on NanoPi NEO, which could either be because of RAM clock or overheating despite the heatsink. The multi-threaded performance is still better than on Raspberry Pi 2 however.
So if you want to want NanoPi NEO to control some relays, you probably don’t need to care at all about this, but if you plan to use it as part as a cluster or build farm, you’d have to consider using a heatsink and possibly a fan to get optimal performance, as well as make sure the board does not die prematurely…
Let’s switch to Ethernet performance, but running iperf server on the board:
|
1 |
iperf -s |
and running iperf client on a computer running Ubuntu 14.04 to test dual duplex performance:
Client connecting to 192.168.0.104, TCP port 5001
TCP window size: 74.4 KByte (default)
————————————————————
[ 6] local 192.168.0.109 port 42860 connected with 192.168.0.104 port 5001
Waiting for server threads to complete. Interrupt again to force quit.
[ 6] 0.0-60.1 sec 672 MBytes 93.8 Mbits/sec
[ 5] 0.0-60.1 sec 185 MBytes 25.8 Mbits/sec
|
1 2 3 4 5 6 7 8 9 |
iperf -t 60 -c 192.168.0.109 -d Client connecting to 192.168.0.104, TCP port 5001                              TCP window size: 74.4 KByte (default)                                          ––––––––––––––––––––––––––––––                   [ 6] local 192.168.0.109 port 42860 connected with 192.168.0.104 port 5001    Waiting for server threads to complete. Interrupt again to force quit.         [ 6] 0.0-60.1 sec  672 MBytes 93.8 Mbits/sec                               [ 5] 0.0-60.1 sec  185 MBytes 25.8 Mbits/sec |
So the download speed is all good at 93.8 Mbps, but the upload speed is not quite up to the task at 25.8 Mbps. Remember that a dual duplex test is a worse case scenario with heavy traffic going in both directions at the same, and it does not mean upload speed is limited to 25 Mbps in more typical scenarios.
NanoPi NEO does not come with any storage, and you can use any micro SD card you want, but FriendlyARM sells and recommend Sandisk Ultra 8GB SD micro card, so it would interesting to see how the one they’ve sent me performs.
For that purpose I’ve installed iozone to test the micro SD card performance. You’ll need to edit /etc/apt/source.list to add multiverse at the end of the first two lines, and then:
|
apt update apt install iozone3 |
I’ve run iozone3 with armbian community command line options, so that it can be compared to other SD cards:
Iozone: Performance Test of File I/O
Version $Revision: 3.429 $
Compiled for 32 bit mode.
Build: linux
Include fsync in write timing
O_DIRECT feature enabled
Auto Mode
File size set to 102400 kB
Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 10242
Output is in kBytes/sec
Time Resolution = 0.000001 seconds.
Processor cache size set to 1024 kBytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
random random
kB reclen write rewrite read reread read write d
102400 4 1955 2352 7864 7863 7761 736
102400 16 7564 7279 15509 15645 15571 99
102400 512 7570 11354 22914 22631 22909 2503
102400 1024 9598 10864 22947 22948 22894 5094
102400 16384 9689 9647 23075 22742 23069 9709
iozone test complete.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2       Iozone: Performance Test of File I/O                Version $Revision: 3.429 $                Compiled for 32 bit mode.                Build: linux                                                                                   Include fsync in write timing                                                 O_DIRECT feature enabled                                                      Auto Mode                                                                     File size set to 102400 kB                                                    Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 10242        Output is in kBytes/sec                                                       Time Resolution = 0.000001 seconds.                                           Processor cache size set to 1024 kBytes.                                      Processor cache line size set to 32 bytes.                                    File stride size set to 17 * record size.                                                                                           random   random               kB reclen   write rewrite   read   reread   read    write d          102400      4    1955    2352    7864    7863    7761     736           102400     16    7564    7279   15509   15645   15571      99           102400    512    7570   11354   22914   22631   22909    2503           102400   1024    9598   10864   22947   22948   22894    5094           102400  16384    9689    9647   23075   22742   23069    9709  iozone test complete. |
So it’s not quite the fastest around, especially in terms of random write for some files, and if you want a board that boot very fast (i.e. faster than the 10 seconds boot I got), and your application is I/O depend you may want to get something better like Samsung EVO 32GB.