在对NanoPi R5S进行评测的第一部分,我进行了拆箱、拆解、快速尝试预装了基于OpenWrt的FriendlyWrt,并对2.5GbE接口进行了一些iperf3基准测试,结果有点令人失望。之后我又进一步进行测试,切换到了基于Ubuntu 20.04的FriendlyCore镜像,因为我更熟悉基于 Debian的操作系统,而且某些工具在OpenWrt上也无法运行。注意,现在测试结果显示的性能仍然不是很理想,这就是我称之为预测试的原因,随着越来越多人的使用和调整软件,未来几个月的情况应该会有所改善。
OpenWrt优化?
现在我们先不讨论基于Ubuntu的镜像。因为FriendElec(广州友善电子科技有限公司)告知我他们添加了一些优化,于是我升级了FriendlyWrt的更新版本并对这个镜像进行了测试:
他们是这么说的:“我们对新镜像做了一些优化,比如网卡中断设置、卸载支持等等。”所以我下载了在Google Drive上找到的“rk3568-eflasher-friendlywrt-20220526.img.gz” ,然后用 USBImager将它烧录到microSD卡上,然后再boot到路由器中。
这样之后,它会自动将镜像烧录到eMMC闪存中,如果你连接了显示器,你就可以按照结果进行操作了。操作完成后,取出microSD卡,再重启路由器。
这样之后,就可以通过连接HDMI显示器(如上所示)或查看设备上的LED来检查状态了。这个过程非常快,安装到eMMC闪存上只需几秒钟。
这个新版本的镜像主要是对40-net-smp-affinity文件进行了更改。在之前预装的 FriendlyWrt中,它看起来是这样的:
1 2 3 4 5 6 7 8 9 10 11 12 13 |
friendlyelec,nanopi-r5s) set_interface_core 8 "eth0" echo 7 > /sys/class/net/eth0/queues/rx-0/rps_cpus set_interface_core 2 "eth1-0" set_interface_core 4 "eth1-16" set_interface_core 4 "eth1-18" echo b > /sys/class/net/eth1/queues/rx-0/rps_cpus set_interface_core 4 "eth2-0" set_interface_core 2 "eth2-16" set_interface_core 2 "eth2-18" echo 9 > /sys/class/net/eth2/queues/rx-0/rps_cpus ;; esac |
而新的40-net-smp-affinity文件确实不同:
1 2 3 4 5 6 7 8 9 10 11 12 13 |
friendlyelec,nanopi-r5s) set_interface_core 8 "eth0" echo f > /sys/class/net/eth0/queues/rx-0/rps_cpus set_interface_core 4 "eth1-0" set_interface_core 4 "eth1-16" set_interface_core 4 "eth1-18" echo b > /sys/class/net/eth1/queues/rx-0/rps_cpus set_interface_core 2 "eth2-0" set_interface_core 2 "eth2-16" set_interface_core 2 "eth2-18" echo d > /sys/class/net/eth2/queues/rx-0/rps_cpus ;; esac |
Willy Tarreau也解释了对eth1接口所做更改的原因:
它涉及RPS 。他们在core 2上接收此IRQ(中断请求),并将传入流量重新分配到core 0、core 1、core 3中,这才是正确使用RPS的方法。但是,要达到这一点必须要手动分配一个网络性能测试工具iperf,并对第一个饱和的core进行观察。如果首先使用ksoftirqd使core 2饱和,那就要确保iperf在其他3个core中的任何一个上都可运行。如果core2稍微空闲,那么就尝试在其上设置iperf。如果把iperf放在它上面会使ksoftirqd弹出,那么它们就会相互阻碍,而且用户会更情愿更改RPS设置来帮助释放另一个core并将其用于iperf。
在测试并切换到Ubuntu之前,其实我没有尝试过这种方法。当我尝试使用新的FriendlyWrt镜像时,得到的结果更糟糕:
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 |
$ iperf3 -t 60 -c 192.168.2.1 -i 10 Connecting to host 192.168.2.1, port 5201 [ 5] local 192.168.2.130 port 49590 connected to 192.168.2.1 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-10.00 sec 1.92 GBytes 1.65 Gbits/sec 0 1.62 MBytes [ 5] 10.00-20.00 sec 1.91 GBytes 1.64 Gbits/sec 10 2.34 MBytes [ 5] 20.00-30.00 sec 1.90 GBytes 1.63 Gbits/sec 0 2.61 MBytes [ 5] 30.00-40.00 sec 1.85 GBytes 1.59 Gbits/sec 4 1.30 MBytes [ 5] 40.00-50.00 sec 1.88 GBytes 1.61 Gbits/sec 1 1.06 MBytes [ 5] 50.00-60.00 sec 1.76 GBytes 1.51 Gbits/sec 2 868 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-60.00 sec 11.2 GBytes 1.61 Gbits/sec 17 sender [ 5] 0.00-60.05 sec 11.2 GBytes 1.60 Gbits/sec receiver iperf Done. $ iperf3 -t 60 -c 192.168.2.1 -i 10 -R Connecting to host 192.168.2.1, port 5201 Reverse mode, remote host 192.168.2.1 is sending [ 5] local 192.168.2.130 port 49594 connected to 192.168.2.1 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-10.00 sec 1.22 GBytes 1.05 Gbits/sec [ 5] 10.00-20.00 sec 1.36 GBytes 1.17 Gbits/sec [ 5] 20.00-30.00 sec 1.31 GBytes 1.12 Gbits/sec [ 5] 30.00-40.00 sec 1.46 GBytes 1.26 Gbits/sec [ 5] 40.00-50.00 sec 1.47 GBytes 1.26 Gbits/sec [ 5] 50.00-60.00 sec 1.46 GBytes 1.26 Gbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-60.05 sec 8.29 GBytes 1.19 Gbits/sec 1 sender [ 5] 0.00-60.00 sec 8.29 GBytes 1.19 Gbits/sec receiver iperf Done. |
因此,这个问题不得不重新审视了。
NanoPi R5S中的M.2 NVMe SSD安装
我不久前购买了APACER AS2280(AP256GAS2280P4-1)PCIe Gen 3.0 x4 SSD,它在正确的硬件上可以实现高达1,800 MB/s的顺序读取速度和高达1,100 MB/s的顺序写入速度。

