NanoPi R2S & NanoPi NEO3 tested with Armbian – Thermal test, Ethernet and USB performance

In the first part of the review of NanoPi NEO3 and Nano R2S I checked out the hardware, with both tiny gateways powered by a Rockchip RK3328 processor but a different features as NEO3 includes a Gigabit Ethernet port and a USB 3.0 port, while R2S comes with dual Gigabit Ethernet ports and a USB 2.0 port.

I’ve now had time to test both gateways using Armbian 20.08.1 release based on Ubuntu 20.04 Focal. Note that while NanoPi R2S is officially supported by Armbian, NanoPi NEO3 images are currently tagged as “suitable for testing“. Having that said I did not come across any specific issues on NEO3, and it may mostly mean it’s easier to get support on the forums with R2S.

I flashed two microSD cards using USBImager with:

  • Armbian_20.08.1_Nanopi-r2s_focal_current_5.8.6_minimal.img.xz
  • Armbian_20.08.1_Nanopineo3_focal_current_5.8.6_minimal.img.xz

That means Ubuntu 20.04 with Linux 5.8.6, but since Armbian is always updated, I ended the review with Linux 5.8.15. I’ll focus the review on thermal testing, as well as Ethernet and USB performance.

NanoPi R2S NanoPi NEO3 Armbian Review
NanoPi R2S (left) and NanoPi NEO (right) – Raspberry Pi 4 for scale

System Setup

Both are headless systems so you can’t connect them to any display to do the configuration. Instead, we can connect with SSH using root and 1234 password.

This will take us through Armbian’s wizard to set a new root password, update locales, and create a new user account. Subsequent login will just show system info.

We can see my NanoPi R2S comes with 1GB RAM and idles at 46°C, while NanoPi NEO3 features 2GB RAM, and the CPU temperature is at 58°C at idle both a few minutes after boot. So the metal case really helps the latter.

Let’s install armbianmonitor to get pretty temperature charts:

Alright… Maybe I should not have asked the initial script to set locales and the console keyboard automatically from my location…

Let’s install armbian-config and change the settings:

armbian-configLet’s select Personal – Timezone, language, hostname, and then Locales to enable/disable the locales we’d like to use, and finally select the default locale as shown below. I went with C.UTF-8.

armbian default locale

So hopefully, all output from the commands in the rest of the review will be entirely in English.

NanoPi NEO3 / R2S thermal testing with SBC Bench

I’ll use Thomas Kaiser’s script to benchmark the system and check for any CPU throttling:

NanoPi R2S results:

We can see throttling occured, but looking at the data and temperature chart it only happened at the very-end of 7-zip multi-threaded benchmark, and during cpuminer.

NanoPi R2S Temperature ChartNote my room temperature was around 30-31°C, and throttling may not happen at all with a lower ambient temperature.

Let’s repeat the test with NanoPi NEO3:

That one hurts! The small heatsink inside the case does not help too much, and throttling occurred virtually immediately with even tinybench being affected.  You’ll also notice the much lower benchmark scores due to throttling despite both platforms using a Rockchip RK3328 processor. For example, R2S scores around 3,800 in 7-zip, while NEO3 only gets around 2,450, that’s a 35% drop.

NanoPi NEO3 Temperature ChartAgain the ambient temperature of 30-31°C likely played a role but considering single-threaded benchmarks trigged CPU throttling at around 85°C, I’d expect this type of problem to show up for most people, even in much cooler rooms.

Nevertheless, I went to bed and noticed the temperature dropped at 4 am the following day.

NanoPi NEO3 Sudden Temperature DropThere was a small spike in CPU usage at that time too.

CPU usage during rebootI thought there may be a scheduled task, but I could not find anything in crontab, and instead, the board just restarted at that time:

Micro power failures are common where I live, but NanoPi R2S did not reboot despite being connected to the same 100W power supply (MINIX NEO P2 USB-C multi-port power supply):

So I have no explanation for the reboot, nor the temperature chart because even after around 11 hours after benchmark completed, the idle temperature did not return to normal until a reboot. [Update: The higher temperature is because sets the governor to “performance”]

Checking NanoPi NEO3 temperature with Syncthing

Not every workload requires the CPU to be under load at all times, so to check how NanoPi NEO3 would perform as a mini NAS I planned to install OpenMediaVault (OMV) via armbian-config. But it’s not there, because OMV does not support Ubuntu. I could have installed Debian to load OMV on the board, but I noticed Syncthing continuous file synchronization program that would also use Ethernet and storage, so I installed it instead using armbian-config going into Software->Softy.

NanoPi NEO3 Armbian SyncThingI also add to install the program on my computer following the standard instructions for Ubuntu, and synchronized the Pictures folder on my computer to a directory on the hard drive connected to NanoPi NEO3.

NanoPi NEO3 SyncThing

