三款软路由评测

分类：数码

浏览数：1325

2022-09-06

（一）、电犀牛R68S软路由评测

一、外观与关键配置解析

1.1 R68S关键配置

电犀牛R68S采用瑞芯微的RK-3568 ARM处理器，22nm工艺，4核Cortex A55架构，主频2Ghz，支持最大8G内存；

RK3568内建1路QSGMII，2条PCIE 3.0X1通道，还带有2个千兆以太网接口，所以用在路由器上可以实现2x2.5Gb+2x1000Mb的4网口组合。

R68S核心配置见下图：

核心配置

CPU旁边的两颗芯片分别为内存和闪存芯片。

LPDDR4内存芯片来自晶存（Rayson），型号为RS1G32LF4D2BDS-53BT，容量为4GB（2GB版本便宜70元）；

eMMC闪存芯片来自FORESEE（深圳江波龙旗下），型号为NCEMASKG-16G，容量为16GB；

处理器的左上角有一颗千兆以太网交换芯片，型号为RTL8211F，看到这个螃蟹标志就知道来自瑞昱；

不是有4个网口吗？其余3颗交换芯片呢？

在主板背面。

两颗2.5Gb交换芯片同样来自瑞昱，型号为RTL8125BG:

主板背面

瑞昱的8125B、英特尔的I225 B3和高通的QCA8081，是目前路由器和NAS上最常见的2.5G交换芯片；

1.2 R68S外观

工程机发来的时候，只有一块裸板。

因为我要做弱电箱内的温度测试，于是几天后老板又发来个外壳（试模用，非最终版）。

我收到的外壳是塑料材质（也有CNC铝壳，价格会100元左右），有大量的散热孔。

正式版外壳会做成磨砂效果

外壳和主板

因为外壳开孔处没有配防尘棉，所以如果你是把R68S放桌面用，还是需要考虑下灰尘的问题，毕竟灰尘是电子设备的第一杀手：

正面

机器的2个侧面同样有大量的散热孔：

机器侧面

如果你和我一样会把R68S放在弱电箱内，那么外壳镂空的设计其实对散热是非常有利的。

但如果你把R68S放在桌面使用，我更建议买CNC铝制外壳，即防尘防水，散热还好。

CNC外壳大概长这样：

CNC外壳初模

1.3 电源

R68S可以买带电源的套装，也可以买单机版。

我实际测了下，用12V 1A的光猫电源适配器也能正常工作。

当然，如果你有接外置硬盘的需求，我建议最好上12V 1.5A的电源适配器。

说到外接硬盘，R68S的USB 3.0性能还是非常强的，读写可以跑到120MB左右。如果想在R68S上接硬盘看电影，不必担心原盘高码率电影会卡顿。

二、性能与稳定性测试

对于一台软路由来说，性能与稳定性同样重要。

2.1 加解密性能

直接看表：

知乎@仙鱼	CPU CoreMARK	AES...	CHA...	AES硬解
R68S（RK3568）	27633	103101	62885	是
N1(S905D)	18704	65377	45712	是
R4S（RK3399）	38275	136089	77899	是
J1900	33985	26550	79185	否
J4125	59931	231907	151102	是

R68S的加解密性能比同为ARM架构的N1要强的多，但是落后6核心的R4S(RK3399)约20%。

R68S的CPU CoreMARK落后J1900约6000分。不过J1900毕竟不支持硬件AES解码，这方面R68S还是有些优势的。

要是跟同样支持AES硬解的J4125比，R68S落后了一半还不止。

虽然分数上R68S并不优秀，但实际使用中，性能绰绰有余。

2.2 NAT性能

NAT性能主要测试宽带速率。测试的拓扑如下：

NAT测试

测试速率如下：

940/100

可以看到，如果除去传输损耗，R68S已经跑到了千兆宽带的极限。

此时CPU负荷在45%左右。

2.3 局域网转发性能

局域网转发能力主要测试R68S 两个2.5G LAN口之间的转发速率，我一共做了3个不同的测试。

3种不同测试的拓扑如下：

3种测试

2.3.1 iPerf3 测试

