Posted on by Jean-Luc Aufranc (CNXSoft) - 21 Comments on NanoPi NEO2 Board Benchmarks with Ubuntu 16.04.2 using Linux 3.10 and Linux 4.10

NanoPi NEO2 Board Benchmarks with Ubuntu 16.04.2 using Linux 3.10 and Linux 4.10

I’ve received NanoPi NEO 2 boards, add-boards and sensor modules last week, where we could see how small the boards were, and how it could be suitable for IoT projects or “hardware hacking” education.  Before testing the board with the add-ons, I have to select the image to run on the board, and currently we have two choices: Ubuntu 16.04.2 FriendlyELEC image with Linux 3.10 “legacy” kernel, or Armbian Ubuntu 16.04.2 Xenial nightly build with Linux 4.10 “mainline” kernel. So I decided to try both: dfssf

  • nanopi-neo2-ubuntu-core-qte-sd4g-20170329.img.zip (296 MB) is the image from FriendlyELEC (previously FriendlyARM)
  • Armbian_5.27.170401_Nanopineo2_Ubuntu_xenial_dev_4.10.0.7z (222 Mb) is the image from Armbian, which I downloaded on March 31st despite the filename including “170401” string

You can flash the image with Win32DiskImager (Windows) or dd (linux) to a micro SD card the usual way, and while I’ve never personally had troubles with dd, I’ve been told Etcher was better, as it verifies the SD card after flashing, and dd may miss errors. Etcher works in Windows, Linux, and Mac OS with a graphical user interface or from the command line. I used Etcher GUI in my Ubuntu 16.04 computer, and it’s indeed easy to use, shows the progress, and a big plus for me is that you can’t mess with your USB hard drive, as it will filter them. Another small advantage is that you don’t need to uncompress the firmware, as Etcher will do that for you, at least for zip files, but i had to manually uncompress Armbian .7z archive before loading to Etcher.

Note that I used the exact same micro SD card (the 8GB SanDisk Ultra sold by FriendlyELEC) and the same board for both images. I started with FriendlyELEC image, and then repeated the test with Armbian image.

I connected the Gigabit Ethernet port to my GbE switch, as well as FriendlyELEC Matrix USB2UART board with the provide cabled including 5V, GND, Tx and RX. It will power the board too, but if you’re going to run benchmarks, there won’t always be enough, and I also used a USB power supply connected to the micro USB port. Having 5V on the serial cable makes it inconvenient, because when I need to power cycle the board I had to remove both the debug board and the extra USB power supply. So instead I used 3 jumper wires without 5V as shown in the picture below.

Click to Enlarge

FriendlyELEC Ubuntu 16.04.2 Boot Log and Info

I used minicom connected to /dev/ttyUSB0 with 115200 8N1 configuration to boot the board, and this is the boot log for Ubuntu 16.04.2 image with Linux 3.10 once I got the debug board issue mentioned above out of the way (so it’s not the very first boot):

It will login automatically in the console, and you don’t need to to enter the username & password. If you need to use sudo later the password for “pi” user is simply “pi”

Let’s check some of the system details:


Linux 3.10.65 is used, and the root file system was automatically resized during the first boot to make use of the complete storage available on the micro SD card. We have 928 MB used out of 7.2 GB. It will show four Aarch64 cores part of sun50iw2 family. There are some module loaded specifically for camera support such as vfe_v4l2 module, which you could disable in /etc/modules if you don’t need it.  I’ll need GPIO support for BakeBit Starter Kit, and it seems enabled by default.

Just like in NanoPi NEO Ubuntu, there’s a Qt demo enabled in /etc/rc.local, so you may want to remove the lines below since we don’t have an LCD display connected to the board:

Armbian Ubuntu 16.04.2 Boot Log and Info

The boot log for Armbian is much shorter (and cleaner):

The image appears to be for OrangePi PC 2 board, and there are some errors about failure to set voltage and CPU frequency, so maybe it will have to be fixed soon.

You’ll need to login with root / 1234, and the first time, you’ll be asked to change root password, and create a new user part of sudoers. I’ve run the same command with the Armbian image as I did with the FriendlyELEC (FE) one:


The obvious advantage is that the Armbian image is running the latest Linux 4.10.0 kernel with all new features and security patchsets. The rootfs is also automatically resized during the first boot, but there must be more packages installed by default, since 1.2 GB is used out of 7.2 GB. while we had only 928 MB used in FE image. The reported hardware is sun50iw1p1 against sun50iw2 in FE image, but I assume it does not matter that much. Different modules are loaded by default in that image, no camera modules, but instead audio modules. The listed GPIOs are the same as in FE image.