The download rate varies a lot, and it looks like Syncthing transfers files one by one as I see transfer peaks on System Monitor on my laptop instead of a continuous transfer rate, so the load on the system is not as high as it could, and indeed after running the synchronization for about one hour, the temperature never exceeded 85°C. The room temperature was around 28-29°C at the time.

Temperature Chart SyncThing NanoPi NEO3 SBCThe temperature probably peaked while transferring larger files like videos.  There was a dropped around 15:06, as folder scanning on the laptop was not complete, and it resumes a few minutes later once all ~1,600 files (70GB) were scanned on the host.

Ethernet Performance

I’ve installed iperf to test network performance

NanoPi R2S full-duplex on LAN port:

That’s almost as good as it gets as the board can move data in both directions at high throughput at the same time.

NanoPi R2S full-duplex on WAN port:

It’s fast in one direction, and a bit slower in the other. It will likely not matter for most use cases, but if you have a Torrent node that downloads and uploads files at the same time performance may not be optimal.

SI also tested R2S WAN port upload only:

and download only:

All good here.

Switching to NanoPi NEO3 with full-duplex transfer:

Pretty good, but still a bit slower in one direction.

So I tested upload only as well:

and download only:

Exactly 940 Mbits/s for both, and that’s excellent for such a small and cheap device.

USB Performance

I’ve connected a USB 3.0 hard drive to one of the gateways to check USB performance. However, none of the partitions on the USB drive would automount:

So for testing, I installed pmount…

in order to mount the EXT-4 partition as the current user (i.e. no sudo):

Let’s now run iozone on NanoPi NEO RS2 to check USB performance:

Around 34MB/s is OK considering we have a USB 2.0 port.

Time to unmount the drive

and move it to Nano NEO3 to repeat the same procedure with a USB 3.0 port.

The results are higher with around 85MB/s, but a bit disappointing for a USB 3.0 port since I’d usually get around 90 to 100+MB/s on this drive.

Final words

Both are nice little gateways that serve different purposes with NanoPi R2S being equipped with two Gigabit Ethernet ports and a USB 2.0 port, and NanoPi NEO3 featuring a Gigabit Ethernet port and a USB 3.0 port, and both devices work well with Armbian (Ubuntu Focal) with performance as expected. But under any heavy or not that heavy workloads, NanoPi NEO3 will heat up pretty quickly, at least with the plastic case mine shipped with, so if the USB 2.0 speed limitation is not an issue for your use case, you may prefer NanoPi R2S with its metal case which helps the gateway stay cool in most loads. However, as we’ve seen with Syncthing syncing pictures (and some videos) not all use cases will make NanoPi NEO3 CPU throttle.

I’d like to thank FriendlyELEC for sending the review samples, and the Armbian community for providing easy to use firmware images. The gateways can be purchased with or without case on Aliexpress (here and there) or directly on the company’s website. Make sure to purchase NanoPi R2S with the black metal case, and not the yellow plastic case, or it will likely suffer from similar overheating issues as NanoPi NEO3 SBC with a plastic case.

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

13 Replies to “NanoPi R2S & NanoPi NEO3 tested with Armbian – Thermal test, Ethernet and USB performance”

  1. Did you measure the power consumption? I guess that is the reason to use a device like this instead of a an x86 with more software support.
    Also I would be a little skeptical with only using a sd cars having experienced a fair share of sd card corruption on raspberry pi’s.

    1. I haven’t measured power consumption. This kind of hardware usually consumes 4 to 10W depending on the load and accessories. Other reasons to use this instead of x86 is price, size, and noise levels.

    2. Define, “more software support”. If you’re wanting Windows, yeah. If you’re wanting Linux, methinks you fail to understand “Linux”. Almost everything that makes sense is, “available,” on it. If it’s not on the distro and you can’t manage to compile, being an x86 machine doesn’t magically make that software available.

  2. It would be nice if we can figure out why wan upload is capped at 500Mbps, the poster saying both nic can work at 941Mbps. It’s could be some software or configuration issue making it slower when TX packets. Otherwise it’s a perfect gigabit gateway/firewall.

  3. I still feel Orange Pi Zero LTS is better on price. With enclosure in the picture this looks like a final product, except that it does not have FCC certification, which it really should have.

    1. Orange Pi Zero LTS is nice, but with fairly different specs: less RAM. Fast Ethernet, USB 2.0, 32-bit Arm vs 64-bt Arm (So no Armv8 crypto extension for OPI board). It all depends what you’d plan to do with it.

  4. > even after around 11 hours after benchmark completed, the idle temperature did not return to normal until a reboot

    sbc-bench switches the cpufreq governor to performance so the SoC stays at the upper clockspeed all the time until this changes (e.g. by running cpufreq-set -g ondemand or rebooting).

    A difference of 12°C between idling at above 1GHz and the normal idle clockspeed still lets me think that there’s something seriously wrong with the DVFS table (feeding RK3328 with voltages too high).

Leave a Reply

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

Khadas VIM4 SBC
Khadas VIM4 SBC