I recommend you redurce the rootfs size to 1024mb, so that you could easily keep the device up to date with owut.
Mask
buttom i can make it work by
echo 44 > /sys/class/gpio/export
echo "in" > /sys/class/gpio/gpio44/direction
how to make it work by hotplug script ?
Google translate.
There is a problem with the catastrophically low performance of NanoPI R3S on OpenWrt firmware.
Anyone can see this for themselves. Just run the benchmark wg-bench
-> https://github.com/cyyself/wg-bench
The result will be about 330-360 Mbits/sec.
This is the same result that a 2-core cortex a53 with a frequency of 1300 MHz from Mediatek MT7981 gives.
How can 4 cores of cotex a55 with a frequency of 1800 MHz be equal to 2 cores of cortex a53 1300 MHz?!
Obviously, it's all about a Linux kernel configuration error. The author of wg-bench
himself draws attention to this error -> A Wireguard comparison DB - #54 by cyyself
I looked through almost all platforms supported by OpenWrt -> https://github.com/openwrt/openwrt/tree/main/target/linux
And found that only the kernel for Rockchip is built with the configuration CONFIG_PREEMPT=y
-> https://github.com/openwrt/openwrt/blob/main/target/linux/rockchip/armv8/config-6.6
While all the others, Mediatek, Broadcom, Qualcomm, x86, have interrupts disabled in the kernel configuration CONFIG_PREEMPT_NONE_BUILD=y
.
Dear OpenWrt developers, please pay attention to the problem and make the appropriate changes to the kernel configuration for Rockchip.
Original.
Есть проблема с катастрофически низкой производительностью NanoPI R3S на прошивке OpenWrt.
Каждый может убедиться в этом лично. Достаточно запустить бенчмаркwg-bench
-> https://github.com/cyyself/wg-bench
Результат будет около 330-360 Mbits/sec.
Это такой же результат, который выдает 2-ядерный cortex a53 с частотой 1300MHz от Mediatek MT7981.
Разве 4 ядра cotex a55 с частотой 1800MHz могут равняться 2 ядрам cortex a53 1300MHz?!Очевидно все дело в ошибке конфигурации ядра линукс. На эту ошибку обращает внимание сам автор
wg-bench
-> A Wireguard comparison DB - #54 by cyyselfЯ просмотрел практически все платформы поддерживаемые OpenWrt -> https://github.com/openwrt/openwrt/tree/main/target/linux
И обнаружил, что только ядро для Rockchip собирается с конфигурациейCONFIG_PREEMPT=y
-> https://github.com/openwrt/openwrt/blob/main/target/linux/rockchip/armv8/config-6.6
Тогда как все остальные, Mediatek, Broadcom, Qualcomm, x86, в конфигурации ядра имеют отключенные прерыванияCONFIG_PREEMPT_NONE_BUILD=y
.Уважаемые разработчики OpenWrt, пожалуйста обратите внимание на проблему, и внесите соответствующие изменения в конфигурацию ядра для Rockchip.
Good catch. Probably you should create a ticket on github.
Created -> https://github.com/openwrt/openwrt/issues/17425
But I see the issue only after authorization on github. As if I wrote into the void.
Upd.:
Thought maybe I made a mistake when creating the "issue". Recreated the "issue" -> https://github.com/openwrt/openwrt/issues/17438
But everything is exactly the same, I see the "issue" only after authorization on github, after "sign out", nothing is visible anymore...
"Issues" on github is a black hole.
Subject: Assistance Needed for Installing OpenWRT on NanoPi R3s (2GB RAM, 32GB eMMC)
Hello Everyone,
I recently purchased a NanoPi R3s (2GB RAM, 32GB eMMC), and I’m new to OpenWRT. I’m looking for detailed guidance on how to install OpenWRT on this device. I’ve read that FriendlyWRT is often recommended, but I specifically want to install the official OpenWRT firmware.
I’d greatly appreciate any guidance, links to tutorials, or tips to ensure a smooth installation process.
Thank you in advance for your support!
i already re open issue ticket. here.
Thank you!
Additional data on the FriendlyWrt firmware has appeared -> https://4pda.to/forum/index.php?showtopic=1098192&view=findpost&p=134328037
I won't translate, I'm afraid the meaning will be lost after Google Translate.
The point is that during the test, even showing more than 600 Mbit/s, the processor core load does not even reach 40% -> https://4pda.to/forum/index.php?act=findpost&pid=134328037&anchor=Spoil-134328037-1
I hope that the OpenWrt team will solve this problem.
Hi,
any of you ever tried using an usb hub?
I tested several hubs and get spontanious errors and resets on the usb port. Same devices work without problems when connectd without hub.
I tried harddisks and WiFi dongles
edit: some of my testhubs have an external power supply. so that shouldn´t be the problem
I don't know why, but github ignores what I write, nothing is published.
Here in this comment -> https://github.com/openwrt/openwrt/issues/17454#issuecomment-2580086982
The line of code marked in green should be like this -> CONFIG_PREEMPT_NONE_BUILD=y
fixed it. someone already commit it to main branch.
I tested the performance of RC4 and RC5 last night. The performance was about 330Mb/s and was the same on both. I have not checked the latest snapshot yet. But did this update miss 24.10.0-rc5?
Jup, not in rc5. Merged two days ago in 24.10-SNAPSHOT. I believe current build has a (now patched) luci bug, maybe wait a build cycle?
Would be nice to hear latest results
I know, thanks a lot for the support on github!
My original post is here -> https://4pda.to/forum/index.php?showtopic=1098192&view=findpost&p=134595675
Google translate.
So, the first build for the Rockchip family, after changes made to the kernel configuration on 12.01.2025, which disabled the PREEMPTion kernel displacement mechanism.
The first to come out was, of course, a crooked snapshot, with an unclear package manager, half-APK/half-IPK... Well, for now, that's it.
How can you even understand in what configuration the kernel was compiled?
Status - System log, Kernel log tab -> http://192.168.1.1/cgi-bin/luci/admin/status/logs/dmesg .
Look at the second line of the log, at the very end of the line.
This is what the entry looks like with PREEMPT ON in the kernel:
[ 0.000000] Linux version 6.6.69 (builder@buildhost) (aarch64-openwrt-linux-musl-gcc (OpenWrt GCC 13.3.0 r28304-6dacba30a7) 13.3.0, GNU ld (GNU Binutils) 2.42) #0 SMP PREEMPT Sat Jan 4 21:35:37 2025
And this is what it looks like with it OFF:
[ 0.000000] Linux version 6.6.71 (builder@buildhost) (aarch64-openwrt-linux-musl-gcc (OpenWrt GCC 13.3.0 r28586-5ce1af9539) 13.3.0, GNU ld (GNU Binutils) 2.42) #0 SMP Mon Jan 13 06:47:54 2025Actually, on this snapshot wg-bench gives 520 Mbit/s, and after clearing the nft rules (nft flush ruleset) - 700 Mbit/s.
So if I understand correctly, wireguard performance is up from 330 to 520~700?
Nice!! Thnx for pointing it out when fix was needed.
It is more correct to consider that the performance increased from 350 to 520.
700 was obtained after clearing the nftables rules. This result can also be compared, but only with the results obtained after the same clearing of the nftables rules. Before the changes in the kernel, after the nft flush ruleset
command I received about 530 Mbit/s. That is, in this case, an increase from 530 to 700.
This commit improves more than just Wireguard on rockchip targets.
I upgraded from 24.10 rc5 to 24.10-SNAPSHOT on my R5C (same CPU as R3S). CAKE/layer_cake throughput improved from 400 Mbps to 568 Mbps, and the latency statistical distribution also tightened up and improved - a substantial latency improvement and higher throughput. Yay! Thank you for identifying the issue!