Home Benchmarking the NanoPi R5S
Post
Cancel

Benchmarking the NanoPi R5S

Table of contents

Because this post is quite long and with too many details, I’ve used a TOC so you can browse better.

1. Intro

Today I’m really happy that I’ve received the new Nanopi R5S from FriendlyElec to test it. 1.5 year ago I was able to test the Nanopi R4S and I’ve written two posts, with the last one here.

You can’t really do a 1-to-1 comparison between the two brothers, because the younger one comes with new features that the older brother lacks, but I’ll write more about that next.

Back to TOC

2. The SBC

The NanoPi-R5S can be bought as a PCB only or you can also buy the black aluminum case as an extra. The quality of the case is very good and it’s made especially for the R5S. The fit is tight and this time I was really excited when I’ve seen the antenna hole above the USB power port. In my last post for the R4S benchmark here I had to drill my own hole on the case to fit the USB-to-UART adapter in order to get the debug console.

NanoPi-R5S NanoPi-R5S front

Back to TOC

2.1 SBC - PCB

The PCB of the R5S is quite populated with several ICs. This is the bottom side.

NanoPi-R5S NanoPi-R5S PCB

And this is the top side.

NanoPi-R5S NanoPi-R5S top side

On the bottom side you can see the 8GB eMMC and the PCIe2.1 M.2 connector for the nvme, which is 1x lane. The theoretical bandwidth of x1 lane for the 2.1 PCIe is 500 MB/sec, which means you don’t really have to buy and expensive nvme to populate the slot.

On the top side you can see the 2GB RAM, the 3x network PHYs under the ports, the SoC which comes with a silicon thermal pad and the RK809 PMIC.

There are also 2x USB 3.0 ports, an SD card holder and between the SD card the USB there’s an expansion connector for UART/SPI/PWM. The debug uart (console) is next to the LAN2 2.5G port. This is useful to solder a pinheader and connect a USB-to-UART module to get the output for debugging.

Back to TOC

2.2 SBC - UART mod

It’s easy to get the debug console output. All you have to do is to solder a pin-header and then connect a USB-to-UART module.

The default baudrate for the UART is 1.5Mbps, therefore many modules won’t work. I’ve used a module with the FTDI FT232RL chipset.

This is how it looks like with the UART mod.

NanoPi-R5S UART mode

And this is how it looks assembled in the case.

NanoPi-R5S UART mode in case

Back to TOC

3. NanoPi R5S specs

The main specs of the NanoPi R5S are listed here, but I’ll mention the ones that I consider the most important.

Back to TOC

3.1 Specs - OS

The OS that the R5S came with in the eMMC is a branch of the OpenWrt, which is named FriendlyWrt. This branch includes all the needed drivers and it has the proper device-tree to support the SoC.

This is the uname result:

1
Linux FriendlyWrt 5.10.66 #1 SMP PREEMPT Wed May 18 17:58:14 CST 2022 aarch64 GNU/Linux

Therefore the kernel is based on Linux 5.10.66.

Back to TOC

3.2 Specs - SoC

The SoC is the Rockchip RK3568B2 which is a Quad Core Cortex-A55 CPU. On idle the FriendlyWrt reports:

1
2
3
4
5
root@FriendlyWrt:~# cat /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_max_freq
1992000
1992000
1992000
1992000

Therefore, all the cores are running at almost 2GHz.

Back to TOC

3.3 Specs - Network interfaces

Nanopi R5S, has 3 HW network interfaces:

  • eth0, it’s the SoC’s native 1Gbps network adapter which is mapped to WAN port
  • eth1, it’s the first 2.5Gbps PHY connected on the PCIe bus
  • eth2, it’s the second 2.5Gbps PHY connected on the PCIe bus

These are the PCIe devices:

1
2
3
4
5
root@FriendlyWrt:~# lspci
0000:00:00.0 PCI bridge: Rockchip Electronics Co., Ltd RK3568 Remote Signal Processor (rev 01)
0000:01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller (rev 05)
0001:10:00.0 PCI bridge: Rockchip Electronics Co., Ltd RK3568 Remote Signal Processor (rev 01)
0001:11:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller (rev 05)

So, the 2.5Gbps interfaces are based on the RTL8125.

The following is the result of the the ip link show command for reference:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
root@FriendlyWrt:~# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000
    link/ether fe:e7:97:xx:xx:xx brd ff:ff:ff:ff:ff:ff permaddr e6:99:c2:xx:xx:xx
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq master br-lan state DOWN mode DEFAULT group default qlen 1000
    link/ether fe:e7:97:xx:xx:xx brd ff:ff:ff:ff:ff:ff permaddr ea:99:c2:xx:xx:xx
4: eth2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq master br-lan state DOWN mode DEFAULT group default qlen 1000
    link/ether fe:e7:97:xx:xx:xx brd ff:ff:ff:ff:ff:ff permaddr 6e:0e:34:xx:xx:xx
5: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 56:40:c4:xx:xx:xx brd ff:ff:ff:ff:ff:ff
6: gre0@NONE: <NOARP> mtu 1476 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/gre 0.0.0.0 brd 0.0.0.0
7: gretap0@NONE: <BROADCAST,MULTICAST> mtu 1462 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
8: erspan0@NONE: <BROADCAST,MULTICAST> mtu 1450 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
14: br-lan: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
    link/ether fe:e7:97:xx:xx:xx brd ff:ff:ff:ff:ff:ff

Here, except the eth0-2 we can see also other virtual interfaces used from FriendlyWrt to handle the WAN and LAN interconnections.

  • erspan0, is a virtual interface used for port mirroring.
  • gre0 and gretap0, are the GRE tunnel. GRE are IP-over-IP tunnels, which can encapsulate IPv4/IPv6 and unicast/multicast traffic.
  • br-lan, is the bridge network for LAN and WAN.

Finally, this is how IRQ are mapped for each interface to each core.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
root@FriendlyWrt:~# cat /proc/interrupts
           CPU0       CPU1       CPU2       CPU3
 13:       6197       4234       4821       4771     GICv3  26 Level     arch_timer
 14:       6496      10384      10959       2961     GICv3 141 Level     rk_timer
 23:       8245          0          0          0     GICv3  78 Level     fdd40000.i2c
 58:          0          0          0         35     GICv3  59 Level     eth0
 59:          0          0          0          0     GICv3  56 Level     eth0
 62:      24315          0          0          0     GICv3  51 Level     mmc2
121:          0          0          0          0   ITS-MSI 142606344 Edge      PCIe PME
123:          0         95          0          0   ITS-MSI 524288 Edge      eth1-0
139:          0          0          8          0   ITS-MSI 524304 Edge      eth1-16
141:          0          0          0          0   ITS-MSI 524306 Edge      eth1-18
144:          0          0          0          2   ITS-MSI 524309 Edge      eth1-21
155:          0          0        748          0   ITS-MSI 143130624 Edge      eth2-0
171:          0         84          0          0   ITS-MSI 143130640 Edge      eth2-16
173:          0          0          0          0   ITS-MSI 143130642 Edge      eth2-18
176:          0          0          0          2   ITS-MSI 143130645 Edge      eth2-21
Err:          0

As you can see eth0 IRQ is mapped on CPU3 and eth1-eth2 on CPU1-2.

You can view the networking benchmarks here.

Back to TOC

3.4 Specs - Storage

There is an internal 8GB eMMC mapped in mmcblk2 where the OS was installed and an SD card slot mapped to mmcblk0. I’ve also installed a Crucial P2 1TB nvme.

This is the layout of all storage devices:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
root@FriendlyWrt:~# lsblk
NAME         MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
mmcblk2      179:0    0   7.3G  0 disk
├─mmcblk2p1  179:1    0     4M  0 part
├─mmcblk2p2  179:2    0     4M  0 part
├─mmcblk2p3  179:3    0     4M  0 part
├─mmcblk2p4  179:4    0    16M  0 part
├─mmcblk2p5  179:5    0    40M  0 part
├─mmcblk2p6  179:6    0    32M  0 part
├─mmcblk2p7  179:7    0    32M  0 part
├─mmcblk2p8  179:8    0   368M  0 part
└─mmcblk2p9  179:9    0   6.8G  0 part
mmcblk2boot0 179:32   0     4M  1 disk
mmcblk2boot1 179:64   0     4M  1 disk
mmcblk0      179:96   0 119.1G  0 disk
└─mmcblk0p1  179:97   0 119.1G  0 part
zram0        253:0    0     0B  0 disk
nvme0n1      259:0    0 931.5G  0 disk

This is how the nvme SSD drive fits on the motherboard. The nvme installed on the board

This nvme drive is much faster compared to the 1x lave PCIe2.1 interface, so I don’t expect to get the full bandwidth, but it should be close to the theoretical 500 MB/sec.

You can view the benchmarks here.

Back to TOC

4. Benchmarks

In this section I’ll list some of the benchmarks I’ve made so far. This will updated in the future with any new tests I’ll perform.

Back to TOC

4.1 Benchmarks - Storage

This is the layout of all storage devices I’ve used in the benchmark:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
root@FriendlyWrt:~# lsblk
NAME         MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
mmcblk2      179:0    0   7.3G  0 disk
├─mmcblk2p1  179:1    0     4M  0 part
├─mmcblk2p2  179:2    0     4M  0 part
├─mmcblk2p3  179:3    0     4M  0 part
├─mmcblk2p4  179:4    0    16M  0 part
├─mmcblk2p5  179:5    0    40M  0 part
├─mmcblk2p6  179:6    0    32M  0 part
├─mmcblk2p7  179:7    0    32M  0 part
├─mmcblk2p8  179:8    0   368M  0 part
└─mmcblk2p9  179:9    0   6.8G  0 part
mmcblk2boot0 179:32   0     4M  1 disk
mmcblk2boot1 179:64   0     4M  1 disk
mmcblk0      179:96   0 119.1G  0 disk
└─mmcblk0p1  179:97   0 119.1G  0 part
zram0        253:0    0     0B  0 disk
nvme0n1      259:0    0 931.5G  0 disk
└─nvme0n1p1  259:1    0 931.5G  0 part

Where:

The nvme drive is formatted as EXT4.

For the benchmark I’ve used hdparm and f3.

f3 - Fight Flash Fraud is another benchmarking tool. I’m not sure how accurate that is but I’ve used it in any case. Since f3 is not available on FriendlyWrt repos, I’ve cross-build it statically and then scp the fread and fwrite executables to the NanoPi-R5S. Have in mind that FriendlyWrt is build with musl therefore you shouldn’t build it as a dynamic ELF on your x86_64 host.

To build f3 on my host I’ve just used these commands:

1
2
3
4
5
6
/opt/toolchains/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc -std=c99 -Wall -Wextra -pedantic -MMD -ggdb   -c -o utils.o utils.c
/opt/toolchains/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc -std=c99 -Wall -Wextra -pedantic -MMD -ggdb   -c -o libflow.o libflow.c
/opt/toolchains/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc -std=c99 -Wall -Wextra -pedantic -MMD -ggdb   -c -o f3write.o f3write.c
/opt/toolchains/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc -static -o f3write utils.o libflow.o f3write.o  -lm
/opt/toolchains/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc -std=c99 -Wall -Wextra -pedantic -MMD -ggdb   -c -o f3read.o f3read.c
/opt/toolchains/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc -static -o f3read utils.o libflow.o f3read.o  -lm