R68S和电脑上分别安装iPerf3客户端，ThinkPAD X13(2.5G USB 3.0网卡）直连R68S的2.5G网口，测试结果下：

iPerf3

下行速率接近2.1Gb，可能受限于USB网卡性能，上行速率略差些，为1.94Gb。

此时，CPU负荷约为30%左右。

2.3.2 LAN TO LAN测试（2.5G）

2.5G 威联通NAS安装内网SPEEDTEST客户端，与笔记本电脑同时连接到R68S，测试结果如下：

LAN TO LAN

下行速率可以跑到接近极限的2.3Gb左右，而上行仍然落后，多次测试最快只跑到了1.85Gb。

同时，我也试了下大文件传输：

读取速率可以稳定在210MB，峰值可以跑到242MB。

不过写入速度就比较不稳定了，会在150MB上下波动，可能是硬盘速率的有瓶颈，也可能是网卡上行本来就慢。

局域网文件传输速度

2.3.2 LAN TO WIFI6测试（2.5G）

Thinkpad X13的AX200网卡可以在红米AX5400电竞版路由器下实现2402Mb协商速率，而且笔记本电脑大部分时间都是使用WIFI的，所以LAN TO WIFI6的测试也非常有必要:

LAN TO WIFI6

AX5400直连NAS，使用WIFI6能跑到的最大速率为1850/624，中间经过R68S转发后速率略有下降，不过降幅也就5%，可以接受。

2.3.4 局域网转发测试小结

整体来讲，R68S的局域网转发能力还是相当可以的，如果你2.5G的设备不多，那么使用R68S还是可以省一台2.5G交换机的。

不过，如果在R68S上装docker使用的话，那局域网桥接转发性能就会大幅下降了，务必加一台交换机：

2.4 温度与稳定性

R68S的固件由lean大神操刀，就使用10天的情况来看，稳定性还是非常好的。

运行时长

R68S我一直扔在弱电箱里面使用。

目前浙江的室内温度差不多在27度左右，R68S裸板待机温度大约在47度左右。

外壳到了后，我观察了下待机温度飙到了53度左右。

不过，温度上升的不仅仅是R68S，这两天我的红米AX5400路由器，哪怕放在电视柜上，外壳也已经非常烫了。

等到高温时，室内温度可能会有31度左右，弱电箱的温度还会更高，我也会持续更新R68S的温度监测情况。

0815更新：

浙江已经高温40多天了，室内温度基本在32度左右。

在弱电箱里的R68S温度基本在58度左右，使用还是非常稳定的，没有出现过死机和断流情况。

三、玩机教程

这里主要讲一下刷机和部分插件安装的教程

3.1 重置与刷机

R68S带有重置按钮，如果系统混乱了，或者进不去路由器设置页面了，那么按住重置按钮5秒既可以恢复出厂设置（插电状态下），还是非常方便的。

另外要吹一下R68S的刷机，几秒钟就能完成。跟N1刷机相比，真的是天壤之别。

不过，方便归方便，教程还是要学一下的。

1）安装瑞芯微驱动与刷机工具

链接：https://pan.baidu.com/s/1pTxQ1yfjYTccClHcy068aw?pwd=6tnl 
提取码：6tnl

2）准备好刷机固件

3）打开瑞芯微开发工具并选择好固件，如下图所示：

固件选择

4）用双公头USB线的一端连接R68S靠右的USB接口，另一端连接电脑；USB线连好后，先按住Recovery键再插入电源。

刷机顺序

大约两秒后就能在电脑上听到提示音，并且开发工具上也会提示发现设备。

5）在刷机工具上点击“擦除Flash”，等待几秒钟后会提示“擦除Flash成功”，并点击确定：

擦除Flash

6）点击升级，2-3秒后提示下载固件和重启设备成功，刷机就完成了

刷机

3.2 WEB升级

当然了，只有当大版本升级，或者内部分区改变时才需要用到线刷，普通的更新使用WEB升级就可以了：

WEB升级

WEB升级需要“sysupgrade”镜像，文件后缀名一般都是tar。

3.2 插件安装

机器出厂内置的是纯净版的固件，如果需要用到某些固件的话，可以上传IPK或者SSH命令安装。

比如影音玩家非常需要的阿里云盘WebDAV插件在出厂时就没有内置，我们可以用SSH工具或者OpenWRT里TYYD复制进命令安装（逐条复制回车）：

wget https://github.com/messense/aliyundrive-webdav/releases/download/v1.3.2/aliyundrive-webdav_1.3.2-1_aarch64_generic.ipk
wget https://github.com/messense/aliyundrive-webdav/releases/download/v1.3.2/luci-app-aliyundrive-webdav_1.3.2_all.ipk
wget https://github.com/messense/aliyundrive-webdav/releases/download/v1.3.2/luci-i18n-aliyundrive-webdav-zh-cn_1.3.2-1_all.ipk
opkg install aliyundrive-webdav_1.3.2-1_aarch64_generic.ipk
opkg install luci-app-aliyundrive-webdav_1.3.2_all.ipk
opkg install luci-i18n-aliyundrive-webdav-zh-cn_1.3.2-1_all.ipk

安装完成后刷新下，服务里面就有插件了：

阿里云盘

四、总结与购买建议

电犀牛R68S软路由，对于我个人来说是非常合适的。

因为我已经有了带2.5G网口的成品NAS，路由器平时也是使用AP模式，所以对我来说，只需要有一台带2.5G网口的软路由做网关即可。

现在的软路由市场非常卷，J4125的2.5G软路由也降价到了600元左右，如果你有更多的需求，例如爱快分流+OpenWRT旁路由+unraid 的标准all in one玩法，那R68S可能无法满足你的要求。

但如果你和我一样，只需要一台纯粹的软路由，那么R68S还是非常适合你的。

（二）、NanoPi R5S软路由评测

NanoPi R5S开箱

带金属外壳SSD和散热垫的NanoPi R5S

开箱后我发现路由器已经都组装好了，他们还附赠了6个橡胶脚垫和一段3M胶带，通过下文大家就会知道，其实这并不是很需要。

NanoPi R5S

NanoPi R5S一侧有一个microSD卡插槽，后面板则带有一个用于供电的 USB-C端口、一个WiFi天线孔（这个天线孔也可以插GPIO、UART console等线缆），两个2.5GbE RJ45 LAN端口、一个千兆以太网WAN端口和HDMI视频输出。

NanoPi R5S掩码密钥

在NanoPi R5S的另一侧我们会找到一个用于固件升级的掩码按钮，前面板上则有四个用于“系统”和以太网端口的LED灯，以及两个USB 3.0端口。

NanoPi R5S拆解

一般想要拆开的原因主要有以下几个：：出于好奇、要安装M.2 NVMe SSD、要焊接SPI闪存、需要连接一些GPIO、RTC电池或者要将UART到TTL调试板。想要拆开很简单，松开四个需要松开的螺钉，就可以轻松拆开。

拆开之后可以看到带有M.2 Key M插槽的电路板底部、SPI闪存占用空间（右侧），以及三星KLM8G1GETF-B041 eMMC 5.1闪存8GB的主板。

NanoPi R5S板上的SPI闪存和M.2插座

要从外壳中取出电路板之前，还需要再拧松四个螺钉。

NanoPi R5S SBC

Rayson RS512M32LM4 D2BDS是一个2GB LPDDR4X内存芯片，我在其板子上找到了该产品宣传时提到的RTL8211F（GbE）和2x RTL8125BG（2.5GbE）以太网芯片，以及一个RK809 PMIC。我还在左侧找到了16针SDIO/I2C连接器和2针RTC电池连接器、在右上角找到了4针SWD和3针UART接头（注意，这些都是还未安装的）、在右下角找到GPIO连接器和风扇头。

金属外壳充当CPU散热器的NanoPi R5S

带有瑞芯微RK3568处理器的NanoPi R5S带有一个与金属外壳直接接触的散热垫，它可以帮助实现最佳冷却效果。

使用2.5GbE USB加密狗和UP Xtreme i11迷你PC进行测试设置

大家可能还记得不久前我在使用RTL8156B USB加密狗时遇到过一些性能问题，但现在这个问题已解决了。因为瑞昱科技（ Realtek）给我寄了另一个RTL8156BG，我之前在笔记本电脑上使用iperf3通过TP-Link 2.5GbE交换机从UP Xtreme i11迷你PC传输数据、并进行全双工测试时，它的测试结果是2.34Gbps/2.29Gbps。

我现在也用了相同的设置来进行测试，只不过这次中间的东西换成了NanoPi R5S。

NanoPi R5S

TP-Link交换机在这里的作用只是用来当作千兆以太网交换机，通过小米AX6000路由器将NanoPi R5S路由器的WAN端口连接到互联网，这样可以避免我必须要在设备上安装一些软件包。虽然将NanoPi R5S放在TP-Link开关的顶部能拍出更好的照片，但这两种设备都很热，我不建议这样做。因为我的以太网电缆很短，我就只好把路由器移到桌子上进行测试。

OpenWrt和iperf3基准测试

FriendlyWrt 是已经预装在路由器上的，因此开箱就能使用。也可以使用“root”作为用户和“password”作为密码立即访问LuCI界面或SSH。这确实是很方便，不过不太安全，而且在某些国家可能违反法律。不管怎么说吧，至少第一次使用时最好改一下密码。

FriendlyWrt的状态

FriendlyWrt是基于OpenWrt 22.03.0-rc1和Linux 5.10.66的内核。它在空闲且使用默认设置时使用的RAM不到250MB，由于系统配备的是2GB RAM，因此这些RAM足够使用了。

FriendlyWrt网络

我还没有连接SSD，所以只挂载了root分区，可用内存有6.7 GB，root分区用了920 KB。所有接口在启动时通过DHCP都能正确地获取到IP地址，局域网上的设备也可以通过<hostname>.lan访问，并获得一些IPv6地址。

从iperf3基准测试开始，我先在NanoPi R5S上运行“iperf3 -s”并在笔记本电脑上运行以下命令：

下载：（在NanoPiR5S上查看Rx测试的结果）

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 48782 connected to 192.168.2.1 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-10.00 sec 2.23 GBytes 1.92 Gbits/sec 0 1.69 MBytes
[ 5] 10.00-20.00 sec 2.02 GBytes 1.74 Gbits/sec 0 1.69 MBytes
[ 5] 20.00-30.00 sec 2.33 GBytes 2.00 Gbits/sec 0 2.64 MBytes
[ 5] 30.00-40.00 sec 1.66 GBytes 1.42 Gbits/sec 0 2.64 MBytes
[ 5] 40.00-50.00 sec 2.62 GBytes 2.25 Gbits/sec 0 2.64 MBytes
[ 5] 50.00-60.00 sec 2.01 GBytes 1.73 Gbits/sec 0 2.64 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-60.00 sec 12.9 GBytes 1.84 Gbits/sec 0 sender
[ 5] 0.00-60.05 sec 12.9 GBytes 1.84 Gbits/sec receiver
iperf Done.

上传（在NanoPiR5S上查看Tx测试的结果）：

$ 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 48786 connected to 192.168.2.1 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.00 sec 1.29 GBytes 1.11 Gbits/sec
[ 5] 10.00-20.00 sec 1.31 GBytes 1.12 Gbits/sec
[ 5] 20.00-30.00 sec 1.33 GBytes 1.14 Gbits/sec
[ 5] 30.00-40.00 sec 1.27 GBytes 1.09 Gbits/sec
[ 5] 40.00-50.00 sec 1.30 GBytes 1.12 Gbits/sec
[ 5] 50.00-60.00 sec 1.30 GBytes 1.12 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-60.06 sec 7.80 GBytes 1.12 Gbits/sec 0 sender
[ 5] 0.00-60.00 sec 7.80 GBytes 1.12 Gbits/sec receiver
iperf Done.

由上可知这并不完全是FriendlyElec宣传时的2.35 Gbps和1.85 Mbps，因为在此配置中我看到的是1.84 Gbps和1.12 Gbps。在查看10秒传输测试报告时，Rx方面也有一些变化。不过好在没有发现重传问题。

现在我们对NanoPi R5S上的另一个WAN端口进行相同的尝试，并从UP Xtreme i11运行命令：

下载（Rx）：

devkit@UPX-i11:~$ iperf3 -t 60 -c 192.168.2.1 -i 10
Connecting to host 192.168.2.1, port 5201
[ 5] local 192.168.2.207 port 52052 connected to 192.168.2.1 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-10.00 sec 2.59 GBytes 2.22 Gbits/sec 0 1.67 MBytes
[ 5] 10.00-20.00 sec 2.62 GBytes 2.25 Gbits/sec 0 1.93 MBytes
[ 5] 20.00-30.00 sec 2.60 GBytes 2.24 Gbits/sec 0 1.93 MBytes
[ 5] 30.00-40.00 sec 2.47 GBytes 2.12 Gbits/sec 0 1.93 MBytes
[ 5] 40.00-50.00 sec 2.43 GBytes 2.08 Gbits/sec 0 1.93 MBytes
[ 5] 50.00-60.00 sec 2.45 GBytes 2.10 Gbits/sec 0 4.90 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-60.00 sec 15.2 GBytes 2.17 Gbits/sec 0 sender
[ 5] 0.00-60.00 sec 15.1 GBytes 2.17 Gbits/sec receiver
iperf Done.

上传（Tx）；

devkit@UPX-i11:~$ 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.207 port 52056 connected to 192.168.2.1 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.00 sec 1.31 GBytes 1.13 Gbits/sec
[ 5] 10.00-20.00 sec 1.29 GBytes 1.11 Gbits/sec
[ 5] 20.00-30.00 sec 1.32 GBytes 1.14 Gbits/sec
[ 5] 30.00-40.00 sec 1.30 GBytes 1.11 Gbits/sec
[ 5] 40.00-50.00 sec 1.33 GBytes 1.14 Gbits/sec
[ 5] 50.00-60.00 sec 1.27 GBytes 1.09 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-60.00 sec 7.82 GBytes 1.12 Gbits/sec 0 sender
[ 5] 0.00-60.00 sec 7.82 GBytes 1.12 Gbits/sec receiver
iperf Done.

下载（Rx）时，在2.17 Gbps运行似乎要更好一些；但上传（Tx）时，在1.12 Gbps仍然运行得很慢。

我们一起来看看同时使用两个WAN端口时速度怎样？一个是在UP Xtreme i11上运行“iperf3 -s”，另一个端口则是在笔记本上运行如下命令：

jaufranc@cnx-laptop-4:~$ iperf3 -t 60 -c 192.168.2.207 -i 10

Connecting to host 192.168.2.207, port 5201

[ 5] local 192.168.2.130 port 49762 connected to 192.168.2.207 port 5201

[ ID] Interval Transfer Bitrate Retr Cwnd

[ 5] 0.00-10.00 sec 1.39 GBytes 1.19 Gbits/sec 0 3.15 MBytes

[ 5] 10.00-20.00 sec 1.42 GBytes 1.22 Gbits/sec 0 3.15 MBytes

[ 5] 20.00-30.00 sec 1.44 GBytes 1.24 Gbits/sec 0 3.15 MBytes

[ 5] 30.00-40.00 sec 1.42 GBytes 1.22 Gbits/sec 0 3.15 MBytes

[ 5] 40.00-50.00 sec 1.42 GBytes 1.22 Gbits/sec 0 3.15 MBytes

[ 5] 50.00-60.00 sec 1.39 GBytes 1.19 Gbits/sec 0 3.15 MBytes

- - - - - - - - - - - - - - - - - - - - - - - - -

[ ID] Interval Transfer Bitrate Retr

[ 5] 0.00-60.00 sec 8.49 GBytes 1.21 Gbits/sec 0 sender

[ 5] 0.00-60.05 sec 8.48 GBytes 1.21 Gbits/sec receiver

iperf Done.

这个数据应该是在预期范围之内的，因为我们之前获得上传（Tx）数据都比较较低；在1.21 Gbps时，它仍然比我们只使用上传（Tx）时的1.12 Gbps高了一点。

我们反过来再试一次：

$ iperf3 -t 60 -c 192.168.2.207 -i 10 -R
Connecting to host 192.168.2.207, port 5201
Reverse mode, remote host 192.168.2.207 is sending
[ 5] local 192.168.2.130 port 49766 connected to 192.168.2.207 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.00 sec 2.04 GBytes 1.75 Gbits/sec
[ 5] 10.00-20.00 sec 2.04 GBytes 1.75 Gbits/sec
[ 5] 20.00-30.00 sec 2.04 GBytes 1.75 Gbits/sec
[ 5] 30.00-40.00 sec 2.05 GBytes 1.76 Gbits/sec
[ 5] 40.00-50.00 sec 2.05 GBytes 1.76 Gbits/sec
[ 5] 50.00-60.00 sec 2.05 GBytes 1.76 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-60.05 sec 12.3 GBytes 1.75 Gbits/sec 0 sender
[ 5] 0.00-60.00 sec 12.3 GBytes 1.76 Gbits/sec receiver
iperf Done.

这次是1.75 Gbps，我不知道发生了什么，也不知道这是如何发生的。

接着我使用了全双工，再次进行了600秒的测试，并检查了LuCI中报告的CPU、内存和温度。

NanoPi R5S的CPU负载

由上可看到其CPU负载介于2.0和2.5之间。

NanoPi R5S的温度

CPU #0的利用率相对较低，CPU #1到#3占据了大部分资源。

在环境温度为28°C的房间中，其温度从未超过60°C。

FriendlyWrt内存使用率

不知道什么原因，1.8GB的可用内存使用量几乎没有改变。全双工测试期间的性能是：1.66 Gbps和736 Mbps。

这个结果有点令人失望，我现在打算切换到FriendlyCore (Ubuntu Core)，来检查一下会不会得到类似的结果，然后执行进一步的测试。如果你们想让我评测OpenWrt的其他内容，可以在评论区告诉我。

又进一步进行测试，切换到了基于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中，它看起来是这样的：

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文件确实不同：

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镜像时，得到的结果更糟糕：

$ 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的顺序写入速度。

Apacer M.2 2280 PCIe SSD

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

NanoPi R5S中的M.2 NVMe SSD安装

在NanoPi R5S上安装Ubuntu 20.04 FriendlyCore

我首先尝试使用eflasher镜像安装FriendlyCore。

使用eflasher镜像安装FriendlyCore

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

Eflasher安装FriendlyCore

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

Ubuntu 20.04 FriendlyElec登录

FriendlyCore系统信息

你们可以在CNX Software Pastebin上找到启动日志。我使用pi/pi凭据（用户名/密码）通过过了SSH登录，并将系统升级到了最新软件包：

1 2	sudo apt update sudo apt dist-upgrade

现在，我们运行一些命令来获取系统信息：

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找到更多细节：

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进行基准测试，希望尽可能可以发现一些问题：

$ 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的文件：

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的文件：

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的文件：

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的输出，仅供参考：

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接口配置和基准测试

NanoPi R5S路由器

由于开箱即用只配置了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

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

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文件：

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的角度接收：

$ 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监控系统：

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检查了一些信息和统计信息：

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。现在我们反过来测试一下：

$ 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）要得好得多了。

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：

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的传输速度，所以看起来还是有希望的！

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可以被充分利用来处理这些了。现在我们试试：

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更好。

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

CPU再次以全速运行了，而且距离100%的利用率差太多了，所以我觉得问题应该出在其他地方了。现在我们可以再次使用ethtool检查eth2信息和统计信息。

$ 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

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了：

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路由器路由。

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。

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处理的。

$ 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和以太网设置相关的各种设置”等等。其中的大部分目前我还不是很熟悉。

（三）、台电凌珑M NUC刷X86软路由评测

前言

很多朋友入手了X86软路由后大部分都闲置吃灰了，要么就是准备踏入X86软路由的坑中！首先要明确你是否愿意花时间去折腾，如果不愿意花时间研究我劝你放弃考虑入手X86软路由。可以考虑买成品的opnenwrt路由器来体验，也可以买个刷Merlin（梅林）固件的路由器或者刷过PandoraBox（潘多拉）固件的路由器玩玩。

准备相关的网络设备

一台合适的2.5G端口交换机和带2.5G电口的X86软路由刷机，一根2.5G网口的Type-C端或者USB-A端的外置有线网卡。

台电凌珑M NUC就是一款非常适合当X86软路由的迷你机，拥有两个2.5GE电口，具有两个SO-DIMM内存插槽和一个PCIe 3.0 NVMe SSD M.2插槽。建议选购裸机，自备内存条和NVMe SSD。这里准备了两根4GB美光DDR4 3200MHz内存条和1个Intel Optane M10 16GB（傲腾内存）。

装好内存和NVMe SSD后拿制作好的Router OS U盘装软路由的系统。

通电开机就可以拿去使用了。

兮克是新晋网络设备品牌，这是一款二层管理交换机，自带8个2.5G电口和4个万兆光口，支持端口聚合和VLAN划分。

朋友买了这款兮克的交换机让我帮升级一下家里的网络，打算整成全屋2.5G的内网环境。

开始调测设备，对于有经验的人来说还是很简单的。

可以看到兮克SKS7300-8GPY4XGS交换机的10G光口已经起来了，连接状态10G Full速率，对于手里有10G SFP模块的朋友来说那可以折腾万兆局域网了。不过现阶段还是2.5G局域网更适合大众实际体验需求。如果升级到万兆（10G）光口，那整体的硬件成本就会明显高出几倍。对于中小型企业，这款交换机很适合接入万兆核心交换机做接入交换机使用。还是更推荐对2.5G电口有需求的家庭用户和喜欢折腾2.5G局域网的朋友入手这款兮克交换机。

对手里有猫棒（GPON Stick ONU模块）的用户来说，直插在这款兮克SKS7300-8GPY4XGS交换机的SFP接口上可以省去一个光猫。有效解决了弱电箱里设备堆积不下的弊病，还能改善一下弱电箱内部的空间降低设备之间热量堆积的问题。

电脑（台式机和笔记本电脑）没有2.5G网口怎么办？可以买个优越者的USB转RJ45 2.5G有线网卡。通过Type-C端接入电脑，另一头的RJ45网口是2.5GbE（2500Mbps）速率。

拿U盘制作引导盘

我一般喜欢用BalenaEtcher这个工具来制作U盘，简单傻瓜式操作很Easy！支持ISO、DMG、IMG、IMG.GZ等多个镜像文件格式制作引导盘。

制作海蜘蛛V9引导盘（刷机）

去海蜘蛛官网，在服务与支持里找到下载专区。拉到最下面的升级地址里，找到V9.0，选择旁边的立即下载就可以下载海蜘蛛V9固件了，注意下载的是ISO镜像文件。

海蜘蛛V9系统

默认登录地址：192.168.0.1。账户和密码是刷机后自行设置。

可以在总览上查看当前的信息概况，仪表图示显示CPU使用率、内存使用率、磁盘使用率，下方是内网实时总流量的监控，右侧是一些关键信息。

已经在使用的LAN口，能够识别网口型号：Realtek RTL8125 2.5GbE，网口图示那也标识出了2.5Gb。

在总览里呢狗查看到当前的内存使用情况，刷机后初始化进入系统可以看到默认使用了10.5%，已使用835.86 MB存储空间。内存总大小：7.6GB（8GB总内存），剩余6.8GB可用。

在总览里也能够查看到CPU负载情况。

接口负载也能查看LAN口的数据，我这里LAN口是运行在全双工模式，2500Mb/s（也就是2.5GbE千兆口速率）。

在硬件信息里可以看到主板/CP信息，基本上显示出的相关信息都很齐全。

这里16GB的傲腾内存，可用容量：13.41GB，可以查看到硬盘存储的分区情况。

两个2.5GbE千兆网口都能正常的识别出来。

海蜘蛛有模块管理，其中就有Docker容器模块。

基本上这些模块对于软路由来说都算是很齐全了，VPN IPsec、PHP套件、IGMP组播代理等都一应俱全。

FTP服务。

文件存储共享。

点评：海蜘蛛V9需要买相关授权才能完整使用所有的功能，好在有一段较长的试用时间。相对很多功能都更偏向于网工使用，对于一般的小白用户来说操作难度可能会很高，一些专业术语也很绕口也难以理解。

制作iStore OS引导盘（刷机）

去KoolCenter官网下载iStore OS固件。在固件列表里找到iStore OS目录进去。

考虑到目前较新的X86软路由都是UEFI引导启动的，所以要选择x86_64_efi这个目录进去下载iStore OS固件。

一般最底下的列表里有Date（日期），选择最新的日期的这个iStore OS固件就可以了。

iStore OS（基于openwrt深度定制）

建议首次使用看一下固件使用注意事项，以便于了解登录IP（管理口地址）、登录密码。

其实iStore OS就是国人进行了易用性的深度定制，相对原版openwrt来说多了应用商店（插件）和Docker的玩法。

首页会有流量统计、IP地址、网络接口状态的图例，看上去一目了然。

往下拉可以看到磁盘信息、存储服务、Docker、下载服务和远程域名，可玩性还是非常高的。

拉到最底下可以看到系统信息，呢狗识别到CPU温度、CPU使用率、内存使用率。

网络向导，这个对小白用户来说是最佳设置连接方式的向导功能了。

概览里有系统信息，可以看到电脑型号、处理器架构等相关信息。

在概览里也能够看到内存的使用情况。

软路由一大比较难掌握用好的就是磁盘管理，这里iStore OS直接整了个图形化的DiskMan磁盘管理，降低了新手的操作难度，提升了使用上的简便性。

iStore OS内置Docker

对于很多想玩软路由的朋友来说Docker绝对是要去尝试的，但是很多openwrt并未内置Docker，需要手动安装插件就难倒了不少初学者或者刚入门的小白用户。而iStore OS直接就内置了Docker组件，便于进行容器化的部署。而且在高级设置中支持CPU和内存的配置设定，这就很人性化了。

iStore OS独有应用商店

对于想研究智能家居体验，可以考虑一下Home Assistant。

易有云适合微型的家庭部署数据服务中心，网上有很多的教程就不再深入探讨了。

如果买不起专用的NAS设备，其实软路由也能充当简易NAS，但是大部分X86软路由做NAS体验都不好用。这里iStore OS直接就有两个工具可以解决这个问题，对于想打造影音中心的朋友来说必装的两个插件：Jellyfin和Nas Tools。会用的话，那绝对是可以轻松将X86软路由打造成一个NAS。

Aria2下载器，会用的话也是很实用的下载工具。对于家里有两条宽带，为了避免上班期间或者出差期间宽带闲置不妨试一试部署网心云来赚点收益。

我其实更喜欢HomeBox内网测速，这个比自行搭建的SpeedTest测速服务器体验更佳。后面我会展示一下HomeBox内网测速的使用体验。

DiskMan磁盘管理绝对是值得安装的插件。而qBittorrent下载器会用的朋友都说好用，具体使用方法和教程网上有更多详细专业的介绍感兴趣就去找一下研究吧。

KMS服务器可以解决Windows、Office提示未激活的问题。

安装插件就跟安装app一样的简单方便，这也是iStore OS最大的易用性体现。

我最常用的就是这四个插件了，其中多线多播适合宽带叠加的地区，一句话300M叠加可以跑到600M，500M叠加可以跑1000M但是又不需要升级宽带套餐和额外多掏钱想想就很值得。

KMS服务器启用，基本上本地的Windows和Office就没再遇到过未授权的情况了。

这个就是HomeBox内网测速，可以直接测出内网的速率。我是用台电凌珑M NUC的2.5GbE千兆网口、CAT6（超六类）网线、Type-C转RJ45的2.5GbE外置有线网卡，可以实现2500Mbps全链路的局域网（内网）体验。

总结

对于具备网工基础或者对网络比较了解的用户可以考虑入手X86软路由。海蜘蛛V9其实更偏向于传统的网络设备，糅合交换机、路由器、AC控制器等功能。iStore OS就适合普通大众了，可玩性更高，上手难度也较为简单。我个人更推荐刷iStore OS固件来使用，基本上就是openwrt里个人用过体验不错的Router OS了。

数码分类资讯推荐