ebin-dev

To troubleshoot this thing I would just boot from another sd card with a fresh bookworm image leaving your system on emmc or on another sd untouched. In 'sudo ethtool -i <interface>' the name of your 2.5G interface has to be inserted - 'ifconfig' will reveal it (I renamed mine to end1). If the rtl_nic firmware is recognized correctly it will display: root@grid:~# sudo ethtool -i end1 driver: r8152 version: v1.12.13 firmware-version: rtl8156a-2 v2 04/27/23 ...

To troubleshoot that you could boot off a fresh Armbian 24.11.1 Bookworm image (6.6.62) and add rtl_nic firmware, replace dtb, setup rc.local. If transfer rates are still low something may be wrong with your client or with your helios64 or with the network itself. Did you launch 'htop' so that you can see what is going on during the data transfer? Are there any cores fully utilized ? Is nic offloading enabled ? etc. 'systemctl disable armbian-hardware-optimize.service' I am automatically calling that shell script while mounting helios64 as a remote drive on macOS clients (using netatalk). The names of the processes (afpd|cnid|iperf3|netatalk) need to be replaced by the processes involved in the data transfer on your helios (iperf3, smb? etc. ). root@grid:~# chmod +x /usr/local/bin/make_nas_processes_faster.sh root@grid:~# sh /usr/local/bin/make_nas_processes_faster.sh pid 21358's current affinity list: 4 pid 21358's new affinity list: 4 pid 21359's current affinity list: 4 pid 21359's new affinity list: 4 pid 21360's current affinity list: 4 pid 21360's new affinity list: 4 pid 21367's current affinity list: 4 pid 21367's new affinity list: 4 pid 21368's current affinity list: 4 pid 21368's new affinity list: 4 pid 21700's current affinity list: 4 pid 21700's new affinity list: 4

Well, the two packages libelf-dev and zlib1g-dev were missing on your installation and 'sudo apt --fix-broken install' resolved it. Reboot should be fine: after the dtb is replaced and 'update-initramfs -u' executed. Cheers

@greg396 You can downgrade linux to 6.6.87: unzip the file debs-6.6.87.zip on your helios, cd into the folder and submit 'dpkg -i linux*'. With linux 6.12. I get some timeouts during data transfer. You need to install the modified dtb for the linux-6.6 branch in /boot/dtb/rockchip/ (do not forget 'update-initramfs -u' after that and reboot). Follow the link load distribution and Install the code displayed ('cd ... exit 0') in /etc/rc.local and reboot. I have disabled any Armbian updates by commenting the text in /etc/apt/sources.list.d/armbian.list but submitting 'apt-mark hold armbian-firmware' may work as well. However, I have no idea whether or not OMV requires a specific kernel branch - but I don't think so. If you need to reinstall linux 6.12. you can collect the three corresponding deb packages (linux-image, linux-dtb and linux-headers) on http://beta.armbian.com/ (currently 6.12.25). P.S.: Alternatively you can also download the Armbian 24.11.1 Bookworm image (6.6.62) and start from the fresh image (add rtl_nic firmware, replace dtb, setup rc.local). If transfer rates are still low something may be wrong with your client or with your helios64 or with the network itself.

Hi greg396, solutions for your issue were discussed in the parallel thread: You need to update the rtl_nic firmware in /lib/firmware/rtl_nic and use the modified dtb for stability reasons. If there are any remaining problems, check the load distribution on your helios64 and the connection to your client. The iperf3 transfer speeds from helios64 to macos clients in our network are 280MByte/s without any dropouts (linux 6.6.87 is recommended), upload speed is around 230MByte/s and we are using it 24/7 without any issues.

Thanks for testing. I think that the load distribution is indeed essential to get good transfer speeds and it seems that the scheduler needs some help to do it right. With the settings posted before the load on cpus0-3 is below 20% and the load on cpus4-5 is between 60% and 80% while downloading a 2GB file from Helios64 to a client with effectively 280MByte/s (on linux 6.6.74, ondemand governor, ext4 FS, transfer with netatalk 4.1.1). But Helios64 only has to access a single 4TB SSD formatted to ext4 in this case. You could try to move your sata load to cpu5 ('echo 20' for the ahci interrupt) and the network load to cpu4 ('echo 10' for the xhci interrupt) and see if that helps (cpu5 is usually less frequently occupied compared to cpu4). # cat /etc/default/cpufrequtils ENABLE=true MIN_SPEED=600000 MAX_SPEED=1800000 GOVERNOR=ondemand