Of course you need to point to the proper path of your aarch64 toolchain to build it. Finally, I’ve copied the files in the NanoPi-R5S.

1
2
scp f3read root@192.168.0.81:/root
scp f3write root@192.168.0.81:/root

TL;DR these are the results:

 hdparm (MB/sec)dd (MB/sec)f3write (MB/sec)f3read (MB/sec)
eMMC162.2215333.77114.83
SD62.895933.2557.80
nvme388.9231673.15175.02

If you want to see the details for each test then keep scrolling, otherwise click here to jump to the networking benchmarks.

Back to TOC

4.1.1 Benchmarks - Storage - hdparm

eMMC

The results for the eMMC are:

1
2
3
4
5
root@FriendlyWrt:~# hdparm -tT /dev/mmcblk2

/dev/mmcblk2:
 Timing cached reads:   2036 MB in  2.00 seconds = 1017.76 MB/sec
 Timing buffered disk reads: 488 MB in  3.01 seconds = 162.22 MB/sec

Therefore, you can expect ~160MB/sec reads from the eMMC, which I personally consider more than enough for my use case.

SD

The results for the SD card are:

1
2
3
4
5
root@FriendlyWrt:~# hdparm -tT /dev/mmcblk0

/dev/mmcblk0:
 Timing cached reads:   2046 MB in  2.00 seconds = 1022.70 MB/sec
 Timing buffered disk reads: 190 MB in  3.02 seconds =  62.89 MB/sec
nvme

The results for the nvme drive are:

1
2
3
4
5
root@FriendlyWrt:~# hdparm -tT /dev/nvme0n1p1

/dev/nvme0n1p1:
 Timing cached reads:   1920 MB in  2.00 seconds = 959.98 MB/sec
 Timing buffered disk reads: 1168 MB in  3.00 seconds = 388.92 MB/sec

The results are a far less from the theoretical advertised read speed of the drive which is 2400MB/sec. From other reviews of the drive though I’ve seen that it actually achieve 2100MB/sec read speeds, see the here for reference. But as I’ve mentioned the actual theoretical limit of the 1z PCIe is 500 MB/sec. Therefore, the actual speed is 25% less than than the maximum theoretical speed.

Back to TOC

4.1.2 Benchmarks - Storage - dd read benchmarks

eMMC
1
2
3
4
root@FriendlyWrt:~# dd if=/dev/mmcblk2 of=/dev/null bs=4k count=1000000 oflag=dsync
1000000+0 records in
1000000+0 records out
4096000000 bytes (4.1 GB, 3.8 GiB) copied, 26.7254 s, 153 MB/s
SD

The results for the SD card are:

1
2
3
4
root@FriendlyWrt:~# dd if=/dev/mmcblk0 of=/dev/null bs=4k count=1000000 oflag=dsync
1000000+0 records in
1000000+0 records out
4096000000 bytes (4.1 GB, 3.8 GiB) copied, 69.371 s, 59.0 MB/s
nvme

The results for the nvme drive are:

1
2
3
4
root@FriendlyWrt:~# dd if=/dev/nvme0n1p1 of=/dev/null bs=4k count=1000000 oflag=dsync
1000000+0 records in
1000000+0 records out
4096000000 bytes (4.1 GB, 3.8 GiB) copied, 12.9644 s, 316 MB/s

Back to TOC

4.1.3 Benchmarks - Storage - f3 benchmarks

The f3 bench mark is to be considered a similar to real-life benchmark, because the CPU needs to perform calculations while writting and reading the data. Well, again it depends the use case, but I like to consider this as the worst case real-scenario.

eMMC

The f3write results for the eMMC are:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
root@FriendlyWrt:~# ./f3write /root/f3test
F3 write 8.0
Copyright (C) 2010 Digirati Internet LTDA.
This is free software; see the source for copying conditions.

Free space: 6.68 GB
Creating file 1.h2w ... OK!
Creating file 2.h2w ... OK!
Creating file 3.h2w ... OK!
Creating file 4.h2w ... OK!
Creating file 5.h2w ... OK!
Creating file 6.h2w ... OK!
Creating file 7.h2w ... OK!
Free space: 16.00 MB
Average writing speed: 33.77 MB/s

The f3read results for the eMMC are:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
root@FriendlyWrt:~# ./f3read /root/f3test
F3 read 8.0
Copyright (C) 2010 Digirati Internet LTDA.
This is free software; see the source for copying conditions.

                  SECTORS      ok/corrupted/changed/overwritten
Validating file 1.h2w ... 2097152/        0/      0/      0
Validating file 2.h2w ... 2097152/        0/      0/      0
Validating file 3.h2w ... 2097152/        0/      0/      0
Validating file 4.h2w ... 2097152/        0/      0/      0
Validating file 5.h2w ... 2097152/        0/      0/      0
Validating file 6.h2w ... 2097152/        0/      0/      0
Validating file 7.h2w ... 1401952/        0/      0/      0

  Data OK: 6.67 GB (13984864 sectors)
Data LOST: 0.00 Byte (0 sectors)
               Corrupted: 0.00 Byte (0 sectors)
        Slightly changed: 0.00 Byte (0 sectors)
             Overwritten: 0.00 Byte (0 sectors)
Average reading speed: 114.83 MB/s
SD

The f3write results for the SD card are:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
root@FriendlyWrt:~# ./f3write --end-at=8 /mnt/sd
F3 write 8.0
Copyright (C) 2010 Digirati Internet LTDA.
This is free software; see the source for copying conditions.

Free space: 119.05 GB
Creating file 1.h2w ... OK!                         
Creating file 2.h2w ... OK!                         
Creating file 3.h2w ... OK!                         
Creating file 4.h2w ... OK!                         
Creating file 5.h2w ... OK!                         
Creating file 6.h2w ... OK!                         
Creating file 7.h2w ... OK!                         
Creating file 8.h2w ... OK!                        
Free space: 111.05 GB
Average writing speed: 33.25 MB/s

The f3read results for the SD card are:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
root@FriendlyWrt:~# ./f3read --end-at=8 /mnt/sd
F3 read 8.0
Copyright (C) 2010 Digirati Internet LTDA.
This is free software; see the source for copying conditions.

                  SECTORS      ok/corrupted/changed/overwritten
Validating file 1.h2w ... 2097152/        0/      0/      0
Validating file 2.h2w ... 2097152/        0/      0/      0
Validating file 3.h2w ... 2097152/        0/      0/      0
Validating file 4.h2w ... 2097152/        0/      0/      0
Validating file 5.h2w ... 2097152/        0/      0/      0
Validating file 6.h2w ... 2097152/        0/      0/      0
Validating file 7.h2w ... 2097152/        0/      0/      0
Validating file 8.h2w ... 2097152/        0/      0/      0

  Data OK: 8.00 GB (16777216 sectors)
Data LOST: 0.00 Byte (0 sectors)
	       Corrupted: 0.00 Byte (0 sectors)
	Slightly changed: 0.00 Byte (0 sectors)
	     Overwritten: 0.00 Byte (0 sectors)
Average reading speed: 57.80 MB/s
NVME

The f3write results for the nvme are:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
root@FriendlyWrt:~# ./f3write --end-at=8 /mnt/nvme
F3 write 8.0
Copyright (C) 2010 Digirati Internet LTDA.
This is free software; see the source for copying conditions.

Free space: 915.82 GB
Creating file 1.h2w ... OK!
Creating file 2.h2w ... OK!
Creating file 3.h2w ... OK!
Creating file 4.h2w ... OK!
Creating file 5.h2w ... OK!
Creating file 6.h2w ... OK!
Creating file 7.h2w ... OK!
Creating file 8.h2w ... OK!
Free space: 907.82 GB
Average writing speed: 73.15 MB/s

The f3read results for the nvme are:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
root@FriendlyWrt:~# ./f3read --end-at=8 /mnt/nvme
F3 read 8.0
Copyright (C) 2010 Digirati Internet LTDA.
This is free software; see the source for copying conditions.

                  SECTORS      ok/corrupted/changed/overwritten
Validating file 1.h2w ... 2097152/        0/      0/      0
Validating file 2.h2w ... 2097152/        0/      0/      0
Validating file 3.h2w ... 2097152/        0/      0/      0
Validating file 4.h2w ... 2097152/        0/      0/      0
Validating file 5.h2w ... 2097152/        0/      0/      0
Validating file 6.h2w ... 2097152/        0/      0/      0
Validating file 7.h2w ... 2097152/        0/      0/      0
Validating file 8.h2w ... 2097152/        0/      0/      0

  Data OK: 8.00 GB (16777216 sectors)
Data LOST: 0.00 Byte (0 sectors)
               Corrupted: 0.00 Byte (0 sectors)
        Slightly changed: 0.00 Byte (0 sectors)
             Overwritten: 0.00 Byte (0 sectors)
Average reading speed: 175.02 MB/s

Back to TOC

4.2 Benchmarks - Networking

This is a TL;DR table with all the results. If you want to see more details for each test then keep scrolling to get a more deep dive.

 Test case 1 (Gbits/sec)Test case 2 (Gbits/sec)Test case 3 (Gbits/sec)
R5S -> M1 (CAT.6a)1.49TBDTBD
M1 -> R5S (CAT.6a)2.14TBDTBD
R5S <-> M1 (CAT.6a)1.37 (TX) / 159 (RX)TBDTBD
R5S -> M1 (CAT.7)1.54TBDTBD
M1 -> R5S (CAT.7)2.24TBDTBD
R5S <-> M1 (CAT.7)1.24 (TX) / 153 (RX)TBDTBD

From the above table it’s interesting to know that the cable didn’t do much of a difference. This is somehow expected, because CAT.6a is rated only 100MHz less, which is capable of 2.5G and furthermore, since the CAT.6a cable is a patch cable it’s only 20cm in length, which means that it can meet its specs.

The 3 different test cases are described below.

Testing a single 2.5G port

This is the first test case:

In the above diagram you can see that the Macbook Air M1 is connected via the USB-C to 2.5G ethernet adapter to the 2.5G LAN2 port of the NanoPi-R5S.

I’ll run this test with 2 different cables:

  • 20cm CAT.6a rated for 500MHz
  • 100cm CAT.7 cable rated for 600MHz

The reason for using two different cables is to check if the different cable category affects the actual bandwidth that the R5S can provide.

To perform this test, I’ve disabled the bridge interface from the web interface and the then I’ve assigned a static IP on the eth2 interface and then brought it up.

1
2
ip addr add 192.168.2.10/24 dev eth2
ip link set dev eth2 up

This resulted in the following config:

1
2
3
4
5
6
7
8
9
eth2      Link encap:Ethernet  HWaddr 96:F4:C8:9E:05:F4
          inet addr:192.168.2.10  Bcast:0.0.0.0  Mask:255.255.255.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:127

Test case 2 - 2.5G to 2.5G port

This is the second test case diagram:

In this case, I’ll test the interconnection between the 2.5G ports using two different external hosts.

This test is not done yet, as I need to buy a second 2.5G USB-C to ethernet interface.

Test case 3 - All ports

This is the second test case diagram:

In this case, I’ll test all the ports at the same time, which pretty much emulated a router usage

