NanoPi R4S-RK3399 is a great new OpenWrt device

Agreed. The R6S is way to expensive and the R4S is fast but getting old.
The R5S would have been sweet if it had the processors from the R4S.

Just to report that I had to do the same to upgrade from .4 to .5 yesterday! I have no idea of why... I suspect is something related to the custom size of the root image (from 100Mb to 30Gb).

If someone have an idea it would be great, reset all and re-write the minisd every time I need to upgrade is a bit annoying.

I really don't consider the R6S expensive given its capability. Issue is really that it's not officially supported by OpenWrt that's the red flag for me. I've heard there is some upstream issues with support, hopefully it happens. The R4S remains a great option though.

FriendlyWRT is not bad, and you could always fork it and customize it.

There have been some security issues mentioned concerning FriendlyWrt that may or may not matter to you.

Aside from the R6S the R6C is the budget version and the newly NanoPc T6 look very interesting too. OpenWrt can run on these devices if you fork @mj82 repo NanoPi R6S & Linux 6.3 ARM SoC Updates - #15 by mj82 or grab the the patches and apply them on the top, I did a build for my R6C last night and everything is working.

1 Like

FriendlyElec has a newer kernel already, but I agree that having official upstream support should be the best way to go. While I saw from kernel git that NanoPi R6S RK3588 already has more usable features in 6.3, so I am expecting something official might come out next year.

Those NanoPi are selling over priced when you buy them from overseas channel.
Since I speaks Chinese so I was able to order R2S/R4S/R6S at much lower price (e.g. R6S at 40% off when compared with Amazon) from their China selling channel directly (I don't live in greater China region, but they can ship me). I am looking forward to the R6C because I can get it with USD80, given the power consumption and the size I really like them (and I plan to use R2S + USB WiFi to form a travel router combination)

1 Like

The problem isn't the upgrade, is a bug in the nics initialization. sometimes at reboot the nics don't show up

see https://github.com/MichaIng/DietPi/issues/6342

so you need to unplug/plug the nanopi several times until the nanopi gets right the nics, you don't need to rewrite the sdcard the first upgrade is good, the problem belongs with the nics

Gabrielo

1 Like

Hi, I think this is a different unrelated topic. One is losing the partitioning after a sysupgrade and the other you linked is about sporadic ethernet device naming issue after reboots. The latter seems to be related to 5.15 kernel. I have not experienced it with 5.10 yet which is in the standard release.

Yes usually (I mean with some other releases) it was like you said: plug-in the power cable 1-2 times and the R4S started to work again but not after the 22.03.3.

I tried 2-4 times to do a power cycle but it didn’t worked.

The curious thing is that the router is up and running after the upgrade, I was able to ping it, but no GUI or SSH access. Then if you do a power cycle it stops responding also to a ping.

I suspect is something related to the custom size but I can’t debug it because the R4S looks like is bricked after the upgrade, until I flash the SD with a new/stock image.

yeah maybe is different issue, my experience is with building snapshots, one every week, but lately every month, from master with a 350Mb image, in that time the sysupgrade never failed, yes sometimes, if not always, I have to reboot the nanopi several times to get it to start in service after the sysupgrade, but never needed to take the sdcard out to rewrite it

so my nanopi run snapshots, not releases, so many variables are different to get a common cause

Well if you can ping it, the nics are ok, and is a different issue because the issue I wrote above the eth0 don't respond the pings

So I was able to do some benchmarks finally. We are moving soon to a new home, from the current 500/30 cable to 1000/300 FTTH pppoe internet. I bought the R4S hoping that it will be able to deal with this and maybe even do sqm on top.

I have seen it route gigabit with sqm but not how it deals with the additional pppoe overhead. I'm happy to report that it is fully capable of saturating Gigabit pppoe nat and even doing sqm over it with a+ rating on bufferbloat waveform test site. So I'm very happy with my choice, this is a perfect little router for Gigabit speeds.

speedtest page without sqm:

bufferbloat test with sqm set to 870:

all this over a pppoe connection.

I was using Anaelorlinski OpenWrt 22.03.5 (stable) minimal build. Schedulers were both on schedutil, irq on small cores, queues on the big cores.

3 Likes

FYI: I had time to build from Git (2023-05-13, just before kernel 5.15.111 got pushed) and update my device. My R4S is running smooth since about 12 hours.

Video: Did anyone here manage to get hardware encoding/decoding working?

could you give some tips how to do it?

Would you share your config settings please? also your net-smp-affinity? im using Qosify with the @anaelorlinski builds with Pppoe, and im setting my download to 700mbs to achieve a A rating on waveform, wondering if i have something configured incorrectly. Thanks

1 Like

That's not entirely correct, the r6c traded one of the 2.5gb ports for an M.2 2280. The r6s lacks that option so I would not call the r6c a "budget version". M.2 could provide storage,WIFI or SATA ports (etc).

1 Like

Yes, I'm sure there is room for improvement, I just played around with it for 1 day as we're not permanently at the new home yet. Just had to make sure it will be fine after we move there soon. For the config which I liked the most for the speed tests with pppoe+sqm I haven't even changed much from the defaults.

By default the IRQ's are going on the big cores, I haven't changed that. Also I left the default schedutil scheduler, as performance always keeps the freqs (and thus the consumption and temp) at max, while powersave keeps them fixed on the lowest. I just add these lines to set the queues to spread among the small cores in /etc/rc.local.

echo f > /sys/class/net/eth0/queues/rx-0/rps_cpus
echo f > /sys/class/net/eth1/queues/rx-0/rps_cpus

For SQM settings I just specified the limits like 800000 down / 290000 up and had cake/piece of cake set which are the defaults.

3 Likes