I have only checked the performance of the 2.5G interface with linux 6.12.10 - not the 1G interface. Could you check if the issue remains if you use linux 6.6.74 ? (install with 'dpkg -i linux*'; replace the dtb with the one attached; execute 'update-initramfs -u'; reboot) Edit: The 2.5G interface needs the hardware fix in order to operate reliably in mode 2500baseT/Full too: during ethernet handshaking 1G speeds could be established transiently. I think that this might have happened during the test with odroid h4+. Edit: You mentioned that helios went to 1.2GHz during the transfer. If the load is handled by a little core that may be the reason for the reduced transfer speed. A big core should be assigned to it. Therefore, the following code in /etc/rc.local is very helpful in this context (it also configures the ondemand governor and makes it responsive) [armbian-hardware-optimization is disabled on my system]: cd /sys/devices/system/cpu/cpufreq for cpufreqpolicy in 0 4 ; do echo 1 > policy${cpufreqpolicy}/ondemand/io_is_busy echo 25 > policy${cpufreqpolicy}/ondemand/up_threshold echo 10 > policy${cpufreqpolicy}/ondemand/sampling_down_factor echo $(cat policy${cpufreqpolicy}/cpuinfo_transition_latency) > policy${cpufreqpolicy}/ondemand/sampling_rate done for i in $(awk -F":" "/ahci/ {print \$1}" < /proc/interrupts | sed 's/\ //g'); do echo 10 > /proc/irq/$i/smp_affinity done for i in $(awk -F":" "/xhci/ {print \$1}" < /proc/interrupts | sed 's/\ //g'); do echo 20 > /proc/irq/$i/smp_affinity done exit 0 While transferring data to/from Helios64 some processes are involved such as iperf3 - or netatalk in my case. Those processes should also be executed on a big core. If iperf3 tests are performed or if helios64 is mounted as a remote drive I call the following script that assigns a big core and a preferred io scheduling class to those processes (to be adapted to your needs). This helps to make your nas_processes faster (kudos to @tkaiser) . # cat /usr/local/bin/make_nas_processes_faster.sh #!/bin/sh -e for i in `pgrep "afpd|cnid|iperf3|netatalk"` ; do ionice -c1 -p $i ; taskset -c -p 4 $i; done # >/dev/null 2>&1 rk3399-kobol-helios64.dtb-6.6.xx-L2-hs400-opp

Since only one of your laptops is affected by the reduced transfer speed I would rather search for any issues there (update NIC driver, check NIC configuration, exclude cable/connection issues, etc.).

The limited transfer rates of 200Mbit/s might be caused by a bad cable or a bad connection (dust in the connector ?). The 2.5G interface is unusable because of the missing hardware soldering fix. It doesn't work without it, at least if you connect it to a 2.5G switch. Did you have a look at the processor utilization while accessing the server ? ZFS is certainly a burden on the CPUs and not known as particularly fast. XFS would be an option (I am still using ext4).

The output using the original dtb of linux 6.12.10 (vanilla Armbian) looks like this: # uname -a Linux grid 6.12.10-current-rockchip64 #2 SMP PREEMPT Fri Jan 17 12:41:00 UTC 2025 aarch64 GNU/Linux # ls /sys/class/leds/ helios64:blue:hdd-status helios64:blue:net helios64:blue:power-status helios64:blue:usb3 helios64:green:status helios64:red:ata1-err helios64:red:ata2-err helios64:red:ata3-err helios64:red:ata4-err helios64:red:ata5-err helios64:red:fault mmc1:: # ls /sys/class/leds/helios64\:\:status ls: cannot access '/sys/class/leds/helios64::status': No such file or directory And the output using the patched dtb (voltages and hs400) for linux 6.12.10 looks like this: # ls /sys/class/leds/ helios64:blue:hdd-status helios64:blue:net helios64:blue:power-status helios64:blue:usb3 helios64:green:status helios64:red:ata1-err helios64:red:ata2-err helios64:red:ata3-err helios64:red:ata4-err helios64:red:ata5-err helios64:red:fault mmc1:: # ls /sys/class/leds/helios64\:\:status ls: cannot access '/sys/class/leds/helios64::status': No such file or directory The output is identical. I have also noticed this with linux 6.12.7: 'helios64::status' is simply missing.