This test is not done yet, as I need to buy a second 2.5G USB-C to ethernet interface.

4.2.1 Benchmarks - Networking - Test case 1 - CAT6A

This test is performed with a CAT.6A patch cable of 20cm, which is characterized for 500MHz.

Back to TOC

4.2.1.1 Benchmarks - Networking - Test case 1 - CAT6A - R5S->M1

The first test is running for 2 mins and with 2 parallel TCP streams

HostCommand
Mac M1 w/ USB-C 2.5Giperf3 -s
NanoPi R5S (LAN2)iperf3 -c 192.168.2.20 -t 120 -d -P 2
Click here to view full console output…
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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
send_results
{
        "cpu_util_total":       99.894594260395,
        "cpu_util_user":        2.53878014645815,
        "cpu_util_system":      97.3558149471838,
        "sender_has_retransmits":       1,
        "congestion_used":      "bbr",
        "streams":      [{
                        "id":   1,
                        "bytes":        11559632896,
                        "retransmits":  2,
                        "jitter":       0,
                        "errors":       0,
                        "packets":      0,
                        "start_time":   0,
                        "end_time":     120.000356
                }, {
                        "id":   3,
                        "bytes":        10766254080,
                        "retransmits":  0,
                        "jitter":       0,
                        "errors":       0,
                        "packets":      0,
                        "start_time":   0,
                        "end_time":     120.000578
                }]
}
get_results
{
        "cpu_util_total":       12.895311139359134,
        "cpu_util_user":        1.0562188759244822,
        "cpu_util_system":      11.839089763429422,
        "sender_has_retransmits":       -1,
        "streams":      [{
                        "id":   1,
                        "bytes":        11559632896,
                        "retransmits":  -1,
                        "jitter":       0,
                        "errors":       0,
                        "packets":      0,
                        "start_time":   0,
                        "end_time":     119.99968
                }, {
                        "id":   3,
                        "bytes":        10766254080,
                        "retransmits":  -1,
                        "jitter":       0,
                        "errors":       0,
                        "packets":      0,
                        "start_time":   0,
                        "end_time":     119.999681
                }]
}
interval_len 0.994603 bytes_transferred 102760448
interval forces keep
interval_len 0.994474 bytes_transferred 85203344
interval forces keep
- - - - - - - - - - - - - - - - - - - - - - - - -
[  5] 119.01-120.00 sec  98.0 MBytes   827 Mbits/sec    0    348 KBytes
[  7] 119.01-120.00 sec  81.3 MBytes   685 Mbits/sec    0    331 KBytes
[SUM] 119.01-120.00 sec   179 MBytes  1.51 Gbits/sec    0
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-120.00 sec  10.8 GBytes   771 Mbits/sec    2             sender
[  5]   0.00-120.00 sec  10.8 GBytes   771 Mbits/sec                  receiver
[  7]   0.00-120.00 sec  10.0 GBytes   718 Mbits/sec    0             sender
[  7]   0.00-120.00 sec  10.0 GBytes   718 Mbits/sec                  receiver
[SUM]   0.00-120.00 sec  20.8 GBytes  1.49 Gbits/sec    2             sender
[SUM]   0.00-120.00 sec  20.8 GBytes  1.49 Gbits/sec                  receiver

Back to TOC

4.2.1.2 Benchmarks - Networking - Test case 1 - CAT6A - M1->R5S

The second test is running for 120 secs, 2x parallel streams and in reverse mode.

Reverse mode means that the Mac M1 with the USB-C dongle will send data to the NanoPi R4S.

HostCommand
Mac M1 w/ USB-C 2.5Giperf3 -s
NanoPi R4S (LAN2)iperf3 -c 192.168.2.20 -t 120 -d -P 2 -R
Click here to view full console output…
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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
send_results
{
        "cpu_util_total":       96.7729033803073,
        "cpu_util_user":        1.3110703132948434,
        "cpu_util_system":      95.461833900263372,
        "sender_has_retransmits":       -1,
        "congestion_used":      "bbr",
        "streams":      [{
                        "id":   1,
                        "bytes":        16135906864,
                        "retransmits":  -1,
                        "jitter":       0,
                        "errors":       0,
                        "packets":      0,
                        "start_time":   0,
                        "end_time":     120.000615
                }, {
                        "id":   3,
                        "bytes":        16003816384,
                        "retransmits":  -1,
                        "jitter":       0,
                        "errors":       0,
                        "packets":      0,
                        "start_time":   0,
                        "end_time":     120.000812
                }]
}
get_results
{
        "cpu_util_total":       79.228332785308552,
        "cpu_util_user":        0.41793856948410563,
        "cpu_util_system":      78.8103925494625,
        "sender_has_retransmits":       0,
        "streams":      [{
                        "id":   1,
                        "bytes":        16140101168,
                        "retransmits":  -1,
                        "jitter":       0,
                        "errors":       0,
                        "packets":      0,
                        "start_time":   0,
                        "end_time":     120.02186
                }, {
                        "id":   3,
                        "bytes":        16008010688,
                        "retransmits":  -1,
                        "jitter":       0,
                        "errors":       0,
                        "packets":      0,
                        "start_time":   0,
                        "end_time":     120.02186
                }]
}
interval_len 1.000521 bytes_transferred 108068584
interval forces keep
interval_len 1.000606 bytes_transferred 85744768
interval forces keep
- - - - - - - - - - - - - - - - - - - - - - - - -
[  5] 119.00-120.00 sec   103 MBytes   864 Mbits/sec
[  7] 119.00-120.00 sec  81.8 MBytes   686 Mbits/sec
[SUM] 119.00-120.00 sec   185 MBytes  1.55 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-120.02 sec  15.0 GBytes  1.08 Gbits/sec                  sender
[  5]   0.00-120.00 sec  15.0 GBytes  1.08 Gbits/sec                  receiver
[  7]   0.00-120.02 sec  14.9 GBytes  1.07 Gbits/sec                  sender
[  7]   0.00-120.00 sec  14.9 GBytes  1.07 Gbits/sec                  receiver
[SUM]   0.00-120.02 sec  29.9 GBytes  2.14 Gbits/sec                  sender
[SUM]   0.00-120.00 sec  29.9 GBytes  2.14 Gbits/sec                  receiver

As you can see, the reverse mode is much faster and achieves 2.14 Gbits/sec!

Back to TOC

4.2.1.3 Benchmarks - Networking - Test case 1 - CAT6A - R5S<->M1

The second test is running for 120 secs, 2x parallel streams and in bidirectional mode.

Bidirectional mode means that the Mac M1 with the USB-C dongle will send data to the NanoPi R5S and then the opposite in full-duplex mode. This is the worst of the worsts case scenario you can get.

HostCommand
Mac M1 w/ USB-C 2.5Giperf3 -s
NanoPi R5S (LAN2)iperf3 -c 192.168.2.20 -t 120 -d -P 2 –bidir
Click here to view full console output…
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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
send_results
{
        "cpu_util_total":       99.908560731364176,
        "cpu_util_user":        2.80259866958722,
        "cpu_util_system":      97.105964561346923,
        "sender_has_retransmits":       1,
        "congestion_used":      "bbr",
        "streams":      [{
                        "id":   1,
                        "bytes":        9695789056,
                        "retransmits":  0,
                        "jitter":       0,
                        "errors":       0,
                        "packets":      0,
                        "start_time":   0,
                        "end_time":     120.000561
                }, {
                        "id":   3,
                        "bytes":        10881466368,
                        "retransmits":  0,
                        "jitter":       0,
                        "errors":       0,
                        "packets":      0,
                        "start_time":   0,
                        "end_time":     120.000648
                }, {
                        "id":   4,
                        "bytes":        1173286984,
                        "retransmits":  -1,
                        "jitter":       0,
                        "errors":       0,
                        "packets":      0,
                        "start_time":   0,
                        "end_time":     120.000871
                }, {
                        "id":   5,
                        "bytes":        1173307256,
                        "retransmits":  -1,
                        "jitter":       0,
                        "errors":       0,
                        "packets":      0,
                        "start_time":   0,
                        "end_time":     120.00124
                }]
}
get_results
{
        "cpu_util_total":       11.915361615820213,
        "cpu_util_user":        1.0039928270691434,
        "cpu_util_system":      10.911359622385747,
        "sender_has_retransmits":       0,
        "streams":      [{
                        "id":   1,
                        "bytes":        9695789056,
                        "retransmits":  -1,
                        "jitter":       0,
                        "errors":       0,
                        "packets":      0,
                        "start_time":   0,
                        "end_time":     120.003843
                }, {
                        "id":   3,
                        "bytes":        10881466368,
                        "retransmits":  -1,
                        "jitter":       0,
                        "errors":       0,
                        "packets":      0,
                        "start_time":   0,
                        "end_time":     120.003843
                }, {
                        "id":   4,
                        "bytes":        1192792280,
                        "retransmits":  -1,
                        "jitter":       0,
                        "errors":       0,
                        "packets":      0,
                        "start_time":   0,
                        "end_time":     120.003843
                }, {
                        "id":   5,
                        "bytes":        1185447680,
                        "retransmits":  -1,
                        "jitter":       0,
                        "errors":       0,
                        "packets":      0,
                        "start_time":   0,
                        "end_time":     120.003843
                }]
}
interval_len 0.988212 bytes_transferred 79691776
interval forces keep
interval_len 0.988202 bytes_transferred 92405760
interval forces keep
interval_len 0.988202 bytes_transferred 9437184
interval forces keep
interval_len 0.988202 bytes_transferred 9437184
interval forces keep
- - - - - - - - - - - - - - - - - - - - - - - - -
[  5][TX-C] 119.01-120.00 sec  76.0 MBytes   645 Mbits/sec    0    320 KBytes
[  7][TX-C] 119.01-120.00 sec  88.1 MBytes   748 Mbits/sec    0    322 KBytes
[SUM][TX-C] 119.01-120.00 sec   164 MBytes  1.39 Gbits/sec    0
[  9][RX-C] 119.01-120.00 sec  9.00 MBytes  76.4 Mbits/sec
[ 11][RX-C] 119.01-120.00 sec  9.00 MBytes  76.4 Mbits/sec
[SUM][RX-C] 119.01-120.00 sec  18.0 MBytes   153 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID][Role] Interval           Transfer     Bitrate         Retr
[  5][TX-C]   0.00-120.00 sec  9.03 GBytes   646 Mbits/sec    0             sender
[  5][TX-C]   0.00-120.00 sec  9.03 GBytes   646 Mbits/sec                  receiver
[  7][TX-C]   0.00-120.00 sec  10.1 GBytes   725 Mbits/sec    0             sender
[  7][TX-C]   0.00-120.00 sec  10.1 GBytes   725 Mbits/sec                  receiver
[SUM][TX-C]   0.00-120.00 sec  19.2 GBytes  1.37 Gbits/sec    0             sender
[SUM][TX-C]   0.00-120.00 sec  19.2 GBytes  1.37 Gbits/sec                  receiver
[  9][RX-C]   0.00-120.00 sec  1.11 GBytes  79.5 Mbits/sec                  sender
[  9][RX-C]   0.00-120.00 sec  1.09 GBytes  78.2 Mbits/sec                  receiver
[ 11][RX-C]   0.00-120.00 sec  1.10 GBytes  79.0 Mbits/sec                  sender
[ 11][RX-C]   0.00-120.00 sec  1.09 GBytes  78.2 Mbits/sec                  receiver
[SUM][RX-C]   0.00-120.00 sec  2.21 GBytes   159 Mbits/sec                  sender
[SUM][RX-C]   0.00-120.00 sec  2.19 GBytes   156 Mbits/sec                  receiver
4.2.1.4 Benchmarks - Networking - Test case 1 - CAT6A - packet generation capabilities - M1->R5S