安装过程很简单,因为我只需要松开四个螺丝即可卸下底盖,安装SSD,然后用他们提供的螺丝将其固定好。

在NanoPi R5S上安装Ubuntu 20.04 FriendlyCore
我首先尝试使用eflasher镜像安装FriendlyCore。

操作之后感觉还不错,所以我重新启动了路由器,但后来我注意到TP-Link开关上没有显示 WAN接口链接,只有电源LED亮起了,电源LED亮起对于FriendlyCore/Ubuntu镜像来说是正常的。我再次尝试,通过单击“完成”进入eflasher UI设置,但还是不行。

因此,我下载了“SD”镜像用来帮助直接从microSD卡启动,并从那里运行操作系统。这样做之后,运行还是正常的。不过,如果你们打算将NanoPi R5S用于多种用途而且还期待在Ubuntu 20.04镜像中使用桌面环境,那么可能会感到很失望,因 HDMI输出目前只能用于访问终端。

FriendlyCore系统信息
你们可以在CNX Software Pastebin上找到启动日志。我使用pi/pi凭据(用户名/密码)通过过了SSH登录,并将系统升级到了最新软件包:
1 2 |
sudo apt update sudo apt dist-upgrade |
现在,我们运行一些命令来获取系统信息:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
pi@FriendlyELEC:~$ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=20.04 DISTRIB_CODENAME=focal DISTRIB_DESCRIPTION="Ubuntu 20.04.4 LTS" 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:~$ free -mh total used free shared buff/cache available Mem: 1.9Gi 150Mi 1.7Gi 3.0Mi 114Mi 1.7Gi Swap: 0B 0B 0B pi@FriendlyELEC:~$ df -mh Filesystem Size Used Avail Use% Mounted on udev 969M 0 969M 0% /dev tmpfs 197M 480K 196M 1% /run overlay 27G 1013M 26G 4% / tmpfs 981M 0 981M 0% /dev/shm tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 981M 0 981M 0% /sys/fs/cgroup tmpfs 197M 0 197M 0% /run/user/1000 |
除了NVMe驱动器没有自动挂载,一切看起来都还不错。现在我们用inxi找到更多细节:
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 |
pi@FriendlyELEC:~$ inxi -Fc0 System: Host: FriendlyELEC Kernel: 5.10.66 aarch64 bits: 64 Console: tty 0 Distro: Ubuntu 20.04.4 LTS (Focal Fossa) Machine: Type: ARM Device System: FriendlyElec NanoPi R5S details: N/A serial: 8cbfe79e107c459c Battery: ID-1: test_battery charge: 100% condition: N/A CPU: Topology: Quad Core model: N/A variant: cortex-a55 bits: 64 type: MCP Speed: 408 MHz min/max: 408/1992 MHz Core speeds (MHz): 1: 1992 2: 1992 3: 1992 4: 1992 Graphics: Device-1: display-subsystem driver: rockchip_drm v: N/A Device-2: mali-bifrost driver: mali v: N/A Device-3: rk3568-dw-hdmi driver: dwhdmi_rockchip v: N/A Display: server: X.org 1.20.8 driver: dwhdmi_rockchip tty: 80x24 Message: Advanced graphics data unavailable in console. Try -G --display Audio: Device-1: rk3568-dw-hdmi driver: dwhdmi_rockchip Device-2: simple-audio-card driver: asoc_simple_card Device-3: simple-audio-card driver: N/A Device-4: simple-audio-card driver: asoc_simple_card Sound Server: ALSA v: k5.10.66 Network: Device-1: Realtek RTL8125 2.5GbE driver: r8125 IF: eth1 state: down mac: e2:1d:62:a1:1a:ca Device-2: Realtek RTL8125 2.5GbE driver: r8125 IF: eth1 state: down mac: e2:1d:62:a1:1a:ca Device-3: rk3568-gmac driver: rk_gmac_dwmac IF-ID-1: eth0 state: up speed: 1000 Mbps duplex: full mac: de:1d:62:a1:1a:ca IF-ID-2: eth2 state: down mac: 12:bf:2b:d6:4b:e0 Drives: Local Storage: total: 274.88 GiB used: 1012.3 MiB (0.4%) ID-1: /dev/mmcblk0 model: SD16G size: 29.12 GiB ID-2: /dev/mmcblk2 model: 8GTF4R size: 7.28 GiB ID-3: /dev/nvme0n1 vendor: Apacer model: AS2280P4 256GB size: 238.47 GiB Partition: ID-1: / size: 26.48 GiB used: 1012.3 MiB (3.7%) fs: overlay source: ERR-102 Sensors: System Temperatures: cpu: 46.1 C mobo: N/A Fan Speeds (RPM): N/A Info: Processes: 130 Uptime: 7m Memory: 1.92 GiB used: 211.4 MiB (10.8%) Init: systemd Shell: bash inxi: 3.0.38 |
只有eth0 WAN端口打开了,eth1/eth2 2.5GbE端口是关闭的,根本没有显示配置。FriendlyElec方面似乎主要关注FriendlyWrt镜像,他们告诉我还没有在FriendlyCore上实现优化,所以大多数人可能使用的还是FriendlyWrt,因为它更容易配置网络和路由器设置。我看到Apacer AS2280P4 SSD其实被检测到了,但是它没有开箱即被格式化,所以我只能用mkfs.ext4将其格式化。
NanoPi R5S基准测试
现在我们通过在路由器上运行SBC Bench的方式来对CPU进行基准测试,希望尽可能可以发现一些问题:
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 |
$ sudo /bin/bash ./sbc-bench.sh -c [sudo] password for pi: WARNING: dmesg output does not contain early boot messages which help in identifying hardware details. It is recommended to reboot now and then execute the benchmarks. Press [ctrl]-[c] to stop or [enter] to continue. Average load and/or CPU utilization too high (too much background activity). Waiting... Too busy for benchmarking: 07:21:06 up 3 min, 1 user, load average: 0.41, 0.27, 0.11, cpu: 3% Too busy for benchmarking: 07:21:11 up 3 min, 1 user, load average: 0.38, 0.26, 0.11, cpu: 1% Too busy for benchmarking: 07:21:16 up 3 min, 1 user, load average: 0.35, 0.26, 0.11, cpu: 1% Too busy for benchmarking: 07:21:21 up 3 min, 1 user, load average: 0.32, 0.25, 0.11, cpu: 1% Too busy for benchmarking: 07:21:26 up 3 min, 1 user, load average: 0.29, 0.25, 0.11, cpu: 1% Too busy for benchmarking: 07:21:31 up 3 min, 1 user, load average: 0.27, 0.24, 0.10, cpu: 1% sbc-bench v0.9.7 Installing needed tools. This may take some time. Done. Checking cpufreq OPP. Done (results will be available in 20-28 minutes). Executing tinymembench. Done. Executing RAM latency tester. Done. Executing OpenSSL benchmark. Done. Executing 7-zip benchmark. Done. Executing cpuminer. 5 more minutes to wait. Done. Checking cpufreq OPP. Done (23 minutes elapsed). Memory performance: memcpy: 2800.5 MB/s memset: 6191.5 MB/s (0.2%) Cpuminer total scores (5 minutes execution): 6.87,6.86,6.85,6.84,6.83,6.82,6.79 kH/s 7-zip total scores (3 consecutive runs): 4756,4768,4727 OpenSSL results: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-cbc 173609.37k 509936.75k 972013.31k 1264387.07k 1383497.73k 1392645.46k aes-128-cbc 175451.26k 506569.66k 973690.71k 1264628.74k 1382845.10k 1393180.67k aes-192-cbc 166539.51k 448796.48k 790104.58k 970846.55k 1040621.57k 1046462.46k aes-192-cbc 168407.31k 451709.25k 792148.91k 970579.63k 1041061.21k 1046375.08k aes-256-cbc 159430.38k 412822.74k 676804.10k 809129.64k 857347.41k 861137.58k aes-256-cbc 162313.43k 412763.39k 677746.94k 809317.38k 857642.33k 861334.19k Unable to upload full test results. Please copy&paste the below stuff to pastebin.com and provide the URL. Check the output for throttling and swapping please. |
我几乎在boot后立即启动了它,因此dmesg输出应该是完整的(具体可参考此次评测前面的boot加载),不过脚本中缺少一些信息。sbc-bench.sh脚本的完整输出可以在pastebin上找到,我们看到“1992”MHz广告频率在现实中被测试为1845 MHz,因此我觉得可以在这里进行一些优化。
7zip仍然比NanoPi R2S路由器( 3871 )更快,或者说性能提高了大约23%,而AES-256-CBC 16KB大约快了22% ( 704,872.45 vs 861,334.19kH/s)
NVMe基准测试
我用iozone 3对NVMe SSD进行了3次测试,其中1次是100MB的文件:
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 |
pi@FriendlyELEC:/media/nvme0n1$ sudo iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 Iozone: Performance Test of File I/O Version $Revision: 3.489 $ Compiled for 64 bit mode. Build: linux Include fsync in write timing O_DIRECT feature enabled Auto Mode File size set to 102400 kB Record Size 4 kB Record Size 16 kB Record Size 512 kB Record Size 1024 kB Record Size 16384 kB Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 Output is in kBytes/sec Time Resolution = 0.000001 seconds. Processor cache size set to 1024 kBytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 102400 4 34994 53668 30431 30385 30136 59719 102400 16 102031 130543 80174 80125 79796 133162 102400 512 300692 296328 276975 291837 276681 313464 102400 1024 309822 340026 308900 326826 306102 339059 102400 16384 357975 392544 369753 391219 370336 390004 iozone test complete. |
然后是一个500MB的文件:
1 2 3 4 5 6 7 8 |
pi@FriendlyELEC:/media/nvme0n1$ sudo iozone -e -I -a -s 500M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 512000 4 35308 62195 30436 30380 30251 61600 512000 16 101504 134916 80454 80449 79642 133631 512000 512 293784 308843 284081 284902 281025 306749 512000 1024 326784 333909 318075 321837 315874 333259 512000 16384 378436 383013 381319 383621 382224 381967 |
最后是一个1GB的文件:
1 2 3 4 5 6 7 8 |
pi@FriendlyELEC:/media/nvme0n1$ sudo iozone -e -I -a -s 1000M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 1024000 4 35105 58082 30395 30447 27458 60895 1024000 16 102421 135279 80210 80314 74596 133579 1024000 512 300759 314704 282743 283883 277911 313413 1024000 1024 329840 337468 318228 319091 317641 337714 1024000 16384 383289 385247 382642 382850 382870 381344 |
一系列操作之后,结果在所有三个测试中都或多或少是一致的,没有太大的变化。最后我得到了大约380MB/s的读写速度,这远远低于SSD原本宣传的写入和读取速度,以及ODROID-M1的结果。我想这是不是因为本设计中使用的是PCIe 2.0 x1接口,而不是Hardkernel板中使用的PCIe Gen 3.0 x2接口。
下面是lspci的输出,仅供参考:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
pi@FriendlyELEC:/media/nvme0n1$ sudo lspci -v 0002:21:00.0 Non-Volatile memory controller: Phison Electronics Corporation Device 5013 (rev 01) (prog-if 02 [NVM Express]) Subsystem: Phison Electronics Corporation Device 5013 Flags: bus master, fast devsel, latency 0, IRQ 87 Memory at 380900000 (64-bit, non-prefetchable) [size=16K] Capabilities: [80] Express Endpoint, MSI 00 Capabilities: [d0] MSI-X: Enable+ Count=9 Masked- Capabilities: [e0] MSI: Enable- Count=1/8 Maskable+ 64bit+ Capabilities: [f8] Power Management version 3 Capabilities: [100] Latency Tolerance Reporting Capabilities: [110] L1 PM Substates Capabilities: [200] Advanced Error Reporting Capabilities: [300] Secondary PCI Express Kernel driver in use: nvme |
2.5GbE接口配置和基准测试

