FriendlyElec launched NanoPi R1S router with two Ethernet ports based on either Allwinner H3 or H5 processor coupled with 512MB RAM last November. Both ports are “Gigabit” Ethernet port, but one is implemented via a USB 2.0 to Ethernet controller with a maximum bandwidth of around 330 Mbps.
If you’d like to get two Gigabit Ethernet reaching close to 1 Gbps each, and your target application would benefit from a bit more memory, the company is now working on NanoPi R2S based on Rockchip RK3328 processor with 1GB DDR4 memory, one Ethernet port using the GMAC from the chip, and one Ethernet port relying one a USB 3.0 to Ethernet controller.
The rest of NanoPi R2S specifications are pretty similar to the earlier board except WiFi is also gone:
- SoC – Rockchip RK3328 quad-core Cortex-A53 @ 1.5 GHz with Arm Mali-450MP2
- System Memory – 1GB DDR4 RAM
- Storage – MicroSD Slot, SPI flash footprint
- Connectivity
- 1x Gigabit Ethernet (WAN) up to 941 Mbps (measured)
- 1x Gigabit Ethernet (LAN) up to 941 Mbps (measured) via Realtek RTL8153 USB 3.0 to Ethernet controller
802.11b/g/n WiFi 4 with IPX-I antenna connector
- USB – 1x USB Type-A host port, 1x micro USB port (power + slave)
- Debugging – 3-pin 2.54mm pitch header for serial console
- Expansion – 10-pin GPIO header with GPIOs, I2C, UART, IR_Rx, 5V, 3.3V and GND
- Misc – 3x LEDs (WAN, LAN, SYS), K1 reset button, fan header
- Power Supply – 5VDC/3A via micro USB port
- Dimensions – 55.6 x 52mm
- Temperature Range – -20 to 70
Another addition is the presence of a 10-pin I/O which was completely lacking from NanoPi R1S router board. Since WiFi is missing, the company recommends USB dongles based on RTL8821CU since those are supported by the default firmware out of the box. The board also supports 4G LTE via Huawei 8372H-155 USB dongle.
The company will provide both FriendlyWrt, based on OpenWrt, and FriendlyCore, based on Ubuntu 18.04 Core, for the board. More details can be found in the Wiki (Chinese version only for now).
NanoPi R2S will be compatible with the same yellow case used for NanoPi R1S. The board is not available yet, and since Chinese New Year 2020 is right around the corner, I would only expect a launch after the celebrations at the beginning of February at the earliest.
That also means pricing is not available, but considering NanoPi R1S sells for $19.99 (H3) / $22.99 (H5) with the enclosure, I’d expect NanoPi R2S to sell for a few dollars more, maybe $26.99?, due to the extra memory and USB 3.0 to Ethernet controller.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
Interesting. I would have preferred to see a dual-port GigE switch like https://www.microchip.com/wwwproducts/en/KSZ9893 instead of one port over USB and another one over Ethernet. But at least it’s a great improvement. Regarding the price, I guess I’d be OK with spending up to ~$30 for such a dual-port board. Maybe it would be the opportunity for us at work to start to work on a new version of our Aloha Pocket and move away from the GL-iNet which is quite limited.
I have been looking quite actively for a small cheap dual GbE SBC. So far, it has been a case of “pick 2”, although the R1S was pretty close. A bit disappointing that the WiFi interface has to fall away in the process, though, although the USB2.0 port allows for adding an external interface as needed.
I agree that using a switch chip would make it more flexible, although I suppose it would also limit the absolute forwarding throughput to 500Mbps? Having the USB3 port available for other uses would be nice, though. And of course, that switch chip itself is fairly expensive, driving up the overall cost.
> I suppose it would also limit the absolute forwarding throughput to 500Mbps
No that would still be 1Gbps, it doesn’t change anything, that’s the bandwidth supported by the SoC interface used to connect to the switch’s port (some can actually even reach 2.5G).
Regarding the switch’s cost, a 2-port switch is around $4, and you remove $2.5 for the USB-to-ethernet interface, and $1.0 for the RTL8211E. In the worst case adding 50 cents to the whole device price remains pretty reasonable given that it enters the very small team of multi-gig boards, which are all significantly more expensive. There could however be some technical limitations that I’m not aware of, including the chip’s footprint not being suitable for the board. But if I had to choose between one USB+ETH board and another one with 2 real ethernets for $4 extra, I’d clearly pick the latter.
But don’t get me wrong, I already find this one quite interesting and it’s a real progress compared to previous ones. I guess there is significant demand if they released 3 such dual-port boards in that short a time frame.
I can’t say that I totally understand your reasoning for saying that the total bandwidth would still be 1Gbps. According to https://en.wikipedia.org/wiki/Media-independent_interface#High_serial_gigabit_media_independent_interface, the key feature of HSGMII is the 2.5Gbps capacity, implying that RGMII is only capable of 1Gbps throughput.
In which case, the CPU would be able to send and receive a total of 1Gbps traffic from the switch, suggesting that if it is acting in a forwarding role, that it would have to send the same amount of data out of the outbound port as it receives on the inbound. And so the maximum traffic rate it could achieve from one port to the other, IF the cpu is acting as a router, and not simply delegating the packet routing to the switch fabric must be half of the RGMII port rate.
Ah now I think I understand your reasoning, you probably missed the most important part which is that GigE (and hence RGMII) is full duplex 🙂 So you both receive AND transmit 1 Gbps at the same time. This is why you do really forward 1 Gbps on one port.
Sure, but that doesn’t change the equation. You have 2 duplex 1 Gbps interfaces, i.e. 2 Gbps duplex total, trying to squeeze into a 1 Gbps duplex RGMII channel. It’s just not possible.
While it IS possible to pass 1 Gbps inbound on one interface to the CPU via RGMII, and route those packets outbound from the CPU via RGMII onto the other interface due to the duplex capability, as soon as interface 2 starts responding to those packets, there will become a bottleneck, and the throughput from interface 1 will have to drop to allow those response packets to pass.
Hence my assertion that there is a 500Mbps limit on symmetric data exchange. (And yes, I am aware that this is the first time I have mentioned “symmetric”, and this is probably the core of the misunderstanding.)
No, it has nothing to do with 500 Mbps. If you want to forward 1 Gbps, it will exactly pass through thanks to the full duplex: one port gets 1 Gbps inbound traffic, which leaves the RGMII port, enters the SoC, is processed, and is routed back to the RGMII port, and directed to the second port. You have 1 Gbps in each direction on the RGMII, so you an effectively forward 1 Gbps of traffic between two ports, and there is no such artificial 500 Mbps. Said differently, this supposed 500 Mbps bit rate exists nowhere in the chain.
And please don’t fall into the marketing trap consisting in counting full duplex as 2 Gbps. That’s wrong, it’s 1 Gbps in both directions at once.
The difference between the switch and the ethernet+USB solution is that with ethernet+USB you may reach higher cumulated speeds (2 Gbps full duplex, i.e. 1 Gbps per port). But given the asymmetry of the edge traffic at most places (typically 95/5 or 90/10), this brings almost no value. For example with a switched port your 1 Gbps forwarding rate could be made of 950 Mbps in and 50 Mbps out, while with 2 ports it could be made of 1000 Mbps in and 50 Mbps out.
:facepalm: Yeah, I see what you mean. I will get there eventually. Thanks for being patient with me.
I beg to differ regarding the use of a switch chip:
A switch, even with VLAN support, *may* connect the WAN & LAN ports into the same network at a given moment (during initial boot sequence, for example, when switch and VLANs are not initialized/configured yet).
Having two distinct network interfaces is an absolute requirement for a router. And, I do agree with you, this is actually a nice board / device for such usage (particularly if the price can actually be around $30 or euros).
The power-on behavior is often configurable on many switch chips. Some require an external EEPROM, some just use some pull-ups. I remember reading a datasheet a long time ago where there was a special mode where each port was put in a distinct VLAN (same ID as the port number). I don’t know if the device I linked to above supports such power-on choices, but that’s definitely something that needs to be validated. Another approach may consist in changing the default port interface mode so that the link cannot automatically go up until the chip is configured by the OS. But it’s a bit dirty 🙂
>A switch, even with VLAN support, *may* connect the WAN & LAN ports into the same network at a given moment
The espressobin did just that for me and it caused a ton of issues. I changed over to the odroid h2 because it has two actual interfaces.
Yes, the Espressobin was a notorious offender. However, if you install the latest UBoot firmware, it configures the switch in a non-forwarding mode, avoiding this problem until the OS takes over.
> instead of one port over USB
We should keep in mind that the used RTL8153 is a really solid choice. Even the ‘experts’ over at RPi Trading Ltd. had to admit that when being confronted with the crappy behavior of their crippled GbE USB choice on the RPi 3B+: https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=208512&start=100#p1297857
I do not contest this at all. It’s just that when you build a router based on totally different driver stacks depending on the port you use, you observe awkward things that start to make you think what should be put on what port. There’s not just the bandwidth, but the latency, losses, the driver itself, the offloading capabilities, the bugs that can differ between them, etc. It increases the amount of head scratching when observing strange phenomenons.
With all that said, we’re still talking about a $30 or so consumer device, which is why I’m still totally positive on this choice, especially not knowing the other constraints that could be faced when trying to integrate an RGMII switch instead. I guess it’s probably close to the best that can be done with such a BOM and this SoC.
> https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=208512&start=100#p1297857
BTW I remember this thread now, it was totally hilarious. “Experts” using Samba to measure network losses, and having no idea why some boards were randomly freezing during speed tests after the users had tuned their TCP stack to use 32GB of RAM 🙂 There was absolutely zero trustable information in all that thread, by total lack of methodology and an extreme dose of amateurism from all parties involved. The deepest analysis was “it now seems to work better for me with RTL8153 but still no idea why”. I’d say that I won’t use that thread as a voucher for how good the RTL8153 is. Fortunately I’ve read good things about it in the past from other more reputable places!
>extreme dose of amateurism
They should put a warning with that in at the top of each thread over there.
What share of consumer behaviour do they represent?
Guess could be around 10% of people able doing even os adjustments or individual hardware&software interaction?
90% switch-on devices and want them functional (enough for >100Mbit/s and mostly <1-2.5Gbit/s)?
There's less lack of cheap devices, but long term usable hardware, with nowadays SoC performance capabilities?
It’s not just a matter of bitrate but reliability in every day use. Those connecting their RPis to 100 Mbps switches can experience higher performance and stability than those connecting them to gigabit switches just due to reduced losses, hence less retransmissions. Their USB chip has so small buffers that it simply cannot buffer the incoming data for the time it takes the OS to retrieve them, resulting in important losses if they don’t enable flow control (hence why Jamesh asks each and every problem reporter to try to enable flow control on their switches). But that’s too much to ask to home users mostly relying on non-manageable switches.
And the problem with retransmissions is that they can add extreme latency sometimes (typically 200ms to 3s if it’s the last segment of a series). For example, typing “ls -l” over SSH in a large directory may possibly result in occasional multi-second freezes for some users, that will not happen at 100 Mbps. This is why it’s always important to be extremely careful about the chip’s quality when using an ethernet controller working over a high-latency bus (USB being such one when the device doesn’t support DMA and depend on software execution to move the data from the chip to memory). The chip must have a lot of memory. Otherwise the OS must be configured to stick to very small Rx windows to never fill the switch’s buffers with a single stream (even though it’s not always necessarily sufficient when having multiple streams).
I would have preferred to see a USB-C power.
Too bad there isn’t an usb3 port available as well.
Yeah the “1x USB 3.0 Gigabit Ethernet (LAN) up to 941 Mbps (measured) via Realtek RTL8153” is pretty confusing.
Why/how? The single SuperSpeed port of the SoC is directly connected to the RTL8153b on the PCB. So no more SuperSpeed ports available…
Why not adding a hub?
or a 3-1 switch to the MAC
Also not sure why the CPU is on top on this board. While cooling is rarely an issue on a router, it’s still more complicated this way than at the bottom like they do on other nanopis.
They have a rather large heatsink as accessory for these router thingies:
http://wiki.friendlyarm.com/wiki/images/8/8a/PSU-ONECOM-R1S.jpg
Yes, it should be way enough for any workload I guess.
With RK3328 you really don’t need much wrt cooling. I’ve set up recently a new backup server using a Libre Computer Renegade (pretty much the same as Rock64 rev3) and this thing just equipped with a small passive heatsink will never throttle (overall consumption when backing up 2 Macs simultaneously: slightly above 3W — but the backup media is a SanDisk Extreme Pro A2 400GB 😉 )
Just started an sbc-bench run and even at 1.5GHz the RK3328 stays below 80°C when running cpuminer for 5 minutes: http://ix.io/27Dq (though there’s something seriously wrong with memory performance, both bandwidth and latency suck compared to previous RK3328 numbers).
This also matches my observation on the same board, which is pretty nice by the way, hence my comment above 🙂
Finally FriendlyArm will build what I requested years ago. Nice step in the right direction!
Currently using an Atomic Pi + USB 3.0 RTL8153 adapter (~$30 USD) on OpenWrt and it runs line rate 1000 Mbps with QoS @ 25% peak load. With 2GB RAM and built-in 16GB eMMC I’m pretty satisfied with it.
The NanoPi R2S is more compact and integrated, if they can bring down the price point a bit – it will be a huge success vs the similar pfsense appliance that retails around $99
Hi Jean-Luc – this is great “the company recommends USB dongles based on RTL8821CU since those are supported by the default firmware out of the box. The board also supports 4G LTE via Huawei 8372H-155 USB dongle.” but up to now I’ve been unable to get a straight answer from FriendlyArm as to how to support a WiFi USB dongle with FriendlyWrt “out of the box”. I’ve installed FriendlyWrt, I’ve added a WiFi dongle (one of the very commonly available ones which simply state “802.11n” on the side of the USB WiFi dongle) – and there is no sign in the setup for FriendlyWrt as to how to enable the WiFi or select an SSID or password – unless I’m missing something. Any thoughts?
What does the kernel log show when you insert the dongle? You can check with dmesg
dmesg output and the discussion continues @ https://www.cnx-software.com/2020/03/25/buy-nanopi-r2s-dual-gbe-iot-board-and-gateway/#comment-571464
Lauched and now on sale @ $22.00. Note Coronavirus shipping advice.