This benchmark was proposed from tkaiser in order to check the packet generation capabilities which would indicate the package processing speed if the device was used as a firewall. You can read more about it here

In the first test the M1 will be the sender

HostCommand
Mac M1 w/ USB-C 2.5Giperf3 -s
NanoPi R5S (LAN2)iperf3 -u -c 192.168.2.20 -t 120 -R -O 5 -f m -b 2500M –length {size}

Notice the -R in the client command, which means reverse, so the M1 will be the sender/client.

This is the table with the results of the various sizes.

Datagram lenghtSender bitrateSender jitterReceiver bitrateReceiver jitter
1620.3 Mbits/sec0.000 ms12.4 Mbits/sec0.013 ms
100125 Mbits/sec0.000 ms75.9 Mbits/sec0.009 ms
300367 Mbits/sec0.000 ms222 Mbits/sec0.007 ms
500626 Mbits/sec0.000 ms352 Mbits/sec0.016 ms
700901 Mbits/sec0.000 ms512 Mbits/sec0.010 ms
9001164 Mbits/sec0.000 ms653 Mbits/sec0.010 ms
11001405 Mbits/sec0.000 ms774 Mbits/sec0.008 ms
13001651 Mbits/sec0.000 ms901 Mbits/sec0.007 ms
14721821 Mbits/sec0.000 ms1019 Mbits/sec0.007 ms
15001533 Mbits/sec0.000 ms510 Mbits/sec0.016 ms

The full results from the console output are listed next

Click here to view full console output…
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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
iperf3 -u -c 192.168.2.20 -t 120 -R -O 5 -f m -b 2500M --length 16
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-119.99 sec   290 MBytes  20.3 Mbits/sec  0.000 ms  0/19000125 (0%)  sender
[  5]   0.00-120.00 sec   177 MBytes  12.4 Mbits/sec  0.013 ms  7414310/18998651 (39%)  receiver


iperf3 -u -c 192.168.2.20 -t 120 -R -O 5 -f m -b 2500M --length 100
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-119.99 sec  1.75 GBytes   125 Mbits/sec  0.000 ms  0/18805217 (0%)  sender
[SUM]  0.0-120.0 sec  15 datagrams received out-of-order
[  5]   0.00-120.00 sec  1.06 GBytes  75.9 Mbits/sec  0.009 ms  7414395/18803684 (39%)  receiver


iperf3 -u -c 192.168.2.20 -t 120 -R -O 5 -f m -b 2500M --length 300
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-119.99 sec  5.13 GBytes   367 Mbits/sec  0.000 ms  0/18367841 (0%)  sender
[  5]   0.00-120.00 sec  3.10 GBytes   222 Mbits/sec  0.007 ms  7263672/18366124 (40%)  receiver


iperf3 -u -c 192.168.2.20 -t 120 -O 5 -f m -b 2500M --length 500
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-119.99 sec  8.75 GBytes   626 Mbits/sec  0.000 ms  0/18793311 (0%)  sender
[SUM]  0.0-120.0 sec  10 datagrams received out-of-order
[  5]   0.00-120.00 sec  4.92 GBytes   352 Mbits/sec  0.016 ms  8228208/18791810 (44%)  receiver


iperf3 -u -c 192.168.2.20 -t 120 -O 5 -f m -b 2500M --length 700
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-120.02 sec  12.6 GBytes   901 Mbits/sec  0.000 ms  0/19321216 (0%)  sender
[  5]   0.00-120.00 sec  7.15 GBytes   512 Mbits/sec  0.010 ms  8348170/19319641 (43%)  receiver


iperf3 -u -c 192.168.2.20 -t 120 -O 5 -f m -b 2500M --length 900
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-120.00 sec  16.3 GBytes  1164 Mbits/sec  0.000 ms  0/19398660 (0%)  sender
[  5]   0.00-120.00 sec  9.13 GBytes   653 Mbits/sec  0.010 ms  8507587/19396858 (44%)  receiver


iperf3 -u -c 192.168.2.20 -t 120 -O 5 -f m -b 2500M --length 1100
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-120.00 sec  19.6 GBytes  1405 Mbits/sec  0.000 ms  0/19157537 (0%)  sender
[  5]   0.00-120.00 sec  10.8 GBytes   774 Mbits/sec  0.008 ms  8598178/19155709 (45%)  receiver


iperf3 -u -c 192.168.2.20 -t 120 -O 5 -f m -b 2500M --length 1300
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-120.00 sec  23.1 GBytes  1651 Mbits/sec  0.000 ms  0/19051115 (0%)  sender
[SUM]  0.0-120.0 sec  15 datagrams received out-of-order
[  5]   0.00-120.00 sec  12.6 GBytes   901 Mbits/sec  0.007 ms  8654520/19049379 (45%)  receiver


iperf3 -u -c 192.168.2.20 -t 120 -O 5 -f m -b 2500M --length 1472
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-120.00 sec  25.4 GBytes  1821 Mbits/sec  0.000 ms  0/18554815 (0%)  sender
[SUM]  0.0-120.0 sec  15 datagrams received out-of-order
[  5]   0.00-120.00 sec  14.2 GBytes  1019 Mbits/sec  0.007 ms  8173669/18553316 (44%)  receiver


iperf3 -u -c 192.168.2.20 -t 120 -O 5 -f m -b 2500M --length 1500
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-120.03 sec  21.4 GBytes  1533 Mbits/sec  0.000 ms  0/15342241 (0%)  sender
[SUM]  0.0-120.0 sec  5 datagrams received out-of-order
[  5]   0.00-120.00 sec  7.13 GBytes   510 Mbits/sec  0.016 ms  10236599/15338533 (67%)  receiver

Back to TOC

4.2.1.4 Benchmarks - Networking - Test case 1 - CAT6A - packet generation capabilities - R5S->M1

Read the test description from above In this test the R5S will be the sender.

HostCommand
Mac M1 w/ USB-C 2.5Giperf3 -s
NanoPi R5S (LAN2)iperf3 -u -c 192.168.2.20 -t 120 -O 5 -f m -b 2500M –length {size}

This is the table with the results of the various sizes.

Datagram lenghtSender bitrateSender jitterReceiver bitrateReceiver jitter
164.23 Mbits/sec0.000 ms4.23 Mbits/sec0.031 ms
10027.4 Mbits/sec0.000 ms27.3 Mbits/sec0.033 ms
30070.1 Mbits/sec0.000 ms70.1 Mbits/sec0.026 ms
500117 Mbits/sec0.000 ms117 Mbits/sec0.032 ms
700190 Mbits/sec0.000 ms190 Mbits/sec0.032 ms
900243 Mbits/sec0.000 ms243 Mbits/sec0.030 ms
1100254 Mbits/sec0.000 ms254 Mbits/sec0.026 ms
1300349 Mbits/sec0.000 ms349 Mbits/sec0.029 ms
1472395 Mbits/sec0.000 ms394 Mbits/sec0.017 ms
1500321 Mbits/sec0.000 ms320 Mbits/sec0.037 ms

From the above table and comparing with the previous table where the sender is the M1, it’s obvious that the RK3568 does suffer when it comes to packet generation capabilities. At least compare to the M1 SoC, which is not really a fair comparison.

The full results from the console output are listed next.

Click here to view full console output…
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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
iperf3 -u -c 192.168.2.20 -t 120 -O 5 -f m -b 2500M --length 16
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-120.00 sec  60.6 MBytes  4.23 Mbits/sec  0.000 ms  0/3970147 (0%)  sender
[  5]   0.00-120.00 sec  60.6 MBytes  4.23 Mbits/sec  0.031 ms  0/3970147 (0%)  receiver

iperf3 -u -c 192.168.2.20 -t 120 -O 5 -f m -b 2500M --length 100
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-120.00 sec   392 MBytes  27.4 Mbits/sec  0.000 ms  0/4106500 (0%)  sender
[  5]   0.00-120.00 sec   391 MBytes  27.3 Mbits/sec  0.033 ms  5084/4106500 (0.12%)  receiver


iperf3 -u -c 192.168.2.20 -t 120 -O 5 -f m -b 2500M --length 300
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-120.00 sec  1002 MBytes  70.1 Mbits/sec  0.000 ms  0/3503348 (0%)  sender
[  5]   0.00-120.00 sec  1002 MBytes  70.1 Mbits/sec  0.026 ms  0/3503348 (0%)  receiver


iperf3 -u -c 192.168.2.20 -t 120 -O 5 -f m -b 2500M --length 500
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-120.00 sec  1.63 GBytes   117 Mbits/sec  0.000 ms  0/3495496 (0%)  sender
[  5]   0.00-120.00 sec  1.63 GBytes   117 Mbits/sec  0.032 ms  0/3495496 (0%)  receiver


iperf3 -u -c 192.168.2.20 -t 120 -O 5 -f m -b 2500M --length 700
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-120.00 sec  2.66 GBytes   190 Mbits/sec  0.000 ms  0/4079112 (0%)  sender
[  5]   0.00-120.00 sec  2.66 GBytes   190 Mbits/sec  0.032 ms  0/4079112 (0%)  receiver

iperf3 -u -c 192.168.2.20 -t 120 -O 5 -f m -b 2500M --length 900
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-120.00 sec  3.40 GBytes   243 Mbits/sec  0.000 ms  0/4052440 (0%)  sender
[  5]   0.00-120.00 sec  3.40 GBytes   243 Mbits/sec  0.030 ms  0/4052440 (0%)  receiver

iperf3 -u -c 192.168.2.20 -t 120 -O 5 -f m -b 2500M --length 1100
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-120.00 sec  3.55 GBytes   254 Mbits/sec  0.000 ms  0/3467852 (0%)  sender
[  5]   0.00-120.00 sec  3.55 GBytes   254 Mbits/sec  0.026 ms  0/3467852 (0%)  receiver

iperf3 -u -c 192.168.2.20 -t 120 -O 5 -f m -b 2500M --length 1300
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-120.00 sec  4.88 GBytes   349 Mbits/sec  0.000 ms  0/4031620 (0%)  sender
[  5]   0.00-120.00 sec  4.88 GBytes   349 Mbits/sec  0.029 ms  129/4031619 (0.0032%)  receiver

iperf3 -u -c 192.168.2.20 -t 120 -O 5 -f m -b 2500M --length 1472
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-120.00 sec  5.51 GBytes   395 Mbits/sec  0.000 ms  0/4021503 (0%)  sender
[  5]   0.00-120.00 sec  5.51 GBytes   394 Mbits/sec  0.017 ms  3951/4021503 (0.098%)  receiver

iperf3 -u -c 192.168.2.20 -t 120 -O 5 -f m -b 2500M --length 1500
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-120.00 sec  4.48 GBytes   321 Mbits/sec  0.000 ms  0/3206860 (0%)  sender
[  5]   0.00-120.00 sec  4.48 GBytes   320 Mbits/sec  0.037 ms  2400/3206860 (0.075%)  receiver

