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.
- 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).
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… Read more »
> 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… Read more »
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… Read more »
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… Read more »
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.… Read more »
: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.… Read more »
>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… Read more »
> 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… Read more »
>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… Read more »
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… Read more »
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… Read more »
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.