I have noticed that the rtl8156a-2 v2 firmware update is not shown in dmesg anymore but ethtool confirms that it is loaded. With linux 6.12.10 the 2.5G interface seems to work as reliable and as fast as with linux 6.6.72: # uname -a Linux grid 6.12.10-current-rockchip64 #2 SMP PREEMPT Fri Jan 17 12:41:00 UTC 2025 aarch64 GNU/Linux # dmesg | grep r8152 [ 5.246547] usbcore: registered new device driver r8152-cfgselector [ 5.492500] r8152-cfgselector 2-1.4: reset SuperSpeed USB device number 3 using xhci-hcd [ 5.798285] r8152 2-1.4:1.0 eth0: v1.12.13 [ 5.825026] usbcore: registered new interface driver r8152 [ 6.057832] r8152 2-1.4:1.0 end1: renamed from eth0 [ 10.098029] r8152-cfgselector 2-1.4: reset SuperSpeed USB device number 3 using xhci-hcd [ 10.218126] r8152 2-1.4:1.0 eth0: v1.12.13 [ 10.666024] r8152-cfgselector 2-1.4: reset SuperSpeed USB device number 3 using xhci-hcd [ 10.744275] r8152 2-1.4:1.0 eth0: v1.12.13 [ 10.935926] r8152 2-1.4:1.0 end1: renamed from eth0 [ 14.284797] r8152 2-1.4:1.0 end1: carrier on # ethtool -i end1 driver: r8152 version: v1.12.13 firmware-version: rtl8156a-2 v2 04/27/23 # ./iperf3 -c 192.168.xx.30 -p 5201 Connecting to host 192.168.xx.30, port 5201 [ 5] local 192.168.xx.43 port 50652 connected to 192.168.xx.30 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.01 sec 282 MBytes 2.36 Gbits/sec [ 5] 1.01-2.01 sec 280 MBytes 2.34 Gbits/sec [ 5] 2.01-3.01 sec 278 MBytes 2.33 Gbits/sec [ 5] 3.01-4.01 sec 282 MBytes 2.36 Gbits/sec [ 5] 4.01-5.01 sec 280 MBytes 2.35 Gbits/sec [ 5] 5.01-6.01 sec 280 MBytes 2.35 Gbits/sec [ 5] 6.01-7.01 sec 268 MBytes 2.25 Gbits/sec [ 5] 7.01-8.00 sec 281 MBytes 2.36 Gbits/sec [ 5] 8.00-9.00 sec 281 MBytes 2.35 Gbits/sec [ 5] 9.00-10.01 sec 281 MBytes 2.35 Gbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-10.01 sec 2.73 GBytes 2.34 Gbits/sec sender [ 5] 0.00-10.01 sec 2.73 GBytes 2.34 Gbits/sec receiver iperf Done. # ./iperf3 -c 192.168.xx.30 -p 5201 -R Connecting to host 192.168.xx.30, port 5201 Reverse mode, remote host 192.168.xx.30 is sending [ 5] local 192.168.xx.43 port 50656 connected to 192.168.xx.30 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 230 MBytes 1.93 Gbits/sec [ 5] 1.00-2.00 sec 226 MBytes 1.90 Gbits/sec [ 5] 2.00-3.00 sec 222 MBytes 1.86 Gbits/sec [ 5] 3.00-4.00 sec 224 MBytes 1.88 Gbits/sec [ 5] 4.00-5.01 sec 232 MBytes 1.94 Gbits/sec [ 5] 5.01-6.00 sec 230 MBytes 1.93 Gbits/sec [ 5] 6.00-7.00 sec 231 MBytes 1.94 Gbits/sec [ 5] 7.00-8.01 sec 232 MBytes 1.95 Gbits/sec [ 5] 8.01-9.01 sec 229 MBytes 1.92 Gbits/sec [ 5] 9.01-10.00 sec 228 MBytes 1.91 Gbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 2.23 GBytes 1.92 Gbits/sec 92 sender [ 5] 0.00-10.00 sec 2.23 GBytes 1.92 Gbits/sec receiver iperf Done. # ./iperf3 -c 192.168.xx.30 -p 5201 --bidir Connecting to host 192.168.xx.30, port 5201 [ 5] local 192.168.xx.43 port 50661 connected to 192.168.xx.30 port 5201 [ 7] local 192.168.xx.43 port 50662 connected to 192.168.xx.30 port 5201 [ ID][Role] Interval Transfer Bitrate [ 5][TX-C] 0.00-1.01 sec 234 MBytes 1.95 Gbits/sec [ 7][RX-C] 0.00-1.01 sec 225 MBytes 1.87 Gbits/sec [ 5][TX-C] 1.01-2.01 sec 209 MBytes 1.75 Gbits/sec [ 7][RX-C] 1.01-2.01 sec 229 MBytes 1.92 Gbits/sec [ 5][TX-C] 2.01-3.01 sec 225 MBytes 1.89 Gbits/sec [ 7][RX-C] 2.01-3.01 sec 228 MBytes 1.92 Gbits/sec [ 5][TX-C] 3.01-4.00 sec 235 MBytes 1.98 Gbits/sec [ 7][RX-C] 3.01-4.00 sec 227 MBytes 1.91 Gbits/sec [ 5][TX-C] 4.00-5.01 sec 236 MBytes 1.98 Gbits/sec [ 7][RX-C] 4.00-5.01 sec 228 MBytes 1.91 Gbits/sec [ 5][TX-C] 5.01-6.01 sec 219 MBytes 1.84 Gbits/sec [ 7][RX-C] 5.01-6.01 sec 226 MBytes 1.90 Gbits/sec [ 5][TX-C] 6.01-7.01 sec 185 MBytes 1.55 Gbits/sec [ 7][RX-C] 6.01-7.01 sec 230 MBytes 1.93 Gbits/sec [ 5][TX-C] 7.01-8.00 sec 253 MBytes 2.13 Gbits/sec [ 7][RX-C] 7.01-8.00 sec 191 MBytes 1.61 Gbits/sec [ 5][TX-C] 8.00-9.00 sec 242 MBytes 2.03 Gbits/sec [ 7][RX-C] 8.00-9.00 sec 227 MBytes 1.90 Gbits/sec [ 5][TX-C] 9.00-10.01 sec 237 MBytes 1.98 Gbits/sec [ 7][RX-C] 9.00-10.01 sec 182 MBytes 1.52 Gbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID][Role] Interval Transfer Bitrate Retr [ 5][TX-C] 0.00-10.01 sec 2.22 GBytes 1.91 Gbits/sec sender [ 5][TX-C] 0.00-10.01 sec 2.22 GBytes 1.91 Gbits/sec receiver [ 7][RX-C] 0.00-10.01 sec 2.15 GBytes 1.84 Gbits/sec 25 sender [ 7][RX-C] 0.00-10.01 sec 2.14 GBytes 1.84 Gbits/sec receiver