Back to TOC

4.2.2 Benchmarks - Networking - Test case 1 - CAT7

This test is performed with a CAT.7 cable of 1m, which is characterized for 500MHz.

Back to TOC

4.2.2.1 Benchmarks - Networking - Test case 1 - CAT7 - R5S->M1

The first test is running for 2 mins and with 2 parallel TCP streams

HostCommand
Mac M1 w/ USB-C 2.5Giperf3 -s
NanoPi R5S (LAN2)iperf3 -c 192.168.2.20 -t 120 -d -P 2
Click here to view full console output…
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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
send_results
{
	"cpu_util_total":	99.812409325112256,
	"cpu_util_user":	2.6527853033374558,
	"cpu_util_system":	97.159684845599841,
	"sender_has_retransmits":	1,
	"congestion_used":	"bbr",
	"streams":	[{
			"id":	1,
			"bytes":	11759124480,
			"retransmits":	0,
			"jitter":	0,
			"errors":	0,
			"packets":	0,
			"start_time":	0,
			"end_time":	120.006756
		}, {
			"id":	3,
			"bytes":	11332616192,
			"retransmits":	1,
			"jitter":	0,
			"errors":	0,
			"packets":	0,
			"start_time":	0,
			"end_time":	120.00685
		}]
}
get_results
{
	"cpu_util_total":	15.338762276897119,
	"cpu_util_user":	1.136211834977197,
	"cpu_util_system":	14.202547942040564,
	"sender_has_retransmits":	-1,
	"streams":	[{
			"id":	1,
			"bytes":	11759124480,
			"retransmits":	-1,
			"jitter":	0,
			"errors":	0,
			"packets":	0,
			"start_time":	0,
			"end_time":	120.005647
		}, {
			"id":	3,
			"bytes":	11332616192,
			"retransmits":	-1,
			"jitter":	0,
			"errors":	0,
			"packets":	0,
			"start_time":	0,
			"end_time":	120.005648
		}]
}
interval_len 0.995712 bytes_transferred 85983232
interval forces keep
interval_len 0.995767 bytes_transferred 75104256
interval forces keep
- - - - - - - - - - - - - - - - - - - - - - - - -
[  5] 119.01-120.01 sec  82.0 MBytes   691 Mbits/sec    0    334 KBytes       
[  7] 119.01-120.01 sec  71.6 MBytes   603 Mbits/sec    0    320 KBytes       
[SUM] 119.01-120.01 sec   154 MBytes  1.29 Gbits/sec    0             
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-120.01 sec  11.0 GBytes   784 Mbits/sec    0             sender
[  5]   0.00-120.01 sec  11.0 GBytes   784 Mbits/sec                  receiver
[  7]   0.00-120.01 sec  10.6 GBytes   755 Mbits/sec    1             sender
[  7]   0.00-120.01 sec  10.6 GBytes   755 Mbits/sec                  receiver
[SUM]   0.00-120.01 sec  21.5 GBytes  1.54 Gbits/sec    1             sender
[SUM]   0.00-120.01 sec  21.5 GBytes  1.54 Gbits/sec                  receiver

Back to TOC

4.2.2.2 Benchmarks - Networking - Test case 1 - CAT7 - M1->R5S

The second test is running for 120 secs, 2x parallel streams and in reverse mode.

Reverse mode means that the Mac M1 with the USB-C dongle will send data to the NanoPi R5S.

HostCommand
Mac M1 w/ USB-C 2.5Giperf3 -s
NanoPi R5S (LAN2)iperf3 -c 192.168.2.20 -t 120 -d -P 2 -R
Click here to view full console output…
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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
send_results
{
	"cpu_util_total":	97.7357373414333,
	"cpu_util_user":	1.2039985094448957,
	"cpu_util_system":	96.5317404979715,
	"sender_has_retransmits":	-1,
	"congestion_used":	"bbr",
	"streams":	[{
			"id":	1,
			"bytes":	17308450816,
			"retransmits":	-1,
			"jitter":	0,
			"errors":	0,
			"packets":	0,
			"start_time":	0,
			"end_time":	120.000334
		}, {
			"id":	3,
			"bytes":	16213082112,
			"retransmits":	-1,
			"jitter":	0,
			"errors":	0,
			"packets":	0,
			"start_time":	0,
			"end_time":	120.000469
		}]
}
get_results
{
	"cpu_util_total":	91.025220143360031,
	"cpu_util_user":	0.27001592327244373,
	"cpu_util_system":	90.755205053369764,
	"sender_has_retransmits":	0,
	"streams":	[{
			"id":	1,
			"bytes":	17315659776,
			"retransmits":	-1,
			"jitter":	0,
			"errors":	0,
			"packets":	0,
			"start_time":	0,
			"end_time":	120.007316
		}, {
			"id":	3,
			"bytes":	16220422144,
			"retransmits":	-1,
			"jitter":	0,
			"errors":	0,
			"packets":	0,
			"start_time":	0,
			"end_time":	120.007317
		}]
}
interval_len 1.000254 bytes_transferred 142696864
interval forces keep
interval_len 1.000248 bytes_transferred 142618672
interval forces keep
- - - - - - - - - - - - - - - - - - - - - - - - -
[  5] 119.00-120.00 sec   136 MBytes  1.14 Gbits/sec                  
[  7] 119.00-120.00 sec   136 MBytes  1.14 Gbits/sec                  
[SUM] 119.00-120.00 sec   272 MBytes  2.28 Gbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-120.01 sec  16.1 GBytes  1.15 Gbits/sec                  sender
[  5]   0.00-120.00 sec  16.1 GBytes  1.15 Gbits/sec                  receiver
[  7]   0.00-120.01 sec  15.1 GBytes  1.08 Gbits/sec                  sender
[  7]   0.00-120.00 sec  15.1 GBytes  1.08 Gbits/sec                  receiver
[SUM]   0.00-120.01 sec  31.2 GBytes  2.24 Gbits/sec                  sender
[SUM]   0.00-120.00 sec  31.2 GBytes  2.23 Gbits/sec                  receiver

Back to TOC

As you can see, the reverse mode is much faster and achieves 2.14 Gbits/sec!

4.2.2.3 Benchmarks - Networking - Test case 1 - CAT7 - R5S<->M1

The second test is running for 120 secs, 2x parallel streams and in bidirectional mode.

Bidirectional mode means that the Mac M1 with the USB-C dongle will send data to the NanoPi R5S and then the opposite in full-duplex mode. This is the worst of the worsts case scenario you can get.

HostCommand
Mac M1 w/ USB-C 2.5Giperf3 -s
NanoPi R5S (LAN2)iperf3 -c 192.168.2.20 -t 120 -d -P 2 –bidir
Click here to view full console output…
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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
send_results
{
	"cpu_util_total":	99.5510184837019,
	"cpu_util_user":	2.3612486345427461,
	"cpu_util_system":	97.189769849159134,
	"sender_has_retransmits":	1,
	"congestion_used":	"bbr",
	"streams":	[{
			"id":	1,
			"bytes":	9466937344,
			"retransmits":	0,
			"jitter":	0,
			"errors":	0,
			"packets":	0,
			"start_time":	0,
			"end_time":	120.004446
		}, {
			"id":	3,
			"bytes":	9086697472,
			"retransmits":	0,
			"jitter":	0,
			"errors":	0,
			"packets":	0,
			"start_time":	0,
			"end_time":	120.004526
		}, {
			"id":	4,
			"bytes":	1132543864,
			"retransmits":	-1,
			"jitter":	0,
			"errors":	0,
			"packets":	0,
			"start_time":	0,
			"end_time":	120.004553
		}, {
			"id":	5,
			"bytes":	1132290408,
			"retransmits":	-1,
			"jitter":	0,
			"errors":	0,
			"packets":	0,
			"start_time":	0,
			"end_time":	120.004575
		}]
}
get_results
{
	"cpu_util_total":	23.939422090232419,
	"cpu_util_user":	1.2419087432296971,
	"cpu_util_system":	22.69750334814001,
	"sender_has_retransmits":	0,
	"streams":	[{
			"id":	1,
			"bytes":	9466937344,
			"retransmits":	-1,
			"jitter":	0,
			"errors":	0,
			"packets":	0,
			"start_time":	0,
			"end_time":	120.013534
		}, {
			"id":	3,
			"bytes":	9086697472,
			"retransmits":	-1,
			"jitter":	0,
			"errors":	0,
			"packets":	0,
			"start_time":	0,
			"end_time":	120.013536
		}, {
			"id":	4,
			"bytes":	1141834968,
			"retransmits":	-1,
			"jitter":	0,
			"errors":	0,
			"packets":	0,
			"start_time":	0,
			"end_time":	120.013536
		}, {
			"id":	5,
			"bytes":	1147607128,
			"retransmits":	-1,
			"jitter":	0,
			"errors":	0,
			"packets":	0,
			"start_time":	0,
			"end_time":	120.013537
		}]
}
interval_len 0.997747 bytes_transferred 92536832
interval forces keep
interval_len 0.997751 bytes_transferred 60555264
interval forces keep
interval_len 0.997762 bytes_transferred 10092544
interval forces keep
interval_len 0.997770 bytes_transferred 10092544
interval forces keep
- - - - - - - - - - - - - - - - - - - - - - - - -
[  5][TX-C] 119.01-120.00 sec  88.2 MBytes   742 Mbits/sec    0    320 KBytes       
[  7][TX-C] 119.01-120.00 sec  57.8 MBytes   486 Mbits/sec    0    345 KBytes       
[SUM][TX-C] 119.01-120.00 sec   146 MBytes  1.23 Gbits/sec    0             
[  9][RX-C] 119.01-120.00 sec  9.62 MBytes  80.9 Mbits/sec                  
[ 11][RX-C] 119.01-120.00 sec  9.62 MBytes  80.9 Mbits/sec                  
[SUM][RX-C] 119.01-120.00 sec  19.2 MBytes   162 Mbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID][Role] Interval           Transfer     Bitrate         Retr
[  5][TX-C]   0.00-120.00 sec  8.82 GBytes   631 Mbits/sec    0             sender
[  5][TX-C]   0.00-120.01 sec  8.82 GBytes   631 Mbits/sec                  receiver
[  7][TX-C]   0.00-120.00 sec  8.46 GBytes   606 Mbits/sec    0             sender
[  7][TX-C]   0.00-120.01 sec  8.46 GBytes   606 Mbits/sec                  receiver
[SUM][TX-C]   0.00-120.00 sec  17.3 GBytes  1.24 Gbits/sec    0             sender
[SUM][TX-C]   0.00-120.01 sec  17.3 GBytes  1.24 Gbits/sec                  receiver
[  9][RX-C]   0.00-120.00 sec  1.06 GBytes  76.1 Mbits/sec                  sender
[  9][RX-C]   0.00-120.01 sec  1.05 GBytes  75.5 Mbits/sec                  receiver
[ 11][RX-C]   0.00-120.00 sec  1.07 GBytes  76.5 Mbits/sec                  sender
[ 11][RX-C]   0.00-120.01 sec  1.05 GBytes  75.5 Mbits/sec                  receiver
[SUM][RX-C]   0.00-120.00 sec  2.13 GBytes   153 Mbits/sec                  sender
[SUM][RX-C]   0.00-120.01 sec  2.11 GBytes   151 Mbits/sec                  receiver

