After being stuck at home for over two months, I finally found the motivation to organize my network devices. Previously, my soft router was running on a Proxmox virtual machine, but since routers are crucial devices that affect everything, I thought it would be better to use a dedicated device. Recently, I saw news about the NanoPi R2S being available for sale, along with various reviews from different content creators, which made me eager to get one.The NanoPi R2S is a small development board launched by FriendlyARM, equipped with an RK3328 CPU, a 4-core A53 ARMv8 64-bit processor clocked at 1.5GHz, although the official frequency is locked at 1.2GHz. It has two Gigabit Ethernet ports, one of which is connected via USB3.0. The firmware is booted from an SD card. At around 200 RMB, isn’t that a great deal?With dual Gigabit Ethernet ports and the modified OpenWrt – FriendlyWrt from FriendlyARM, along with its compact size, the R2S has the potential to be the main router for home use.Since many reviewers mentioned that the R2S’s original plastic case has thermal issues, I directly purchased the version with an aluminum case from Taobao, and testing showed that heat dissipation was no longer a problem.The aluminum case is larger in width, length, and height than the plastic case, encapsulating all the R2S’s ports, which makes it slightly difficult to insert and remove the SD card.As FriendlyARM is a domestic company, FriendlyWrt lacks some essential components for soft routers. Fortunately, FriendlyWrt is open-source, and FriendlyARM has published the method to compile FriendlyWrt for the R2S. So now everyone basically uses firmware compiled by various enthusiasts.The compilation method for FriendlyWrt is actually quite simple. In general, it involves installing compilation dependencies, installing FriendlyARM’s version management tool repo, downloading the source code, running the compilation script, and then waiting for a few hours.
However, each enthusiast has their own preferences, and everyone makes some modifications they think are beneficial. Some prefer stability, while others prefer speed, so various firmware versions are being tested. The firmware compiled by these two masters on GitHub, klever1988 and soffchen, are both quite popular. Besides those on GitHub, there are also various channels for distributing non-open-source firmware.For me, Clash is a must-have, but various Clash plugins tend to route all traffic through Clash, which results in unnecessary performance losses, especially impacting the performance of the ARM CPU. Therefore, I modified someone else’s plugin to ensure that only part of the traffic goes through Clash, thus embarking on the path of compiling my own firmware.Referring to the GitHub projects of the two masters mentioned above, I compiled three types of firmware for the NanoPi R2S. One of them is based on FriendlyWrt with the packages I need added, while the other two are based on different branches of Lean OpenWrt. The firmware based on FriendlyWrt has the CPU frequency limited to 1.2GHz, while the other two firmware versions have the CPU frequency unlocked to 1.5GHz.For the main router device in my home, I still prefer stability. After testing all three firmware versions, I chose the version based on FriendlyWrt, and the following tests are all conducted using the FriendlyWrt firmware.When the WAN port protocol is set to DHCP client, the NAT performance can stably reach over 900 Mbps, with CPU usage between 20% and 30%. The temperature is around 55 degrees.
When the WAN port protocol is set to PPPOE, due to the inherent performance consumption of PPPOE, the NAT performance decreases to between 700 and 800 Mbps, with CPU usage increasing by about 20%, and the temperature rising by a degree or two.
For the main home router, the test results for PPPOE dialing should be considered. I don’t use optical modem dialing or bypass routing. Public IP and single NAT are essential since an additional layer of NAT introduces more loss and inconvenience.From the test results, the R2S is definitely sufficient for a 500M home broadband. If you have a gigabit broadband connection at home, it would be better to invest in an x86 soft router.Additionally, when the CPU is unlocked to 1.5GHz, the temperature during NAT testing can reach over 60 degrees.Let’s check the speed on YouTube.
This speed is sufficient for watching YouTube in 4K. Since streaming does not require continuous high-speed access, during YouTube viewing, the CPU usage is mostly in single digits, with only occasional peaks.Finally, let’s take another look at the speed on fast.com while testing in WAN port DHCP mode.
Below are the CPU usage and temperature during fast.com speed tests.
The temperature is definitely not an issue. However, the CPU usage is somewhat concerning. Let’s also take a look at the CPU usage when performing NAT performance tests with iperf3 while running fast.com speed tests. The speed test results from fast.com remain unchanged, so I won’t include a picture here. Below is the CPU usage.
At this point, CPU usage is at 70%, and if we consider the additional 20% overhead introduced by PPPOE, the R2S’s CPU is at its limit.If the broadband output exceeds 500M and requires PPPOE, the R2S may need to unlock the CPU frequency or use a Flow Offload patch.Unlocking the CPU frequency can provide an additional 25% CPU performance, but the temperature may increase by around 10 degrees.I have also tested Flow Offload (which is supported by the other two firmware versions I compiled apart from FriendlyWrt). When performing full-speed NAT with DHCP, it can reduce CPU usage by about ten percent, but unfortunately, Flow Offload is still not very stable on the R2S.Currently, I am only using the R2S for single-machine testing. Once I officially use it as the main router, if I find the performance insufficient, I will prioritize unlocking the CPU frequency limit. After all, an increase of 10 degrees from the current 40 to 50 degrees is still acceptable.