Linux 4.8 and greater is supposed to support the new GPIO subsystem with the ability to list GPIOs using lsgpio command:


But the command is not installed, and not part of any Ubuntu packages, so it would have to be build from source, but I have not checked it yet. All examples provided by FriendlyELEC for their BakeBit Starter Kit are going to use sysfs interface since they provide a Linux 3.10 image.

NanoPi NEO 2 Benchmarks

I’m going to running the same benchmarks as on NanoPi NEO with Phoronix and iperf. Since Ubuntu 16.04 comes with PHP 7, Phoronix Test Suite installation is a little different:


I made sure the heatsink faced upwards when running the benchmarks, as in the past I had troubles when the heatsink faced the table since – as you mum or teacher must have told you – heat is going up, and if the heatsink faces down, heat may be trapped.

Then I ran the benchmark using FE and Armbian images:


You’ll find all results here, but let’s have a look at some of the results starting with Ripper, a multi-thread password cracking program. FA stands for FriendlyARM in the chart.

Click to Enlarge

I’ve included all the boards for broad results. In this particular benchmark NanoPi NEO 2 is about the same speed as NanoPi NEO board, and both images have similar performance. Please note that the image may not have been optimized for the best performance, but rather low power consumption with lower CPU and RAM frequencies, which may explain for example why Orange Pi One is a little faster. You’ll note the importance of have a heatsink, by looking at “NanoPi NEO 512MB No Heatsink” result. The results with the image used on NanoPi NEO 2 also seem more “stable”, as the SE +/- values are much smaller in all tests.

Click to Enlarge

FLAC audio encoding is a single thread test, and here NanoPi NEO  and NEO 2 have similar performance using Ubuntu FA image, but for some reason the Armbian image was slower here.

Click to Enlarge

So far we did not see any improvement use NEO 2 over NEO, but if we look at C-Ray benchmark, there’s a clear advantage of using the 64-bit processor (H5) over the 32-bit processor (H3).

Click to Enlarge

Smallpt v1.0 is another example showing much better performance on NanoPi NEO 2, and it’s even faster than Raspberry Pi 3 board.

But overall, there’s basically no difference between using FriendlyELEC or Armbian Ubuntu image, except for the FLAC audio encoding.  But let’s have a look at Ethernet performance.

Ethernet Performance with Ubuntu 16.04.2 + Linux 3.10 FriendlyELEC image.

iperf upload (iperf -s running on computer):


iperf download (iperf -s running on board):


full duplex:


There seems to be a serious problem with upload speed.
I did an extra test with a 1.6 GB HTTP download to /dev/null:


The download speed on NanoPi NEO 2 was 57.1 MB/s. Acceptable.

Ethernet Performance on Ubuntu 16.04.2 + Linux 4.10 Armbian image.

I’m repeated the same test with Armbiab image:

iperf upload:


iperf download:


iperf full duplex:


HTTP download: 108 MB/s.

So there’s no competition here, Armbian image is much better if you need good Gigabit Ethernet performance. The poor upload performance is gone, and the HTTP download is twice as fast, and close to the maximum theoretically possible throughput.

Finally , I did a quick test with CHARGER DOCTOR to check the power consumption in idle mode: 0.21A @ 4.65V (~0.98 Watt). Last year, NanoPi NEO consumed about 2 Watts in idle mode with a non-optimized Ubuntu + Qt Embedded image.

Based on the results I got here, I’ll probably try Armbian image with BakeBit Starter Kit to test GPIO, I2C, UART,… and only revert to FriendlyELEC image in case one of the module does not work.

NanoPi NEO 2 sells for $14.99, and the heatsink set for $2.97 with shipping adding a few dollars.

Share this:
FacebookTwitterHacker NewsSlashdotRedditLinkedInPinterestFlipboardMeWeLineEmailShare

Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress

ROCK 5 ITX RK3588 mini-ITX motherboard