Back to TOC

4.2.3 Benchmarks - Networking - Test case 2

This is a placeholder. I can’t perform the test yet, because I don’t have a second 2.5G adapter. This will be done when I get a second adapter.

Back to TOC

4.2.4 Benchmarks - Networking - Test case 3

This is a placeholder. I can’t perform the test yet, because I don’t have a second 2.5G adapter. This will be done when I get a second adapter.

Back to TOC

5. Power consumption and thermals

I’ve measured the power consumption and thermal in two states: idle and stress.

I’ve used a USB power supply, capable of 3A at 5V and a USB current meter to measure the current and voltage.

5.1 Power consumption and thermals - Idle

NanoPi-R5S while in idle, consumes 3.59W as you can see from the photo.

Power consumption (idle)

With a room temperature of 22C, the idle temperature was:

 Temperature (C)
Thermal zone 039.5
Thermal zone 142.5

5.2 Power consumption and thermals - Stress

In order to test the power consumption and the thermals, I’ve tried to stress the Nanopi-R5S, with 3 parallel tasks. To do that I’ve opened 3 ssh sessions on the SBC and then I’ve run those commands

Stress the nvme drive

1
./f3write /mnt/nvme

Stress the network:

1
iperf3 -c 192.168.2.20 -t 1200 -d -P 2

Stress the CPU:

1
cat /dev/urandom | gzip > /dev/null

All the above commands where running at the same time for ~5mins. In this case the power consumption was ~5.38W as you can see from the photo.

Power consumption (stress)

With a room temperature of 22C, the idle temperature was:

 Temperature (C)
Thermal zone 045.5
Thermal zone 152

During the test all cores were running at 1992000 Hz, which means that there might be a throttle, but the core speed didn’t change at all to compensate the temperature.

Next you can see the statistics graphs from the UI before and while running the stress test.

Statistics graph - Processor

Statistics graph - Load

Statistics graph - Thermal

Statistics graph - Memmory

Back to TOC

6. sbc-bench results

I’m also adding the sbc-bench in the benchmarks. sbc-bench is a tool from Thomas Kaiser which is more focused on the embedded Linux devices. Since this benchmark doesn’t run on the Friendly-Wrt OS, I’ve installed the rk3568-sd-friendlycore-focal-5.10-arm64-20220526.img.gz from the official Google drive storage from FriendlyElec.

The details of this image are:

1
2
3
4
5
pi@FriendlyELEC:~$ uname -a
Linux FriendlyELEC 5.10.66 #219 SMP PREEMPT Fri Apr 22 18:20:21 CST 2022 aarch64 aarch64 aarch64 GNU/Linux

pi@FriendlyELEC:~$ cat /etc/issue
Ubuntu 20.04.4 LTS \n \l

First I’ve updated all the packages and then I’ve used the following steps to run the bechmark.

1
2
pi@FriendlyELEC:~$ sudo -s
root@FriendlyELEC:/home/pi/sbc-bench# ./sbc-bench.sh

Since the result output is too long, you need to expand the following link to view it all.

Click here to view full console output…
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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
sbc-bench v0.9.7 FriendlyElec NanoPi R5S (Thu, 02 Jun 2022 11:27:01 +0000)

Distributor ID:	Ubuntu
Description:	Ubuntu 20.04.4 LTS
Release:	20.04
Codename:	focal

/usr/bin/gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0

Uptime: 11:27:02 up 50 min,  1 user,  load average: 0.08, 0.06, 0.60

Linux 5.10.66 (FriendlyELEC) 	06/02/22 	_aarch64_	(4 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          27.26    0.01    1.02    0.13    0.00   71.58

Device             tps    kB_read/s    kB_wrtn/s    kB_dscd/s    kB_read    kB_wrtn    kB_dscd
mmcblk0           4.46       125.19        86.19         0.00     377467     259865          0
mmcblk2           0.17         3.03         0.00         0.00       9135          0          0
nvme0n1           0.05         1.44         0.00         0.00       4343          0          0

              total        used        free      shared  buff/cache   available
Mem:          1.9Gi       228Mi       1.6Gi       3.0Mi        84Mi       1.6Gi
Swap:            0B          0B          0B

##########################################################################

Checking cpufreq OPP (Cortex-A55):

Cpufreq OPP: 1992    Measured: 1870 (1870.560/1870.495/1870.430)     (-6.1%)
Cpufreq OPP: 1800    Measured: 1834 (1835.338/1835.087/1833.920)     (+1.9%)
Cpufreq OPP: 1608    Measured: 1667 (1667.241/1667.017/1666.742)     (+3.7%)
Cpufreq OPP: 1416    Measured: 1480 (1496.987/1496.605/1447.581)     (+4.5%)
Cpufreq OPP: 1104    Measured: 1242 (1243.506/1243.431/1241.548)    (+12.5%)
Cpufreq OPP:  816    Measured:  810    (811.603/811.085/808.754)
Cpufreq OPP:  600    Measured:  594    (596.105/594.804/593.709)
Cpufreq OPP:  408    Measured:  402    (403.043/402.789/402.507)     (-1.5%)

##########################################################################

Hardware sensors:

gpu_thermal-virtual-0
temp1:        +38.3 C  

test_battery-virtual-0
in0:           4.00 mV 
temp:         +26.0 C  
curr1:        -2.00 mA (avg =  -0.00 A)

soc_thermal-virtual-0
temp1:        +41.9 C  (crit = +115.0 C)

test_battery-virtual-0

temp1:        +26.0 C  
curr1:            N/A  (avg =  +0.00 A)

##########################################################################

Executing benchmark on cpu0 (Cortex-A55):

tinymembench v0.4.9 (simple benchmark for memory throughput and latency)

==========================================================================
== Memory bandwidth tests                                               ==
==                                                                      ==
== Note 1: 1MB = 1000000 bytes                                          ==
== Note 2: Results for 'copy' tests show how many bytes can be          ==
==         copied per second (adding together read and writen           ==
==         bytes would have provided twice higher numbers)              ==
== Note 3: 2-pass copy means that we are using a small temporary buffer ==
==         to first fetch data into it, and only then write it to the   ==
==         destination (source -> L1 cache, L1 cache -> destination)    ==
== Note 4: If sample standard deviation exceeds 0.1%, it is shown in    ==
==         brackets                                                     ==
==========================================================================

 C copy backwards                                     :   1817.6 MB/s (1.1%)
 C copy backwards (32 byte blocks)                    :   1758.7 MB/s
 C copy backwards (64 byte blocks)                    :   1303.1 MB/s
 C copy                                               :   2669.6 MB/s
 C copy prefetched (32 bytes step)                    :   1687.5 MB/s (0.2%)
 C copy prefetched (64 bytes step)                    :   2373.0 MB/s (0.5%)
 C 2-pass copy                                        :   1587.3 MB/s
 C 2-pass copy prefetched (32 bytes step)             :   1038.2 MB/s
 C 2-pass copy prefetched (64 bytes step)             :   1447.1 MB/s
 C fill                                               :   6192.6 MB/s (2.3%)
 C fill (shuffle within 16 byte blocks)               :   6189.5 MB/s (0.2%)
 C fill (shuffle within 32 byte blocks)               :   6194.2 MB/s (0.1%)
 C fill (shuffle within 64 byte blocks)               :   6194.9 MB/s (0.2%)
 ---
 standard memcpy                                      :   2653.2 MB/s
 standard memset                                      :   6195.6 MB/s (0.1%)
 ---
 NEON LDP/STP copy                                    :   2675.5 MB/s
 NEON LDP/STP copy pldl2strm (32 bytes step)          :   2143.3 MB/s (0.7%)
 NEON LDP/STP copy pldl2strm (64 bytes step)          :   2569.1 MB/s (0.1%)
 NEON LDP/STP copy pldl1keep (32 bytes step)          :   1962.5 MB/s (0.1%)
 NEON LDP/STP copy pldl1keep (64 bytes step)          :   2719.2 MB/s
 NEON LD1/ST1 copy                                    :   2681.2 MB/s
 NEON STP fill                                        :   6194.4 MB/s (0.2%)
 NEON STNP fill                                       :   2067.0 MB/s (1.3%)
 ARM LDP/STP copy                                     :   2675.6 MB/s
 ARM STP fill                                         :   6191.0 MB/s (2.1%)
 ARM STNP fill                                        :   2063.7 MB/s (1.1%)

==========================================================================
== Memory latency test                                                  ==
==                                                                      ==
== Average time is measured for random memory accesses in the buffers   ==
== of different sizes. The larger is the buffer, the more significant   ==
== are relative contributions of TLB, L1/L2 cache misses and SDRAM      ==
== accesses. For extremely large buffer sizes we are expecting to see   ==
== page table walk with several requests to SDRAM for almost every      ==
== memory access (though 64MiB is not nearly large enough to experience ==
== this effect to its fullest).                                         ==
==                                                                      ==
== Note 1: All the numbers are representing extra time, which needs to  ==
==         be added to L1 cache latency. The cycle timings for L1 cache ==
==         latency can be usually found in the processor documentation. ==
== Note 2: Dual random read means that we are simultaneously performing ==
==         two independent memory accesses at a time. In the case if    ==
==         the memory subsystem can't handle multiple outstanding       ==
==         requests, dual random read has the same timings as two       ==
==         single reads performed one after another.                    ==
==========================================================================

block size : single random read / dual random read, [MADV_NOHUGEPAGE]
      1024 :    0.0 ns          /     0.0 ns 
      2048 :    0.0 ns          /     0.0 ns 
      4096 :    0.0 ns          /     0.0 ns 
      8192 :    0.0 ns          /     0.0 ns 
     16384 :    0.6 ns          /     1.1 ns 
     32768 :    3.8 ns          /     6.1 ns 
     65536 :    9.4 ns          /    13.6 ns 
    131072 :   12.5 ns          /    16.5 ns 
    262144 :   14.9 ns          /    18.0 ns 
    524288 :   18.1 ns          /    20.5 ns 
   1048576 :   82.9 ns          /   123.6 ns 
   2097152 :  117.9 ns          /   157.3 ns 
   4194304 :  136.2 ns          /   169.4 ns 
   8388608 :  152.4 ns          /   183.9 ns 
  16777216 :  161.2 ns          /   192.9 ns 
  33554432 :  167.6 ns          /   199.8 ns 
  67108864 :  169.9 ns          /   204.8 ns 

block size : single random read / dual random read, [MADV_HUGEPAGE]
      1024 :    0.0 ns          /     0.0 ns 
      2048 :    0.0 ns          /     0.0 ns 
      4096 :    0.0 ns          /     0.0 ns 
      8192 :    0.0 ns          /     0.0 ns 
     16384 :    0.6 ns          /     1.1 ns 
     32768 :    3.7 ns          /     6.0 ns 
     65536 :    9.4 ns          /    13.5 ns 
    131072 :   12.5 ns          /    16.6 ns 
    262144 :   14.9 ns          /    18.0 ns 
    524288 :   18.0 ns          /    20.9 ns 
   1048576 :   82.9 ns          /   123.7 ns 
   2097152 :  117.9 ns          /   157.4 ns 
   4194304 :  135.5 ns          /   168.4 ns 
   8388608 :  144.6 ns          /   172.3 ns 
  16777216 :  148.7 ns          /   173.8 ns 
  33554432 :  150.4 ns          /   174.4 ns 
  67108864 :  151.0 ns          /   174.6 ns 

##########################################################################

Executing ramlat on cpu0 (Cortex-A55), results in ns:

       size:  1x32  2x32  1x64  2x64 1xPTR 2xPTR 4xPTR
         4k: 4.960 6.697 3.970 6.697 2.855 3.468 6.704 
         8k: 4.961 6.695 3.982 6.699 2.853 3.478 6.711 
        16k: 4.963 6.699 3.972 6.700 2.852 3.469 6.706 
        32k: 5.213 7.196 4.203 7.198 2.994 3.833 7.561 
        64k: 20.03 34.21 19.11 34.18 17.56 31.25 58.41 
       128k: 22.17 40.19 21.20 40.21 20.23 35.93 72.81 
       256k: 22.35 40.61 21.31 40.58 20.34 36.31 73.82 
       512k: 35.80 63.24 32.98 66.47 31.72 78.16 113.5 
      1024k: 111.1 199.7 108.4 197.8 103.9 207.7 369.3 
      2048k: 136.0 239.3 136.9 260.5 138.9 244.3 456.6 
      4096k: 151.3 265.2 151.1 262.2 154.8 260.3 497.8 
      8192k: 162.9 276.2 161.9 276.6 160.8 268.7 498.5 
     16384k: 174.6 284.2 170.7 284.3 170.1 279.3 513.6 

##########################################################################

Executing benchmark twice on cluster 0 (Cortex-A55)

OpenSSL 1.1.1f, built on 31 Mar 2020
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-128-cbc     178321.39k   513258.92k   979912.79k  1274652.67k  1396165.29k  1405637.97k
aes-128-cbc     179189.45k   515358.34k   991584.60k  1277756.76k  1396285.44k  1406287.87k
aes-192-cbc     169652.90k   455485.40k   794666.75k   979625.30k  1050566.66k  1056385.71k
aes-192-cbc     166513.96k   455422.63k   792915.37k   979013.97k  1050681.34k  1056172.71k
aes-256-cbc     162527.72k   414969.51k   686710.02k   818163.37k   866932.05k   870727.68k
aes-256-cbc     162564.21k   415006.38k   686708.74k   817777.66k   866992.13k   870536.53k

##########################################################################

Executing benchmark single-threaded on cpu0 (Cortex-A55)

7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=C,Utf16=off,HugeFiles=on,64 bits,4 CPUs LE)