由于开箱即用只配置了eth0千兆以太网“WAN”接口,因此我们必须手动配置两个2.5GbE端口。我使用了与“第一部分FriendlyWrt评测”相同的测试平台,即Ubuntu 20.04笔记本电脑。接着,我将Realtek RTL8156BG USB 3.0到2.5GbE的加密狗连接到eth1、UP Xtreme i11迷你PC连接到eth2。我并没有像在FriendlyWrt中那样使用桥接接口,而是配置了两个不同的子网:eth1是192.168.2.0、eth2是192.168.3.0。
现在我们在/etc/network/interfaces.d/中创建两个新文件:
- eth1
1 2 3 4 5 6 |
auto eth1 iface eth1 inet static address 192.168.2.1 network 192.168.2.0 netmask 255.255.255.0 broadcast 192.168.2.255 |
- eth2
1 2 3 4 5 6 |
auto eth2 iface eth2 inet static address 192.168.3.1 network 192.168.3.0 netmask 255.255.255.0 broadcast 192.168.3.255 |
现在安装DHCP服务器
1 |
sudo apt install isc-dhcp-server |
使用我们的两个子网编辑/etc/dhcp/dhcpd.conf文件:
1 2 3 4 5 6 7 8 9 |
subnet 192.168.2.0 netmask 255.255.255.0 { range 192.168.2.100 192.168.2.200; option routers 192.168.2.1; } subnet 192.168.3.0 netmask 255.255.255.0 { range 192.168.3.100 192.168.3.200; option routers 192.168.3.1; } |
在重新启动dhcp服务器之前:
1 |
sudo systemctl restart isc-dhcp-server |
此时,笔记本电脑和迷你PC应该可以从各自子网上的NanoPi R5S获取到它们的IP地址了。现在我们可以开始对接口进行基准测试了。使用连接到笔记本电脑的eth1下载iperf3,然后从R5S的角度接收:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
$ iperf3 -t 60 -c 192.168.2.1 -i 10 Connecting to host 192.168.2.1, port 5201 [ 5] local 192.168.2.130 port 59822 connected to 192.168.2.1 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-10.00 sec 2.28 GBytes 1.96 Gbits/sec 42 1.41 MBytes [ 5] 10.00-20.00 sec 2.02 GBytes 1.74 Gbits/sec 0 1.61 MBytes [ 5] 20.00-30.00 sec 1.72 GBytes 1.48 Gbits/sec 0 1.62 MBytes [ 5] 30.00-40.00 sec 1.87 GBytes 1.61 Gbits/sec 0 1.62 MBytes [ 5] 40.00-50.00 sec 1.89 GBytes 1.62 Gbits/sec 0 1.70 MBytes [ 5] 50.00-60.00 sec 2.06 GBytes 1.77 Gbits/sec 21 1.66 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-60.00 sec 11.8 GBytes 1.70 Gbits/sec 63 sender [ 5] 0.00-60.04 sec 11.8 GBytes 1.69 Gbits/sec receiver iperf Done. |
这比我在OpenWrt中得到的1.85 Gbps要慢一些,而且还有部重传内容。在传输过程中,我还使用l sbc-bench.sh监控系统:
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 |
pi@FriendlyELEC:~$ sudo ./sbc-bench.sh -m Rockchip RK3568 (35682000), Kernel: aarch64, Userland: arm64 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 Thermal source: /sys/devices/virtual/thermal/thermal_zone0/ (soc-thermal) Time CPU load %cpu %sys %usr %nice %io %irq Temp 03:38:07: 1416MHz 0.32 5% 3% 1% 0% 0% 0% 55.0°C 03:38:12: 1992MHz 0.37 35% 15% 0% 0% 0% 20% 56.7°C 03:38:17: 1992MHz 0.42 43% 18% 0% 0% 0% 24% 58.3°C 03:38:23: 1992MHz 0.47 42% 17% 0% 0% 0% 23% 57.2°C 03:38:28: 1992MHz 0.51 29% 10% 0% 0% 0% 18% 56.7°C 03:38:33: 1992MHz 0.55 29% 10% 0% 0% 0% 18% 57.2°C 03:38:38: 1992MHz 0.59 26% 8% 0% 0% 0% 17% 56.7°C 03:38:43: 1992MHz 0.62 33% 12% 0% 0% 0% 20% 57.2°C 03:38:48: 1992MHz 0.65 30% 11% 0% 0% 0% 18% 57.2°C 03:38:53: 1992MHz 0.68 26% 7% 0% 0% 0% 17% 57.2°C 03:38:58: 1992MHz 0.79 37% 15% 0% 0% 0% 21% 57.2°C 03:39:03: 1992MHz 0.80 34% 13% 0% 0% 0% 20% 57.2°C 03:39:09: 1104MHz 0.82 34% 14% 0% 0% 0% 19% 55.0°C |
该系统在测试期间确实以其在宣传中提到的最大频率运行了,在这里我没有看到任何明显的问题。
我还使用ethtool检查了一些信息和统计信息:
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 |
pi@FriendlyELEC:~$ sudo ethtool -i eth1 driver: r8125 version: 9.008.00-NAPI firmware-version: expansion-rom-version: bus-info: 0000:01:00.0 supports-statistics: yes supports-test: no supports-eeprom-access: no supports-register-dump: yes supports-priv-flags: no pi@FriendlyELEC:~$ sudo ethtool -S eth1 NIC statistics: tx_packets: 451228 rx_packets: 9569147 tx_errors: 0 rx_errors: 0 rx_missed: 0 align_errors: 0 tx_single_collisions: 0 tx_multi_collisions: 0 unicast: 9569102 broadcast: 45 multicast: 0 tx_aborted: 0 tx_underrun: 0 tx_octets: 31676089 rx_octets: 14506385933 rx_multicast64: 0 tx_unicast64: 451214 tx_broadcast64: 2 tx_multicast64: 12 tx_pause_on: 570 tx_pause_off: 570 tx_pause_all: 1140 tx_deferred: 0 tx_late_collision: 0 tx_all_collision: 0 tx_aborted32: 0 align_errors32: 0 rx_frame_too_long: 0 rx_runt: 0 rx_pause_on: 0 rx_pause_off: 0 rx_pause_all: 0 rx_unknown_opcode: 0 rx_mac_error: 0 tx_underrun32: 0 rx_mac_missed: 31 rx_tcam_dropped: 0 tdu: 0 rdu: 570 |
我确实得到了一些rx_mac_missed。现在我们反过来测试一下:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
$ iperf3 -t 60 -c 192.168.2.1 -i 10 -R Connecting to host 192.168.2.1, port 5201 Reverse mode, remote host 192.168.2.1 is sending [ 5] local 192.168.2.130 port 59826 connected to 192.168.2.1 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-10.00 sec 1.75 GBytes 1.50 Gbits/sec [ 5] 10.00-20.00 sec 1.95 GBytes 1.67 Gbits/sec [ 5] 20.00-30.00 sec 1.95 GBytes 1.67 Gbits/sec [ 5] 30.00-40.00 sec 1.95 GBytes 1.67 Gbits/sec [ 5] 40.00-50.00 sec 1.94 GBytes 1.67 Gbits/sec [ 5] 50.00-60.00 sec 1.94 GBytes 1.67 Gbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-60.04 sec 11.5 GBytes 1.64 Gbits/sec 0 sender [ 5] 0.00-60.00 sec 11.5 GBytes 1.64 Gbits/sec receiver iperf Done. |
这看起来比OpenWrt(1.12Gbps)要得好得多了。
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 |
pi@FriendlyELEC:~$ sudo ./sbc-bench.sh -m Rockchip RK3568 (35682000), Kernel: aarch64, Userland: arm64 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 Thermal source: /sys/devices/virtual/thermal/thermal_zone0/ (soc-thermal) Time CPU load %cpu %sys %usr %nice %io %irq Temp 03:56:48: 1416MHz 0.00 2% 1% 0% 0% 0% 1% 55.0°C 03:56:53: 1992MHz 0.00 23% 17% 0% 0% 0% 4% 57.2°C 03:56:58: 1992MHz 0.30 31% 27% 0% 0% 0% 3% 57.2°C 03:57:03: 1992MHz 0.36 31% 27% 0% 0% 0% 3% 57.8°C 03:57:08: 1992MHz 0.41 31% 27% 0% 0% 0% 3% 57.8°C 03:57:13: 1992MHz 0.46 31% 27% 0% 0% 0% 3% 57.8°C 03:57:19: 1992MHz 0.50 31% 27% 0% 0% 0% 3% 57.8°C 03:57:24: 1992MHz 0.62 31% 27% 0% 0% 0% 3% 57.8°C 03:57:29: 1992MHz 0.65 31% 28% 0% 0% 0% 2% 58.3°C 03:57:34: 1992MHz 0.68 31% 27% 0% 0% 0% 2% 58.3°C 03:57:39: 1992MHz 0.71 31% 27% 0% 0% 0% 2% 57.8°C 03:57:44: 1992MHz 0.73 31% 28% 0% 0% 0% 3% 58.3°C 03:57:49: 1104MHz 0.75 26% 22% 0% 0% 0% 3% 55.0°C |
IRQ百分比要比Rx低得多,但我认为这对于Tx 来说是正常的。我们切换到连接到UP Xtreme i11的eth2:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
devkit@UPX-i11:~$ iperf3 -t 60 -c 192.168.3.1 -i10 Connecting to host 192.168.3.1, port 5201 [ 5] local 192.168.3.100 port 37794 connected to 192.168.3.1 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-10.00 sec 2.73 GBytes 2.35 Gbits/sec 0 1.81 MBytes [ 5] 10.00-20.00 sec 2.73 GBytes 2.35 Gbits/sec 0 1.81 MBytes [ 5] 20.00-30.00 sec 2.73 GBytes 2.35 Gbits/sec 0 1.81 MBytes [ 5] 30.00-40.00 sec 2.73 GBytes 2.34 Gbits/sec 0 2.90 MBytes [ 5] 40.00-50.00 sec 2.73 GBytes 2.35 Gbits/sec 0 4.37 MBytes [ 5] 50.00-60.00 sec 2.73 GBytes 2.35 Gbits/sec 0 4.37 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-60.00 sec 16.4 GBytes 2.35 Gbits/sec 0 sender [ 5] 0.00-60.00 sec 16.4 GBytes 2.35 Gbits/sec receiver iperf Done. |
哦,太好了!这是我第一次得到了2.35 Gbps的传输速度,所以看起来还是有希望的!
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 |
pi@FriendlyELEC:~$ sudo ./sbc-bench.sh -m Rockchip RK3568 (35682000), Kernel: aarch64, Userland: arm64 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 Thermal source: /sys/devices/virtual/thermal/thermal_zone0/ (soc-thermal) Time CPU load %cpu %sys %usr %nice %io %irq Temp 04:11:00: 1104MHz 0.00 2% 1% 0% 0% 0% 0% 53.8°C 04:11:05: 1992MHz 0.08 34% 12% 0% 0% 0% 21% 56.1°C 04:11:10: 1992MHz 0.23 40% 14% 0% 0% 0% 25% 56.1°C 04:11:15: 1992MHz 0.30 40% 15% 0% 0% 0% 25% 57.2°C 04:11:20: 1992MHz 0.43 40% 14% 0% 0% 0% 25% 57.2°C 04:11:25: 1992MHz 0.48 41% 15% 0% 0% 0% 25% 56.7°C 04:11:30: 1992MHz 0.60 40% 15% 0% 0% 0% 25% 57.2°C 04:11:36: 1992MHz 0.71 40% 14% 0% 0% 0% 25% 57.2°C 04:11:41: 1992MHz 0.74 41% 15% 0% 0% 0% 25% 57.2°C 04:11:46: 1992MHz 0.84 40% 14% 0% 0% 0% 25% 56.7°C 04:11:51: 1992MHz 0.85 40% 14% 0% 0% 0% 25% 57.2°C 04:11:56: 1992MHz 0.86 40% 14% 0% 0% 0% 25% 56.7°C 04:12:01: 1416MHz 0.87 35% 13% 0% 0% 0% 21% 53.8°C |
除非我弄错了,否者25%的IRQ就意味着一个core可以被充分利用来处理这些了。现在我们试试:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
devkit@UPX-i11:~$ iperf3 -t 60 -c 192.168.3.1 -i 10 -R Connecting to host 192.168.3.1, port 5201 Reverse mode, remote host 192.168.3.1 is sending [ 5] local 192.168.3.100 port 37800 connected to 192.168.3.1 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-10.00 sec 1.92 GBytes 1.65 Gbits/sec [ 5] 10.00-20.00 sec 1.84 GBytes 1.58 Gbits/sec [ 5] 20.00-30.00 sec 1.84 GBytes 1.58 Gbits/sec [ 5] 30.00-40.00 sec 1.84 GBytes 1.58 Gbits/sec [ 5] 40.00-50.00 sec 1.84 GBytes 1.58 Gbits/sec [ 5] 50.00-60.00 sec 1.84 GBytes 1.58 Gbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-60.01 sec 11.1 GBytes 1.59 Gbits/sec 0 sender [ 5] 0.00-60.00 sec 11.1 GBytes 1.59 Gbits/sec receiver iperf Done. |
结果是1.59 Gbps,不是很完美,但仍然还是比OpenWrt更好。
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 |
pi@FriendlyELEC:~$ sudo ./sbc-bench.sh -m Rockchip RK3568 (35682000), Kernel: aarch64, Userland: arm64 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 Thermal source: /sys/devices/virtual/thermal/thermal_zone0/ (soc-thermal) Time CPU load %cpu %sys %usr %nice %io %irq Temp 04:13:37: 1104MHz 0.31 3% 1% 0% 0% 0% 1% 53.8°C 04:13:42: 1992MHz 0.37 25% 22% 0% 0% 0% 3% 56.1°C 04:13:47: 1992MHz 0.42 31% 27% 0% 0% 0% 3% 56.1°C 04:13:52: 1992MHz 0.47 30% 25% 0% 0% 0% 4% 56.1°C 04:13:58: 1992MHz 0.51 30% 25% 0% 0% 0% 4% 56.1°C 04:14:03: 1992MHz 0.55 30% 25% 0% 0% 0% 4% 56.1°C 04:14:08: 1992MHz 0.58 30% 25% 0% 0% 0% 4% 56.1°C 04:14:13: 1992MHz 0.62 30% 25% 0% 0% 0% 5% 56.1°C 04:14:18: 1992MHz 0.65 30% 25% 0% 0% 0% 5% 56.1°C 04:14:23: 1992MHz 0.68 30% 25% 0% 0% 0% 4% 56.1°C 04:14:28: 1992MHz 0.70 30% 25% 0% 0% 0% 4% 56.1°C 04:14:34: 1992MHz 0.82 30% 26% 0% 0% 0% 4% 56.1°C 04:14:39: 1104MHz 0.76 26% 22% 0% 0% 0% 3% 53.8°C ^C |
CPU再次以全速运行了,而且距离100%的利用率差太多了,所以我觉得问题应该出在其他地方了。现在我们可以再次使用ethtool检查eth2信息和统计信息。
1 2 3 4 5 6 7 8 9 10 11 |
$ sudo ethtool -i eth2 driver: r8125 version: 9.008.00-NAPI firmware-version: expansion-rom-version: bus-info: 0001:11:00.0 supports-statistics: yes supports-test: no supports-eeprom-access: no supports-register-dump: yes supports-priv-flags: no |
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 |
sudo ethtool -S eth2 NIC statistics: tx_packets: 8506609 rx_packets: 12553353 tx_errors: 0 rx_errors: 0 rx_missed: 0 align_errors: 0 tx_single_collisions: 0 tx_multi_collisions: 0 unicast: 12553209 broadcast: 144 multicast: 0 tx_aborted: 0 tx_underrun: 0 tx_octets: 12543719502 rx_octets: 18471602900 rx_multicast64: 0 tx_unicast64: 8503557 tx_broadcast64: 3035 tx_multicast64: 17 tx_pause_on: 35 tx_pause_off: 35 tx_pause_all: 70 tx_deferred: 0 tx_late_collision: 0 tx_all_collision: 0 tx_aborted32: 0 align_errors32: 0 rx_frame_too_long: 0 rx_runt: 0 rx_pause_on: 0 rx_pause_off: 0 rx_pause_all: 0 rx_unknown_opcode: 0 rx_mac_error: 0 tx_underrun32: 0 rx_mac_missed: 335 rx_tcam_dropped: 0 tdu: 0 rdu: 35 |
在这儿的测试结果中,我发现有更多的rx_mac_missed。所以我猜想应该会有一些调整来提高性能。但根据之前我对RTL8156B调整设置的经验,调整设置真的很棘手,而且对此有经验的人似乎在具体调整什么设置选项上无法达成一致意见,我主要指的是致力于RTL8156/8125驱动的Realtek工程师,以及读者中的一些网络专家。
在两个2.5GbE接口之间配置NAT
由于2.5GbE接口不能与iperf3达成最佳配合,我就没有费心在FriendlyWrt中测试路由器性能了,但还是有几个人问我。所以接下来我将会展示我如何在Ubuntu 20.04中配置NAT,并且会继续测试NAT性能,记住它肯定会在几周或几个月内得到很大改善。
在这里,我们需要启用IP转发和NAT。我使用的指令改编自一篇networkreverse上的帖子。
编辑/etc/sysctl.conf以启用IP转发(取消注释以下行):
1 |
net.ipv4.ip_forward=1 |
应用更改:
1 |
sudo sysctl -p |
现在我们启用NAT:
1 |
sudo iptables ! -o lo -t nat -A POSTROUTING -j MASQUERADE |
我们现在可以在192.168.2.0子网的笔记本电脑上ping 192.168.3.0子网上的Xtreme i11了:
1 2 3 4 |
jaufranc@cnx-laptop-4:~$ ping 192.168.3.100 PING 192.168.3.100 (192.168.3.100) 56(84) bytes of data. 64 bytes from 192.168.3.100: icmp_seq=1 ttl=63 time=0.690 ms 64 bytes from 192.168.3.100: icmp_seq=2 ttl=63 time=0.764 ms |
如果你们想让更改永久有效,可执行如下:
1 2 |
sudo apt install iptables-persistent sudo sh -c 'iptables-save > /etc/iptables/rules.v4' |
我在UP Xtreme i11和我的笔记本电脑之间尝试了iperf3,数据通过NanoPi R5S路由器路由。
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 |
jaufranc@cnx-laptop-4:~$ iperf3 -t 60 -c 192.168.3.100 -i 10 Connecting to host 192.168.3.100, port 5201 [ 5] local 192.168.2.130 port 59430 connected to 192.168.3.100 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-10.00 sec 914 MBytes 767 Mbits/sec 355 1011 KBytes [ 5] 10.00-20.00 sec 912 MBytes 765 Mbits/sec 324 1.23 MBytes [ 5] 20.00-30.00 sec 917 MBytes 769 Mbits/sec 124 1.09 MBytes [ 5] 30.00-40.00 sec 915 MBytes 767 Mbits/sec 150 942 KBytes [ 5] 40.00-50.00 sec 915 MBytes 767 Mbits/sec 78 1.22 MBytes [ 5] 50.00-60.00 sec 919 MBytes 771 Mbits/sec 64 1.03 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-60.00 sec 5.36 GBytes 768 Mbits/sec 1095 sender [ 5] 0.00-60.06 sec 5.36 GBytes 767 Mbits/sec receiver iperf Done. jaufranc@cnx-laptop-4:~$ iperf3 -t 60 -c 192.168.3.100 -i 10 -R Connecting to host 192.168.3.100, port 5201 Reverse mode, remote host 192.168.3.100 is sending [ 5] local 192.168.2.130 port 59434 connected to 192.168.3.100 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-10.00 sec 1.09 GBytes 935 Mbits/sec [ 5] 10.00-20.00 sec 1.09 GBytes 938 Mbits/sec [ 5] 20.00-30.00 sec 1.09 GBytes 938 Mbits/sec [ 5] 30.00-40.00 sec 1.09 GBytes 938 Mbits/sec [ 5] 40.00-50.00 sec 1.09 GBytes 939 Mbits/sec [ 5] 50.00-60.00 sec 1.09 GBytes 937 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-60.05 sec 6.55 GBytes 937 Mbits/sec 973 sender [ 5] 0.00-60.00 sec 6.55 GBytes 937 Mbits/sec receiver iperf Done. |
一个方向的传输速度是768 Mbps,另一方向则是937 Mbps。
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 |
pi@FriendlyELEC:~$ sudo ./sbc-bench.sh -m Rockchip RK3568 (35682000), Kernel: aarch64, Userland: arm64 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 Thermal source: /sys/devices/virtual/thermal/thermal_zone0/ (soc-thermal) Time CPU load %cpu %sys %usr %nice %io %irq Temp 05:00:01: 1608MHz 0.16 4% 3% 0% 0% 0% 1% 52.5°C 05:00:06: 1992MHz 0.15 21% 0% 0% 0% 1% 19% 53.8°C 05:00:11: 1992MHz 0.22 25% 0% 0% 0% 0% 25% 53.8°C 05:00:16: 1992MHz 0.28 25% 0% 0% 0% 0% 25% 53.8°C 05:00:21: 1992MHz 0.34 25% 0% 0% 0% 0% 25% 53.8°C 05:00:26: 1992MHz 0.39 25% 0% 0% 0% 0% 25% 53.8°C 05:00:31: 1992MHz 0.44 25% 0% 0% 0% 0% 25% 54.4°C 05:00:36: 1992MHz 0.49 25% 0% 0% 0% 0% 25% 53.8°C 05:00:41: 1992MHz 0.53 25% 0% 0% 0% 0% 25% 53.8°C 05:00:47: 1992MHz 0.57 25% 0% 0% 0% 0% 25% 53.8°C 05:00:52: 1992MHz 0.84 25% 0% 0% 0% 0% 24% 53.8°C 05:00:57: 1992MHz 0.94 25% 0% 0% 0% 0% 25% 54.4°C 05:01:02: 1104MHz 0.86 24% 0% 0% 0% 0% 24% 52.5°C 05:01:07: 1992MHz 0.79 16% 0% 0% 0% 0% 15% 54.4°C 05:01:12: 1992MHz 0.81 25% 0% 0% 0% 0% 25% 54.4°C 05:01:17: 1992MHz 0.83 25% 0% 0% 0% 0% 25% 54.4°C 05:01:22: 1992MHz 0.84 25% 0% 0% 0% 0% 24% 54.4°C 05:01:27: 1992MHz 0.85 25% 0% 0% 0% 0% 25% 55.0°C 05:01:33: 1992MHz 0.87 25% 0% 0% 0% 0% 25% 54.4°C 05:01:38: 1992MHz 0.88 25% 0% 0% 0% 0% 25% 54.4°C 05:01:43: 1992MHz 0.89 25% 0% 0% 0% 0% 25% 55.0°C 05:01:48: 1992MHz 0.90 25% 0% 0% 0% 0% 25% 54.4°C 05:01:53: 1992MHz 0.90 25% 0% 0% 0% 0% 25% 54.4°C 05:01:58: 1992MHz 0.91 25% 0% 0% 0% 0% 25% 54.4°C 05:02:03: 1992MHz 0.92 25% 0% 0% 0% 0% 25% 54.4°C |
如果使用sbc-bench.sh监控显示处理器,其运行频率会是1992 MHz(实际上是1845 MHz),而且25%的IRQ应该就意味着一个core已完全被用于处理IRQ了。
根据mpstat命令显示来看,这应该是由core #0处理的。
1 2 3 4 5 6 7 8 9 |
$ mpstat -P ALL -I SUM Linux 5.10.66 (FriendlyELEC) 06/05/22 _aarch64_ (4 CPU) 09:52:53 CPU intr/s 09:52:53 all 226.34 09:52:53 0 174.51 09:52:53 1 20.32 09:52:53 2 21.34 09:52:53 3 10.16 |
上面这一点可以通过使用top和htop来确认。
NanoPi R5S功耗
我刚好有一个壁式功率计,可以用它来检查功耗:
- 空闲 – 5.1 W
- Iperf3到eth1 – 6.3到6.7W
- 笔记本电脑和迷你电脑之间的NAT测试 – 6.2W
上面的数据是在在该产品上安装了Ubuntu 20.04和NVMe SSD后测试的。
我还在使用OpenWrt且没有SSD的NanoPi R5S上进行了测试:
- 空闲 – 4.6W
- Iperf3 – 6.0至6.2 W
注意,由于我使用的是壁挂式功率计,因此这个数值将包括电源适配器(Khadas VIM4 USB-C 电源适配器)中的效率损失。而且该值可能高于使用USB-C功率计时的数值。这应该也可以通过设置来优化功耗。
最终结论
今天的测评就到这里了。优化部分其实应该还包括“更改固件使Rockchip内核以1992 MHz 运行”、“调整与PCIe和以太网设置相关的各种设置”等等。其中的大部分目前我还不是很熟悉。
最后,十分感谢FriendlyElec寄送NanoPi R5S迷你路由器给我。这款带有金属外壳的路由器你们可以在FriendlyElec网站上购买,其价格是75美元,或者你也可以只购买开发板本身,其价格是59美元。该路由器在全球速卖通的多家网店都可以买到,其中一些卖家甚至还出售4GB RAM版本。这其实有点奇怪,因为FriendlyElec目前只销售配备2GB RAM的型号。

文章翻译者:Jacob,嵌入式系统测试工程师、RAK高级工程师,物联网行业多年工作经验,熟悉嵌入式开发、测试各个环节,对不同产品有自己专业的分析与评估。