21 Replies to “NanoPi NEO2 Board Benchmarks with Ubuntu 16.04.2 using Linux 3.10 and Linux 4.10”

  1. There’s definitely something wrong with the Armbian image if it reports Orange Pi PC 2. Please try to add

    to /boot/armbianEnv.txt, reboot and if this doesn’t fix it we have to investigate further. Please also note that there is a fixed/better mainline Ethernet driver variant in the works so performance will most probably increase automatically within the next weeks or months.

    It should also be noted that Armbian settings for NEO 2 are tuned for low consumption and we didn’t even start to investigate fine-tuning with H5 boards. I’ll start working on this in a few weeks (FriendlyELEC currently ran out of dev samples) and then both overall and also network performance will further improve when running with Armbian (so any benchmarks done now are somewhat irrelevant)

    BTW: NanoPi NEO with H3 is allowed to clock up to 1.2 GHz while H5 here is limited to 1 GHz so it’s nice that performance is somewhat identical even if NEO 2 is clocked lower. Due to memory constraints on this board we’ll also investigate whether running a true 32-bit userland on NEO 2 might be a better alternative: https://github.com/igorpecovnik/lib/issues/645

    Reply

  2. @cnxsoft:
    You mentioned H3 NEO consuming 2W in idle. Most probably your board is PCB rev 1.0 which had a design flaw that was fixed soon by FriendlyELEC (IIRC only weeks later after some early adopters noticed bad thermal and consumption behaviour they replaced U7 LDO regulator and since then the problem is gone. With Armbian’s settings a NEO with PCB rev 1.0 idled slightly below 1W so I would assume with later board revisions that must have been dropped to 700mW or even below).

    Unfortunately you won’t have much fun with Bakebit stuff and Armbian now since we only support mainline kernel and the necessary device-tree (DT) bits are missing. Armbian will address this with DT overlays in the future but this stuff isn’t available for H5 boards yet: https://docs.armbian.com/User-Guide_Allwinner_overlays/ (still WiP and only useable on A10, A20 or H3 boards now)

    Reply

  3. BTW: Since NEO 2 might also make for a nice small NAS I added some lines of code to Armbian’s build system to create proper OpenMediaVault 3 OS images for any of the ~50 SBC we currently support: https://github.com/igorpecovnik/lib/commit/04583b2ceb4f0e7b5d8544c4251a33e5a320648b

    So in case you want to extend your NEO 2 test series with another part in a few weeks (I need my NEO Plus 2 here to start improving performance settings) you could give it a try. Funnily most ‘ready to run’ OMV images available on the net for ARM devices use weird settings so that a NEO 2 while being USB2 only might outperform OMV images made for A20 SATA boards 🙂

    FriendlyELEC sells now a nice looking NAS enclosure which suffers from one serious design flaw (incapable USB-to-SATA bridge — I hope they fix that soon) so I would call this a valid use case…

    Reply

  4. And another question: could you please provide output from ‘gcc –version’ with both images (if different then it might explain some variations in Moronix test suite results above). And tinymembench numbers would also be very interesting 🙂

    Reply

  5. What is the maximum power NanoPi NEO 2 draw, say when doing full speed iperf. Also how the Air with wifi and load. Thanks for the benchmarks. They rate 2A. Does it really need 10W under load?

    Reply

  6. @Antony
    I get 0.52A @ 3.96V (~2W) during iperf.
    This test does not stress the CPU however, as only one core is used.

    armbian monitor does not fully work yet, and I’m not sure how to check frequencies.

    If I run cpuburn on all four cores, and measure power consumption with a kill-a-watt clone (less accurate than charer doctor, but my USB port won’t provide enough power) I get 4.2 Watts.

    Now if you’re going to connect a USB drive, you’ll need to take into account the extra draw too. It went up to 9.1 watts when I connected my hard drive, before stabilizing at 6.1 watts, still with cpuburn running.

    Reply

  7. @tkaiser
    The kernel detects NanoPi NEO 2, but I think the bootloader is the one made for Orange Pi PC 2.
    Adding the new line to /boot/armbianEnv does not change the output of the bootloader.

    I don’t think you can improve Gigabit Ethernet much, it’s hard to get better than 108 MB/s for an HTTP transfer over GbE.

    gcc version is always shown in Phoronix results: GCC 5.4.0 for both which makes sense since the root fs is the same (Ubuntu 16.04.2).

    tinybench in Armbian image:

    Reply

  8. @Antony
    Check bottom of ‘SBC consumption/performance comparisons’ thread in Armbian forum for cpuburn consumption at 1008 MHz / 1.1V (this load is rather unrealistic so even in worst case conditions the board alone won’t consume that much). The limitation to 1.1V here keeps maximum consumption low (something you can achieve on all SBC by tweaking cpufreq/DVFS scaling settings)

    Regarding a 2A ‘rating’: PSUs with lower ratings are often crap (huge voltage drops under load) so it makes some sense to recommend something that most probably don’t suck. Also you should keep in mind that the NEO 2 exposes 3 USB host ports (eating up to 500mA each) and what’s also interesting: soon you can switch even the Micro USB port to a host-powered real USB host port (the PHY can be either be connected to a ‘musb’ controller or a real EHCI/OHCI controller inside H5) so you might end up with USB peripherals already exceeding 10W 🙂

    Reply

  9. @cnxsoft
    Thank you for tinymembench numbers. They show a huge improvement over H3 based NEO (the single bank DRAM configuration on all small H3 boards leads to much lower memory bandwidth: ‘standard memcpy’ with H3 NEO is 433.5 MB/s at 408MHz DRAM clock or 539.3 MB/s at 672 MHz while with NEO 2 it’s 908.9 MB/s now).

    Regarding boot loader settings currently only DRAM config matters (it’s CONFIG_DRAM_CLK=672 which might change) and of course there’s some improvement with network performance possible (tweaking settings, eg. sending eth0 IRQs to another core, stuff like this will give some extra performance on a system under full load or when single threaded applications start to be bottlenecked by CPU as it’s the case with iperf [full duplex])

    Reply

  10. cnxsoft :
    @tkaiser
    The kernel detects NanoPi NEO 2, but I think the bootloader is the one made for Orange Pi PC 2.
    Adding the new line to /boot/armbianEnv does not change the output of the bootloader.

    It’s easy to see if you’re booting from the correct DT or not, when using the default DT the blue LED is off. Once you boot with the nanopi2 DT, you see it blink.

    Reply

  11. @Willy
    My blue LED is blinking. The hostname is automatically set to nanopineo2 as well, so I guess the board has been detected properly. It’s just the beginning of the boot log (after BL binaries output) shows:

    Reply

  12. @cnxsoft
    The ‘OrangePi PC 2’ might be even hardcoded in this mainline u-boot version since this was the board H5 support started with. As already said, it doesn’t really matter what happens in early bootloader stages here since DRAM clockspeed is the only thing that really matters (and then some error messages due to SY8106A voltage regulator missing on NEO 2 🙂

    Mikhail, the dev who assembled the patches floating around to something useable, pointed out that we need to update branches soon anyway since:
    ‘First problem is the u-boot configuration. We are using a quite old u-boot branch but newer stuff wasn’t accepted in mainline yet (so we are using something that works instead of trying to catch a constantly moving target).
    Second problem is H5 device tree (merged to 4.11 while we are using WIP 4.10 stuff). Again, once we move to a more or less stable 4.11 or 4.12 based branch it would be more productive for the future mainlining efforts.’

    Reply

  13. thanks @cnxsoft
    It is impressive. One more question you mentioned you run into situation where the board can not draw enough power.
    What exactly did you observe then? Some possibilities I can imagine are:
    1. software warning and can take action.
    2. CPU reset when voltage drops?
    3. does the system lock up and need a manual reset?
    4. permanent damage to CPU/hardware? It sounds less probable.
    4. cpu/dram shutdown due to overheating. Is there an overheating protection?
    5. Or something else happens?
    I understand connecting external USB could draw more power from the board.

    Reply

  17. Great post! I’m glad to see these got good ethernet performance (at least with 4.x kernel).

    I couldn’t find the specs on Friendly’s site – do the NEO2’s support microSDXC, or just SDHC?
    I’ve been looking for small SBCs with GigE that could sustain ~100MB/s transfers over the network using high-end microSDXC, such as the Sandisk Extreme and PRO series (reviewed – https://www.anandtech.com/show/12002/sandisk-extreme-and-extreme-pro-memory-cards-review/3 )
    I suspect the 8GB Ultras aren’t fast enough, but do you have any faster microSD to benchmark on the NEO2?

    Reply

    1. I’m not sure about SDCX vs SDHC. But you’ll find a post about SD cards for development board @ https://www.cnx-software.com/2017/06/13/micro-sd-cards-for-development-boards-classes-tools-benchmarks-reliability-and-tips-tricks/

      The recommendations are mostly to get the OS runs smoothly, but in your case it looks like you also need fast sequential speed for whatever data stored in your card. I think I’ve seen some photography websites have data about that since that metric is also important to them.

      Reply

    2. The SD interface on those Allwinner SoCs supports higher speed modes but usually the boards don’t. So you’re stuck with DDR50 and end up with sequential transfer speeds being limited to ~23 MB/s regardless of the card used.

      Higher speed modes require switching from 3.3V to 1.8V and only some (more expensive) boards support this. DDR50 vs. higher speed modes affects all performance metrics: https://forum.armbian.com/topic/954-sd-card-performance/?do=findComment&comment=49811

      I would have an eye on the upcoming NanoPi NEO4 with RK3399 SoC since by looking into preliminary hardware documentation (device-tree) it seems it will support 1.8V.

      Reply

      1. Thanks for the info, this is good to know. I’ll wait for the NEO4 to try it out. Do you know of any other small boards that have SATA interface (native, not USB-to-SATA)? I tested Nvidia Jetson a while back, and that could sustain 100MB/s (with SATA SSD) no problem, but is total overkill in terms of size and cost.

        Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

Boardcon Rockchip and Allwinner SoM and SBC products
Boardcon Rockchip and Allwinner SoM and SBC products