LE
CPU Freq: - - - - - - - - -

RAM size:    1961 MB,  # CPU hardware threads:   4
RAM usage:    435 MB,  # Benchmark threads:      1

                       Compressing  |                  Decompressing
Dict     Speed Usage    R/U Rating  |      Speed Usage    R/U Rating
         KiB/s     %   MIPS   MIPS  |      KiB/s     %   MIPS   MIPS

22:       1032   100   1005   1005  |      21349   100   1824   1823
23:        966   100    985    985  |      20776   100   1799   1798
24:        916   100    986    985  |      20261   100   1780   1779
25:        855   100    978    977  |      19696   100   1754   1753
----------------------------------  | ------------------------------
Avr:             100    989    988  |              100   1789   1788
Tot:             100   1389   1388

##########################################################################

Executing benchmark 3 times multi-threaded on CPUs 0-3

7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=C,Utf16=off,HugeFiles=on,64 bits,4 CPUs LE)

LE
CPU Freq: - - - - - - - - -

RAM size:    1961 MB,  # CPU hardware threads:   4
RAM usage:    882 MB,  # Benchmark threads:      4

                       Compressing  |                  Decompressing
Dict     Speed Usage    R/U Rating  |      Speed Usage    R/U Rating
         KiB/s     %   MIPS   MIPS  |      KiB/s     %   MIPS   MIPS

22:       2819   353    777   2743  |      81682   399   1745   6969
23:       2738   367    759   2790  |      78157   394   1717   6763
24:       2676   376    765   2877  |      76160   394   1696   6686
25:       2553   380    768   2915  |      73020   394   1651   6499
----------------------------------  | ------------------------------
Avr:             369    767   2831  |              395   1702   6729
Tot:             382   1235   4780

7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=C,Utf16=off,HugeFiles=on,64 bits,4 CPUs LE)

LE
CPU Freq: - - - - - - - 1024000000 -

RAM size:    1961 MB,  # CPU hardware threads:   4
RAM usage:    882 MB,  # Benchmark threads:      4

                       Compressing  |                  Decompressing
Dict     Speed Usage    R/U Rating  |      Speed Usage    R/U Rating
         KiB/s     %   MIPS   MIPS  |      KiB/s     %   MIPS   MIPS

22:       2906   361    784   2828  |      80566   395   1738   6874
23:       2703   365    755   2754  |      78164   395   1714   6763
24:       2645   375    759   2845  |      76139   394   1695   6684
25:       2518   378    760   2875  |      73569   394   1660   6548
----------------------------------  | ------------------------------
Avr:             370    765   2826  |              395   1702   6717
Tot:             382   1233   4771

7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=C,Utf16=off,HugeFiles=on,64 bits,4 CPUs LE)

LE
CPU Freq: - - - - - - 512000000 - -

RAM size:    1961 MB,  # CPU hardware threads:   4
RAM usage:    882 MB,  # Benchmark threads:      4

                       Compressing  |                  Decompressing
Dict     Speed Usage    R/U Rating  |      Speed Usage    R/U Rating
         KiB/s     %   MIPS   MIPS  |      KiB/s     %   MIPS   MIPS

22:       2835   354    780   2758  |      80967   398   1737   6908
23:       2744   367    761   2797  |      79393   399   1721   6869
24:       2640   376    756   2839  |      77059   399   1697   6765
25:       2543   379    766   2904  |      74358   398   1662   6618
----------------------------------  | ------------------------------
Avr:             369    766   2825  |              398   1704   6790
Tot:             384   1235   4807

Compression: 2831,2826,2825
Decompression: 6729,6717,6790
Total: 4780,4771,4807

##########################################################################

Testing maximum cpufreq again, still under full load. System health now:

Time        CPU    load %cpu %sys %usr %nice %io %irq   Temp
11:45:11: 1992MHz  4.11  96%   3%  92%   0%   0%   0%  50.0°C

Checking cpufreq OPP (Cortex-A55):

Cpufreq OPP: 1992    Measured: 1863 (1864.617/1863.304/1862.208)     (-6.5%)

##########################################################################

Hardware sensors:

gpu_thermal-virtual-0
temp1:        +41.9 C  

test_battery-virtual-0
in0:           4.00 mV 
temp:         +26.0 C  
curr1:        -2.00 mA (avg =  -0.00 A)

soc_thermal-virtual-0
temp1:        +46.7 C  (crit = +115.0 C)

test_battery-virtual-0

temp1:        +26.0 C  
curr1:            N/A  (avg =  +0.00 A)

##########################################################################

Thermal source: /sys/devices/virtual/thermal/thermal_zone0/ (soc-thermal)

System health while running tinymembench:

Time        CPU    load %cpu %sys %usr %nice %io %irq   Temp
11:27:26: 1992MHz  0.39  28%   0%  27%   0%   0%   0%  44.4°C
11:28:06: 1992MHz  0.69  25%   0%  25%   0%   0%   0%  46.1°C
11:28:47: 1992MHz  0.84  25%   0%  25%   0%   0%   0%  46.1°C
11:29:27: 1992MHz  0.92  25%   0%  25%   0%   0%   0%  46.7°C
11:30:08: 1992MHz  0.96  25%   0%  24%   0%   0%   0%  45.0°C
11:30:48: 1992MHz  0.98  25%   0%  25%   0%   0%   0%  44.4°C
11:31:28: 1992MHz  0.99  25%   0%  25%   0%   0%   0%  43.8°C
11:32:08: 1992MHz  1.00  25%   0%  25%   0%   0%   0%  43.8°C
11:32:48: 1992MHz  1.00  25%   0%  25%   0%   0%   0%  43.8°C
11:33:28: 1992MHz  1.00  25%   0%  24%   0%   0%   0%  44.4°C
11:34:08: 1992MHz  1.00  25%   0%  25%   0%   0%   0%  43.8°C
11:34:48: 1992MHz  1.00  25%   0%  25%   0%   0%   0%  43.8°C
11:35:28: 1992MHz  1.00  25%   0%  25%   0%   0%   0%  43.8°C
11:36:08: 1992MHz  1.00  25%   0%  25%   0%   0%   0%  43.8°C

System health while running ramlat:

Time        CPU    load %cpu %sys %usr %nice %io %irq   Temp
11:36:37: 1992MHz  1.00  27%   0%  26%   0%   0%   0%  45.6°C
11:36:40: 1992MHz  1.00  25%   0%  25%   0%   0%   0%  45.6°C
11:36:43: 1992MHz  1.00  25%   0%  24%   0%   0%   0%  45.6°C
11:36:46: 1992MHz  1.00  25%   0%  25%   0%   0%   0%  44.4°C
11:36:49: 1992MHz  1.00  25%   0%  25%   0%   0%   0%  44.4°C
11:36:52: 1992MHz  1.00  25%   0%  25%   0%   0%   0%  43.8°C
11:36:55: 1992MHz  1.00  25%   0%  24%   0%   0%   0%  43.8°C
11:36:58: 1992MHz  1.00  25%   0%  25%   0%   0%   0%  44.4°C

System health while running OpenSSL benchmark:

Time        CPU    load %cpu %sys %usr %nice %io %irq   Temp
11:37:01: 1992MHz  1.00  27%   0%  26%   0%   0%   0%  46.1°C
11:37:17: 1992MHz  1.00  25%   0%  25%   0%   0%   0%  43.8°C
11:37:33: 1992MHz  1.00  25%   0%  25%   0%   0%   0%  43.8°C
11:37:49: 1992MHz  1.00  25%   0%  25%   0%   0%   0%  44.4°C
11:38:05: 1992MHz  1.07  25%   0%  24%   0%   0%   0%  44.4°C
11:38:21: 1992MHz  1.05  25%   0%  24%   0%   0%   0%  44.4°C
11:38:38: 1992MHz  1.04  25%   0%  25%   0%   0%   0%  44.4°C

System health while running 7-zip single core benchmark:

Time        CPU    load %cpu %sys %usr %nice %io %irq   Temp
11:38:49: 1992MHz  1.03  27%   0%  26%   0%   0%   0%  45.6°C
11:38:59: 1992MHz  1.03  25%   0%  24%   0%   0%   0%  45.0°C
11:39:09: 1992MHz  1.02  25%   0%  24%   0%   0%   0%  46.1°C
11:39:20: 1992MHz  1.02  25%   0%  24%   0%   0%   0%  45.6°C
11:39:30: 1992MHz  1.16  25%   0%  24%   0%   0%   0%  45.6°C
11:39:40: 1992MHz  1.14  25%   0%  24%   0%   0%   0%  45.0°C
11:39:50: 1992MHz  1.12  25%   0%  24%   0%   0%   0%  45.6°C
11:40:00: 1992MHz  1.10  25%   0%  24%   0%   0%   0%  45.0°C
11:40:10: 1992MHz  1.08  25%   0%  24%   0%   0%   0%  45.0°C
11:40:20: 1992MHz  1.07  25%   0%  24%   0%   0%   0%  44.4°C
11:40:30: 1992MHz  1.06  25%   0%  24%   0%   0%   0%  45.0°C
11:40:40: 1992MHz  1.05  25%   0%  24%   0%   0%   0%  45.6°C

