NanoPi R4S-RK3399 is a great new OpenWrt device

Thanks! Yes I meant not in the test kernel because I don’t want to make a build myself every time there’s a new one, I don’t have hurry, I’m just curious! What are the benefits for the R4S with the 5.15 instead of 5.10?

We’ll it is the new features/enhancements coming with 5.15 plus some R4S patches got upstreamed (= directly implemented in the kernel), thus one could drop some patches. Generally I’d say R4S support improved, although for the general case I would doubt you feel any material difference.

1 Like

Hello,

I have been following this post on the forum and I have seen that you have great knowledge in R4S, I would like to ask you for some help.

My R4S with "OpenWrt 21.02.1 r16325-88151b8303" has very high latency compared to other devices. Even performing a ping to localhost the latency is between 0.200 ms and 0.400 ms. Testing on other devices is around 0.050 ms, which I find strange because the R4S is a powerful device.

When I perform a ping to the next hop after the WAN or LAN, the ping is above 1 ms, I believe this should be smaller too, since the network is wired.

Is there a solution to this problem I'm having?

I really appreciate your help.

Thanks.

Hi!

Unfortunately I'm not the expert you believe I am :frowning:

I only setup OpenWrt this month, with the help of this forum. Would not be possible.

Having said that, I can try to do some ping tests myself

I am currently using the dual gigabit RPi Computer Module 4

When I get some spare time I will swap it for the R4S and test

Here you go:

root@OpenWrt:~# ping 10.10.100.10
PING 10.10.100.10 (10.10.100.10): 56 data bytes
64 bytes from 10.10.100.10: seq=0 ttl=64 time=0.716 ms
64 bytes from 10.10.100.10: seq=1 ttl=64 time=0.770 ms
64 bytes from 10.10.100.10: seq=2 ttl=64 time=0.790 ms
64 bytes from 10.10.100.10: seq=3 ttl=64 time=0.797 ms
^C
--- 10.10.100.10 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0.716/0.768/0.797 ms
root@OpenWrt:~# ping localhost
PING localhost (::1): 56 data bytes
64 bytes from ::1: seq=0 ttl=64 time=0.423 ms
64 bytes from ::1: seq=1 ttl=64 time=0.325 ms
64 bytes from ::1: seq=2 ttl=64 time=0.333 ms
64 bytes from ::1: seq=3 ttl=64 time=0.370 ms
64 bytes from ::1: seq=4 ttl=64 time=0.369 ms
64 bytes from ::1: seq=5 ttl=64 time=0.370 ms
^C
--- localhost ping statistics ---
6 packets transmitted, 6 packets received, 0% packet loss
round-trip min/avg/max = 0.325/0.365/0.423 ms

Those are the sort of very high ping times that result from the default scheduil scheduler. Suggest moving to performance as indicated in this thread:

1 Like

I see that one of the methods resulted in reboots of the R4S.
At least, that's how I read it.

For one user running FriendlyWRT, yes. I've had no such issues. If you try it and find the same, a) that would be a very useful data point and b) it is trivial to reverse.

This is not the R4S, it's OpenWrt, when I ping from one RaspberryPI to another I have about 0.2ms, when i ping from RaspberryPI to the R7800 or R4S, latency is about 0.4/0.5ms

192.168.1.2 = R4S
192.168.1.3 = R7800
192.168.1.5 & 6 = other RPis inside the LAN