The dtbs attached to my previous post can be used for kernel branches 6.6.xx and 6.12.xx respectively as identified in their names. There is no latest version - they are all the same for each kernel branch and posted for your convenience (so you don't have to compile them by yourself) until the patches make it into Armbian - hopefully soon. The message is actually that linux 6.6 rockchip64 kernels (LTS) are not built anymore by the current Armbian build system. Therefore there is an urgent need to test linux 6.12 on Helios64 (and report any issues here), since that is what is going to be shipped with the next release.

The voltage values were changed in opp-table-1 - the values used can be found (here) earlier in this thread. The dtb for the 6.6 branch still works fine with them (cache awareness and emmc HS400 speed is also enabled in it). I am currently using it with linux-6.6.79 as it provides the best performance and stability. rockchip64-current was bumped from kernel branch 6.6 to 6.12 (on Dec. 21st) and rockchip64-edge bumped to branch 6.13. These kernel versions are available on beta.armbian.com and any issues with them could be reported here. The downside is that linux-6.6 rockchip64 kernel versions are not built anymore by the current armbian build system. rk3399-kobol-helios64.dtb-6.6.xx-L2-hs400-opp rk3399-kobol-helios64.dtb-6.12.xx-L2-hs400-opp

You can further tune your system (see here). I am on linux 6.6.56 now and use the 6.6.34 dtb with the fixes.

Well, the dtbs contain fixes for the 6.6 and 6.10 branch respectively (see i.e. here). If the 2.5G port of your Helios64 is connected to a device (via a 2.5G switch), where that device is connected using a 2.5G USB-C adapter instead of a standard 1G ethernet plug, the transmission rates between the two devices rise to 2.5Gbit/s full duplex.