System health while running 7-zip multi core benchmark:

Time        CPU    load %cpu %sys %usr %nice %io %irq   Temp
11:40:44: 1992MHz  1.05  27%   0%  26%   0%   0%   0%  46.7°C
11:41:05: 1992MHz  1.93  93%   1%  91%   0%   0%   0%  49.4°C
11:41:28: 1992MHz  2.45  94%   2%  92%   0%   0%   0%  48.9°C
11:41:49: 1992MHz  2.87  91%   2%  88%   0%   0%   0%  49.4°C
11:42:15: 1992MHz  3.31  97%   3%  94%   0%   0%   0%  53.8°C
11:42:37: 1992MHz  3.80  92%   1%  90%   0%   0%   0%  50.6°C
11:42:58: 1992MHz  3.94  93%   2%  91%   0%   0%   0%  50.6°C
11:43:19: 1992MHz  3.78  92%   2%  89%   0%   0%   0%  50.6°C
11:43:41: 1992MHz  4.01  97%   3%  94%   0%   0%   0%  49.4°C
11:44:07: 1992MHz  4.01  91%   1%  89%   0%   0%   0%  55.6°C
11:44:29: 1992MHz  4.06  94%   1%  92%   0%   0%   0%  50.6°C
11:44:50: 1992MHz  3.94  93%   2%  91%   0%   0%   0%  48.9°C
11:45:11: 1992MHz  4.11  96%   3%  92%   0%   0%   0%  50.0°C

##########################################################################

Linux 5.10.66 (FriendlyELEC) 	06/02/22 	_aarch64_	(4 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          31.18    0.02    0.99    0.10    0.00   67.71

Device             tps    kB_read/s    kB_wrtn/s    kB_dscd/s    kB_read    kB_wrtn    kB_dscd
mmcblk0           3.44        94.03        64.04         0.00     387467     263877          0
mmcblk2           0.12         2.22         0.00         0.00       9135          0          0
nvme0n1           0.04         1.05         0.00         0.00       4343          0          0

              total        used        free      shared  buff/cache   available
Mem:          1.9Gi       229Mi       1.6Gi       3.0Mi        95Mi       1.6Gi
Swap:            0B          0B          0B

CPU sysfs topology (clusters, cpufreq members, clockspeeds)
                 cpufreq   min    max
 CPU    cluster  policy   speed  speed   core type
  0        0        0      408    1992   Cortex-A55 / r2p0
  1        0        0      408    1992   Cortex-A55 / r2p0
  2        0        0      408    1992   Cortex-A55 / r2p0
  3        0        0      408    1992   Cortex-A55 / r2p0

Architecture:                    aarch64
CPU op-mode(s):                  32-bit, 64-bit
Byte Order:                      Little Endian
CPU(s):                          4
On-line CPU(s) list:             0-3
Thread(s) per core:              1
Core(s) per socket:              4
Socket(s):                       1
Vendor ID:                       ARM
Model:                           0
Model name:                      Cortex-A55
Stepping:                        r2p0
CPU max MHz:                     1992.0000
CPU min MHz:                     408.0000
BogoMIPS:                        48.00
Vulnerability Itlb multihit:     Not affected
Vulnerability L1tf:              Not affected
Vulnerability Mds:               Not affected
Vulnerability Meltdown:          Not affected
Vulnerability Spec store bypass: Not affected
Vulnerability Spectre v1:        Mitigation; __user pointer sanitization
Vulnerability Spectre v2:        Not affected
Vulnerability Srbds:             Not affected
Vulnerability Tsx async abort:   Not affected
Flags:                           fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp

SoC guess: Rockchip RK3568 (35682000)
DT compat: friendlyelec,nanopi-r5s
           rockchip,rk3568
 Compiler: /usr/bin/gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0 / aarch64-linux-gnu
 Userland: arm64
   Kernel: 5.10.66/aarch64
           CONFIG_HZ=300
           CONFIG_HZ_300=y
           CONFIG_PREEMPTION=y
           CONFIG_PREEMPT=y
           CONFIG_PREEMPT_COUNT=y
           CONFIG_PREEMPT_RCU=y

| FriendlyElec NanoPi R5S | 1992 MHz | 5.10 | Ubuntu 20.04.4 LTS arm64 | 4790 | 178760 | 870630 | 2650 | 6200 | - |

The file is also available here.

This comment from tkaiser claims that according to the same benchmark the NanoPi-R5S is the slowest RK3568 SBC so far. The difference from the nominal frequency is -6%. Personally, I don’t really mind and I can’t really tell how much difference this would have in the real usage.

The full list is here

Click here to view full list…
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 Radxa ROCK 3 Model A (4.19.193-30-rockchip-gee73a9ef8c6d): Cpufreq OPP: 1992    Measured: 1970 (1966.096/1964.278/1965.330)
 Firefly RK3568-ROC-PC HDMI (Linux) (4.19.219-station-p2): Cpufreq OPP: 1992    Measured: 1965 (1962.701/1952.327/1962.797)
 Hardkernel ODROID-M1 (4.19.219-realtek-odroid-arm64): Cpufreq OPP: 1992    Measured: 1930 (1927.475/1929.203/1928.857)
 Hardkernel ODROID-M1 (4.19.219-odroid-arm64): Cpufreq OPP: 1992    Measured: 1930 (1928.465/1928.603/1928.419)
 Hardkernel ODROID-M1 (4.19.219-realtek-odroid-arm64): Cpufreq OPP: 1992    Measured: 1950 (1948.509/1948.109/1947.240)
 Hardkernel ODROID-M1 (4.19.219-odroid-arm64): Cpufreq OPP: 1992    Measured: 1950 (1946.371/1939.775/1951.572)
 Hardkernel ODROID-M1 (4.19.219-odroid-arm64): Cpufreq OPP: 1992    Measured: 1940 (1935.240/1933.455/1939.472)
 Radxa ROCK 3 Model A (5.15.32): Cpufreq OPP: 1992    Measured: 1960 (1955.852/1955.473/1955.781)
 Hardkernel ODROID-M1 (4.19.219-odroid-arm64): Cpufreq OPP: 1992    Measured: 1935 (1934.451/1933.131/1929.895)
 Firefly rk3568-roc-pc (5.16.18-media): No cpufreq support available. Measured on cpu1: 815 Mhz (813.601/813.541/813.250)
 Firefly RK3568-ROC-PC HDMI (Linux) (4.19.219-station-p2): Cpufreq OPP: 1992    Measured: 2010 (2008.644/2009.094/2008.969)
 Firefly RK3568-ROC-PC HDMI (Linux) (4.19.219-station-p2): Cpufreq OPP: 1992    Measured: 1995 (1991.715/1998.398/1985.981)
 Hardkernel ODROID-M1 (4.19.219-odroid-arm64): Cpufreq OPP: 1992    Measured: 1955 (1951.289/1953.272/1943.021)
 Hardkernel ODROID-M1 (5.18.0-odroid-arm64): No cpufreq support available. Measured on cpu1: 815 Mhz (814.071/814.001/813.150)
 Hardkernel ODROID-M1 (5.18.0-odroid-arm64): No cpufreq support available. Measured on cpu1: 815 Mhz (814.182/813.140/812.511)
 Hardkernel ODROID-M1 (5.18.0-odroid-arm64): No cpufreq support available. Measured on cpu1: 815 Mhz (814.844/813.250/812.830)
 Radxa ROCK 3 Model A (4.19.193): Cpufreq OPP: 1992    Measured: 1940 (1936.633/1936.075/1934.405)
 Radxa ROCK 3 Model A (4.19.193-36-rockchip-gd05f98887579): Cpufreq OPP: 1992    Measured: 2000 (1998.447/1997.359/1996.742)
 Hardkernel ODROID-M1 (4.19.219-odroid-arm64): Cpufreq OPP: 1992    Measured: 1947 (1948.039/1947.827/1947.592)  (-2.3%)
 Mrkaio M68S (4.19.219-station-p2): Cpufreq OPP: 1992    Measured: 1904 (1911.021/1909.236/1892.758)     (-4.4%)
 FriendlyElec NanoPi R5S (5.10.66): Cpufreq OPP: 1992    Measured: 1872 (1872.991/1872.926/1872.230)     (-6.0%)

Source: http://ix.io/3Zb4

Back to TOC

7. Using the Docker image

OK, so this is interesting to me, so I’ve installed the FriendlyWrt docker image to play a bit around. It’s so important to me, because I’m using containers all the time to deploy applications in my k3s cluster and I also use docker compose to bring up small services.

For this test I’ve used the rk3568-eflasher-friendlywrt-docker-20220526.img.gz which I’ve downloaded from here. This is the official Google Drive of FriendlyElec btw, it’s not my image.

Unfortunately, docker-compose is not available in the image, but no worries, you can download the static binary from here. Just select the official release for aarch64.

1
2
3
curl -L https://github.com/docker/compose/releases/download/v2.6.0/docker-compose-linux-aarch64 --output docker-compose
chmod +x docker-compose
mv docker-compose /usr/bin/

Now, you’re ready and you can use docker compose.

Also this image comes with the luci-app-dockerman installed. I haven’t yet figured out how to use this, but I think I’ll have to wait until August when I’m back :(

Back to TOC

8. Other resources

Reviews:

  1. There is also another review of the NanoPi R5S from Jean-Luc in cnx-software blog here. You should also read the comments in that post.

FriendlyElec resources

Back to TOC

9. Conclusions

Well, personally I’m excited with the NanoPi-R5S. This is what you get for $60 today (+$16 for the case). 2x 2.5Gbps ports and a Quad core running all cores at 2GHz. For me, this makes a great router if you want to upgrade to 2.5G. Also the fact that it comes with an OS that you can do pretty much whatever you like it’s also nice. You can even use the nvme M.2 slot to install an SSD and use it as your local network storage.

Also, FriendlyWRT it’s not the only OS you can get. You can choose also between Android and Ubuntu and a docker ready image. This means that you can use the NanoPi-R5S for many different use-cases. For example, it could also serve as a k3s node (I suggeset the 4GB RAM for that). There are really so much things that you can do. Especially, since I’m running my own K3S cluster with 1x Jetson nano as the master and 3x RPi-8GB nodes, the NanoPi-R5S really rings a bell to me that it would be a great K3S node.

My personal opinion, according to my current testsm is that this is the best SBC from FriendlyElec so far. The performance/price ratio is great, especially considering the high prices of other alternatives right now and the lack of SBC in the market because of the COVID.

Unfortunately, I need to leave for a couple of months and therefore I won’t be able to play around more with the NanoPi-R5S, but when I’m back I would like to test it also in a K3S cluster. I mean for the price is a no brainer. You can build a 2.5G K3S cluster at your home. Just wow…

I’ll be back with more tests in the future.

Have fun!

Back to TOC

This post is licensed under CC BY 4.0 by the author.