ebin-dev

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.

These timeout issues are actually linux kernel related (see i.e. here). To get rid of those issues, disable scatter/gather offloading (just execute 'ethtool -K <iface> sg off' ; replace <iface> by your interface name like eth0). But transmission speed will suffer ! With some optimizations the timeout issues also disappear. Dealing with 2.5G traffic is quite a burden on the CPUs! Use jumbo frames. I am using the following content in /etc/rc.local to bind the tasks involved to the big cores (sata (cpu 4) and 2.5g network traffic (cpu 5)). How is your PC connected to your Helios64 ? If you are using an 2.5G USB-C adapter it should contain the latest version of the rtl8156 chip (31.04) (i.e. like this one). #!/bin/sh -e # # rc.local # # This script is executed at the end of each multiuser runlevel. # Make sure that the script will "exit 0" on success or any other # value on error. # # In order to enable or disable this script just change the execution # bits. # # By default this script does nothing. 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 rk3399-kobol-helios64.dtb-6.10.2-L2-hs400-opp rk3399-kobol-helios64.dtb-6.6.34-L2-hs400-opp

Download a new system image with linux 6.6.y, flash it to another sd card (just use etcher) and boot from it. I would recommend to copy the dtb from my post (for the 6.6 branch) and execute 'update-initramfs -u'. If you are using the 2.5G interface, replace the rtl firmware in /lib/firmware/rtl_nic. No need to install a new r8152 driver. You can then copy the system from sd to emmc using armbian-config (this also changes the bootloader on emmc) and boot from emmc. (If there are issues with the new bootloader installed on emmc, flash the following u-boot to emmc (linux-u-boot-edge-helios64_22.02.1_arm64) (see here).)

Here is my backup script - it copies the content from the running system - emmc (/) in my case - to sd (/mnt/sd). (create the mount point on emmc if it does not exist: 'mkdir /mnt/sd') As you can see the UUID that starts with 87654321... corresponds to the sd card, and the UUID starting with 12345678... corresponds to emmc. Type 'blkid' to get the UUIDs of your devices and insert them into the script accordingly. Check that the script can be executed (chmod +x backup.sh), insert a formatted sd card (ext4) and let the script run. That`s it. # cat backup.sh #!/bin/bash # Check if user is root if [ $(id -u) != "0" ]; then echo "Error: You must be root to run this script." exit 1 fi cat > install-exclude <<EOF /dev/* /proc/* /sys/* /mnt/sd/* /mnt/ssd/* /mnt/usb/* /mnt/hd/* /run/* # /tmp/* # /root/* EOF exec 2>/dev/null umount /mnt/sd exec 2>&1 mount --uuid 87654321-5709-4000-91ac-099eeefe4685 /mnt/sd rsync -avxSE --delete --exclude-from="install-exclude" / /mnt/sd # change fstab sed -e 's/UUID=12345678-3e1b-4e01-a6be-9ee203b1b54f/UUID=87654321-5709-4000-91ac-099eeefe4685/g' -i /mnt/sd/etc/fstab sed -e 's/UUID=12345678-3e1b-4e01-a6be-9ee203b1b54f/UUID=87654321-5709-4000-91ac-099eeefe4685/g' -i /mnt/sd/boot/armbianEnv.txt umount /mnt/sd rm install-exclude echo "SD - done."

MAC address changed in edge kernels to native hardware address (see here).

Did you update the r8152 firmware (link)? # dmesg | grep r8152 [ 5.245881] usbcore: registered new device driver r8152-cfgselector [ 5.460956] r8152-cfgselector 2-1.4: reset SuperSpeed USB device number 3 using xhci-hcd [ 5.741177] r8152 2-1.4:1.0: load rtl8156a-2 v2 04/27/23 successfully [ 5.795083] r8152 2-1.4:1.0 eth0: v1.12.13