Table of contents
Because this post is quite long and with too many details, I’ve used a TOC so you can browse better.
- Table of contents
- 1. Intro
- 2. The SBC
- 3. NanoPi R5S specs
- 4. Benchmarks
- 4.1 Benchmarks - Storage
- 4.2 Benchmarks - Networking
- Testing a single 2.5G port
- Test case 2 - 2.5G to 2.5G port
- Test case 3 - All ports
- 4.2.1 Benchmarks - Networking - Test case 1 - CAT6A
- 4.2.1.1 Benchmarks - Networking - Test case 1 - CAT6A - R5S->M1
- 4.2.1.2 Benchmarks - Networking - Test case 1 - CAT6A - M1->R5S
- 4.2.1.3 Benchmarks - Networking - Test case 1 - CAT6A - R5S<->M1
- 4.2.1.4 Benchmarks - Networking - Test case 1 - CAT6A - packet generation capabilities - M1->R5S
- 4.2.1.4 Benchmarks - Networking - Test case 1 - CAT6A - packet generation capabilities - R5S->M1
- 4.2.2 Benchmarks - Networking - Test case 1 - CAT7
- 4.2.3 Benchmarks - Networking - Test case 2
- 4.2.4 Benchmarks - Networking - Test case 3
- 5. Power consumption and thermals
- 6.
sbc-benchresults - 7. Using the Docker image
- 8. Other resources
- 9. Conclusions
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.
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 front
2.1 SBC - PCB
The PCB of the R5S is quite populated with several ICs. This is the bottom side.
NanoPi-R5S PCB
And this is the top side.
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.
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.
UART mode
And this is how it looks assembled in the case.
UART mode in case
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.
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.
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.
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 porteth1, it’s the first 2.5Gbps PHY connected on the PCIe buseth2, 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.
gre0andgretap0, 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.
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.
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.
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:
mmcblk2, the eMMCmmcblk0, the SD card which in my case is the SandDisk Extreme 128GB V30 A2nvme0n1, the Crucial P2 1TB nvme drive.
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) | |
|---|---|---|---|---|
| eMMC | 162.22 | 153 | 33.77 | 114.83 |
| SD | 62.89 | 59 | 33.25 | 57.80 |
| nvme | 388.92 | 316 | 73.15 | 175.02 |
If you want to see the details for each test then keep scrolling, otherwise click here to jump to the networking benchmarks.
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.
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
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
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.49 | TBD | TBD |
| M1 -> R5S (CAT.6a) | 2.14 | TBD | TBD |
| R5S <-> M1 (CAT.6a) | 1.37 (TX) / 159 (RX) | TBD | TBD |
| R5S -> M1 (CAT.7) | 1.54 | TBD | TBD |
| M1 -> R5S (CAT.7) | 2.24 | TBD | TBD |
| R5S <-> M1 (CAT.7) | 1.24 (TX) / 153 (RX) | TBD | TBD |
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.
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
| Host | Command |
|---|---|
| Mac M1 w/ USB-C 2.5G | iperf3 -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
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.
| Host | Command |
|---|---|
| Mac M1 w/ USB-C 2.5G | iperf3 -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!
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.
| Host | Command |
|---|---|
| Mac M1 w/ USB-C 2.5G | iperf3 -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
| Host | Command |
|---|---|
| Mac M1 w/ USB-C 2.5G | iperf3 -s |
| NanoPi R5S (LAN2) | iperf3 -u -c 192.168.2.20 -t 120 -R -O 5 -f m -b 2500M –length {size} |
Notice the
-Rin the client command, which meansreverse, so the M1 will be the sender/client.
This is the table with the results of the various sizes.
| Datagram lenght | Sender bitrate | Sender jitter | Receiver bitrate | Receiver jitter |
|---|---|---|---|---|
| 16 | 20.3 Mbits/sec | 0.000 ms | 12.4 Mbits/sec | 0.013 ms |
| 100 | 125 Mbits/sec | 0.000 ms | 75.9 Mbits/sec | 0.009 ms |
| 300 | 367 Mbits/sec | 0.000 ms | 222 Mbits/sec | 0.007 ms |
| 500 | 626 Mbits/sec | 0.000 ms | 352 Mbits/sec | 0.016 ms |
| 700 | 901 Mbits/sec | 0.000 ms | 512 Mbits/sec | 0.010 ms |
| 900 | 1164 Mbits/sec | 0.000 ms | 653 Mbits/sec | 0.010 ms |
| 1100 | 1405 Mbits/sec | 0.000 ms | 774 Mbits/sec | 0.008 ms |
| 1300 | 1651 Mbits/sec | 0.000 ms | 901 Mbits/sec | 0.007 ms |
| 1472 | 1821 Mbits/sec | 0.000 ms | 1019 Mbits/sec | 0.007 ms |
| 1500 | 1533 Mbits/sec | 0.000 ms | 510 Mbits/sec | 0.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
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.
| Host | Command |
|---|---|
| Mac M1 w/ USB-C 2.5G | iperf3 -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 lenght | Sender bitrate | Sender jitter | Receiver bitrate | Receiver jitter |
|---|---|---|---|---|
| 16 | 4.23 Mbits/sec | 0.000 ms | 4.23 Mbits/sec | 0.031 ms |
| 100 | 27.4 Mbits/sec | 0.000 ms | 27.3 Mbits/sec | 0.033 ms |
| 300 | 70.1 Mbits/sec | 0.000 ms | 70.1 Mbits/sec | 0.026 ms |
| 500 | 117 Mbits/sec | 0.000 ms | 117 Mbits/sec | 0.032 ms |
| 700 | 190 Mbits/sec | 0.000 ms | 190 Mbits/sec | 0.032 ms |
| 900 | 243 Mbits/sec | 0.000 ms | 243 Mbits/sec | 0.030 ms |
| 1100 | 254 Mbits/sec | 0.000 ms | 254 Mbits/sec | 0.026 ms |
| 1300 | 349 Mbits/sec | 0.000 ms | 349 Mbits/sec | 0.029 ms |
| 1472 | 395 Mbits/sec | 0.000 ms | 394 Mbits/sec | 0.017 ms |
| 1500 | 321 Mbits/sec | 0.000 ms | 320 Mbits/sec | 0.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
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.
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
| Host | Command |
|---|---|
| Mac M1 w/ USB-C 2.5G | iperf3 -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
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.
| Host | Command |
|---|---|
| Mac M1 w/ USB-C 2.5G | iperf3 -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
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.
| Host | Command |
|---|---|
| Mac M1 w/ USB-C 2.5G | iperf3 -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
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.
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.
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 0 | 39.5 |
| Thermal zone 1 | 42.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 0 | 45.5 |
| Thermal zone 1 | 52 |
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
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
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 :(
8. Other resources
Reviews:
- There is also another review of the NanoPi R5S from Jean-Luc in
cnx-softwareblog here. You should also read the comments in that post.
FriendlyElec resources
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!