root@Pi-Hole:~# ping 192.168.1.2
PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.
64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=0.560 ms
64 bytes from 192.168.1.2: icmp_seq=2 ttl=64 time=0.471 ms
64 bytes from 192.168.1.2: icmp_seq=3 ttl=64 time=0.531 ms
64 bytes from 192.168.1.2: icmp_seq=4 ttl=64 time=0.222 ms
64 bytes from 192.168.1.2: icmp_seq=5 ttl=64 time=0.476 ms
64 bytes from 192.168.1.2: icmp_seq=6 ttl=64 time=0.483 ms
64 bytes from 192.168.1.2: icmp_seq=7 ttl=64 time=0.479 ms
64 bytes from 192.168.1.2: icmp_seq=8 ttl=64 time=0.528 ms
64 bytes from 192.168.1.2: icmp_seq=9 ttl=64 time=0.514 ms
64 bytes from 192.168.1.2: icmp_seq=10 ttl=64 time=0.473 ms
64 bytes from 192.168.1.2: icmp_seq=11 ttl=64 time=0.475 ms
64 bytes from 192.168.1.2: icmp_seq=12 ttl=64 time=0.467 ms
64 bytes from 192.168.1.2: icmp_seq=13 ttl=64 time=0.505 ms
64 bytes from 192.168.1.2: icmp_seq=14 ttl=64 time=0.512 ms
64 bytes from 192.168.1.2: icmp_seq=15 ttl=64 time=0.491 ms
64 bytes from 192.168.1.2: icmp_seq=16 ttl=64 time=0.459 ms
64 bytes from 192.168.1.2: icmp_seq=17 ttl=64 time=0.470 ms
64 bytes from 192.168.1.2: icmp_seq=18 ttl=64 time=0.463 ms
64 bytes from 192.168.1.2: icmp_seq=19 ttl=64 time=0.513 ms
64 bytes from 192.168.1.2: icmp_seq=20 ttl=64 time=0.533 ms
64 bytes from 192.168.1.2: icmp_seq=21 ttl=64 time=0.480 ms
^C
--- 192.168.1.2 ping statistics ---
21 packets transmitted, 21 received, 0% packet loss, time 20466ms
rtt min/avg/max/mdev = 0.222/0.481/0.560/0.063 ms
root@Pi-Hole:~# ping 192.168.1.3
PING 192.168.1.3 (192.168.1.3) 56(84) bytes of data.
64 bytes from 192.168.1.3: icmp_seq=1 ttl=64 time=0.510 ms
64 bytes from 192.168.1.3: icmp_seq=2 ttl=64 time=0.448 ms
64 bytes from 192.168.1.3: icmp_seq=3 ttl=64 time=0.405 ms
64 bytes from 192.168.1.3: icmp_seq=4 ttl=64 time=0.467 ms
64 bytes from 192.168.1.3: icmp_seq=5 ttl=64 time=0.477 ms
64 bytes from 192.168.1.3: icmp_seq=6 ttl=64 time=0.434 ms
64 bytes from 192.168.1.3: icmp_seq=7 ttl=64 time=0.403 ms
64 bytes from 192.168.1.3: icmp_seq=8 ttl=64 time=0.411 ms
64 bytes from 192.168.1.3: icmp_seq=9 ttl=64 time=0.420 ms
64 bytes from 192.168.1.3: icmp_seq=10 ttl=64 time=0.426 ms
64 bytes from 192.168.1.3: icmp_seq=11 ttl=64 time=0.455 ms
64 bytes from 192.168.1.3: icmp_seq=12 ttl=64 time=0.434 ms
64 bytes from 192.168.1.3: icmp_seq=13 ttl=64 time=0.448 ms
^C
--- 192.168.1.3 ping statistics ---
13 packets transmitted, 13 received, 0% packet loss, time 12291ms
rtt min/avg/max/mdev = 0.403/0.441/0.510/0.029 ms
root@Pi-Hole:~# ping 192.168.1.5
PING 192.168.1.5 (192.168.1.5) 56(84) bytes of data.
64 bytes from 192.168.1.5: icmp_seq=1 ttl=64 time=0.220 ms
64 bytes from 192.168.1.5: icmp_seq=2 ttl=64 time=0.220 ms
64 bytes from 192.168.1.5: icmp_seq=3 ttl=64 time=0.268 ms
64 bytes from 192.168.1.5: icmp_seq=4 ttl=64 time=0.212 ms
64 bytes from 192.168.1.5: icmp_seq=5 ttl=64 time=0.258 ms
64 bytes from 192.168.1.5: icmp_seq=6 ttl=64 time=0.206 ms
64 bytes from 192.168.1.5: icmp_seq=7 ttl=64 time=0.240 ms
64 bytes from 192.168.1.5: icmp_seq=8 ttl=64 time=0.252 ms
64 bytes from 192.168.1.5: icmp_seq=9 ttl=64 time=0.220 ms
64 bytes from 192.168.1.5: icmp_seq=10 ttl=64 time=0.256 ms
64 bytes from 192.168.1.5: icmp_seq=11 ttl=64 time=0.281 ms
64 bytes from 192.168.1.5: icmp_seq=12 ttl=64 time=0.235 ms
64 bytes from 192.168.1.5: icmp_seq=13 ttl=64 time=0.234 ms
^C
--- 192.168.1.5 ping statistics ---
13 packets transmitted, 13 received, 0% packet loss, time 12279ms
rtt min/avg/max/mdev = 0.206/0.238/0.281/0.022 ms
root@Pi-Hole:~# ping 192.168.1.6
PING 192.168.1.6 (192.168.1.6) 56(84) bytes of data.
64 bytes from 192.168.1.6: icmp_seq=1 ttl=64 time=0.249 ms
64 bytes from 192.168.1.6: icmp_seq=2 ttl=64 time=0.331 ms
64 bytes from 192.168.1.6: icmp_seq=3 ttl=64 time=0.236 ms
64 bytes from 192.168.1.6: icmp_seq=4 ttl=64 time=0.259 ms
64 bytes from 192.168.1.6: icmp_seq=5 ttl=64 time=0.242 ms
64 bytes from 192.168.1.6: icmp_seq=6 ttl=64 time=0.244 ms
64 bytes from 192.168.1.6: icmp_seq=7 ttl=64 time=0.338 ms
64 bytes from 192.168.1.6: icmp_seq=8 ttl=64 time=0.230 ms
64 bytes from 192.168.1.6: icmp_seq=9 ttl=64 time=0.238 ms
64 bytes from 192.168.1.6: icmp_seq=10 ttl=64 time=0.248 ms
^C
--- 192.168.1.6 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9198ms
rtt min/avg/max/mdev = 0.230/0.261/0.338/0.037 ms
root@Pi-Hole:~# 

