三款軟路由評測

（一）、電犀牛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”，另一個端口則是在筆記本上運行如下命令：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

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中，它看起來是這樣的：

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

$ 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

現在，我們運行一些命令來獲取系統信息：

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接口配置和基準測試

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

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和以太網設置相關的各種設置”等等。其中的大部分目前我還不是很熟悉。

（三）、台電凌瓏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了。