Which would be?

Just remove the lines you added to /etc/rc.local and reboot again.

Or, if you don't want it to be permanent at all, just ssh in and execute the three lines by hand. It'll stick until the next reboot (intentional or otherwise).

1 Like

I'm running OpenWRT snapshots in a nanopi r4s 4GB, but this week in the recents snapshots, when I reboot the nanopi sometimes the lan port is not recognized, maybe the issue was always present, but this week is more frequent, in the update log from:

https://wiki.friendlyelec.com/wiki/index.php/NanoPi_R4S

says:

14.1 2022-08-03

14.1.1 FriendlyWrt:

Fixed the problem that the R4S/R4SE may not recognize the pcie device (lan port) after a soft reboot (small probability)

but I tried to look in the commits from:

but since june 2022 to today didnt find any commit fixing the above issue, and google didnt turn any useful posts about the patch

so please someone has any pointers about where I can find the commit fixing the above issue?

thanks

Which snapshot are you running? I did not experience something like this, but did not update in the last ~2 weeks.

Hi,

from yesterday:

OpenWrt SNAPSHOT, r20451-6c302b9009

last commit in openwrt git:

commit 6c302b900979c3bad2a7764f72f23ccc2d2a33a4 (HEAD -> master, origin/master, origin/HEAD)
Author: 
Date:   Thu Sep 1 21:40:44 2022 +0100

    kernel: fix DSA mac_select_pcs backport


I using the nanopi r4s since June 2022, always compiling my own image, once every two weeks or more frequently if the commits show something interesting as new kernel version, from snapshots,

and I'm using the test kernel 5.15,

and always wrote the image from the nanopi, and sometimes failed to boot from the new image, but in this week wrote two images, different snapshots, from the nanopi and the two failed to boot, but I was able to ssh and the lan port didn't come online, so I have to reboot the nanopi many times until the eth1 comes online.

so I found that the issue was resolved, but I'm unable to find the commit to test

did you merge this pull request in your own build?

without this PR I have boot issues too

Thanks, I applied the PR to my git tree, but the new build have the same issue, sometimes the eth1 was not present at boot time.

I have an R4SE and it works fine with vanilla OpenWRT. I did have to zero the loader on the eMMC, as described in the R4SE documentation, before it would boot the SD card though:

https://wiki.friendlyelec.com/wiki/index.php/NanoPi_R4SE#The_Boot_order_between_eMMC_and_SD_card

I haven't tried to boot OpenWRT proper from the eMMC. It may or may not work.

3 Likes

This is good to know as I just ordered an R4SE and expect it in hand tomorrow. When you say "vanilla OpenWRT" are you specifically referring to a vanilla snapshot build?

I used this image, though I imagine the snapshots should work as well: https://downloads.openwrt.org/releases/22.03.0-rc6/targets/rockchip/armv8/openwrt-22.03.0-rc6-rockchip-armv8-friendlyarm_nanopi-r4s-squashfs-sysupgrade.img.gz

Something is amiss, however, as I just noticed the iperf speeds are in the 300-500 Mbps range, not the 900+ Mbps advertised.

1 Like

Are you seeing CPU contention? Do you use irqbalance?