ebin-dev

The most current download images for Helios64 are now all provided with linux 6.18.xx. I downloaded a minimal image and checked the dtb: it would not appear to contain the opp-microvolt patch that made Helios64 finally stable. So for the ones who have stability issues again on Helios64, I attached the patched dtb compiled for linux 6.18.xx using the exact same opp-microvolt values as in the previous dtb versions I compiled for linux 6.6 and 6.12. The current linux deb files can be downloaded from beta.armbian.com, the linux 6.18.18 deb files I used can be downloaded from here (to be installed with 'dpkg -i linux*'). In order to install the dtb, simply unzip it, copy it into the proper location, update initramfs and reboot: # install the dtb with the opp-microvolt patch: unzip rk3399-kobol-helios64.dtb-6.18.18-opp.zip cp rk3399-kobol-helios64.dtb-6.18.18-opp /boot/dtb/rockchip/rk3399-kobol-helios64.dtb update-initramfs -u reboot rk3399-kobol-helios64.dtb-6.18.18-opp.zip

Thanks for your comments. I did not touch the regulator@40 values at all - only the opp frequencies in line with suggestions from @prahal and some cache settings. cpufreq sampling_rates were changed to about 40000 (depending on the cluster) for kernels 6.6 by a script in /etc/rc.local. The script does not apply anymore in linux 6.12. Instead of disabling the A72 cluster altogether, reducing the burden on the CPUs during data transfers helps to substantially reduce crashes and avoids triggering the watchdog timer. P.S.: I bought a Rock-5B in October 2022 and I finally migrated everything to it.

The rsync instruction copies the files using an exclude list. However that list does not explain why folders other than /var/log/journal are missing in /var/log. # cat /usr/lib/armbian-install/exclude.txt /boot/* /dev/* /proc/* /sys/* /media/* /mnt/* /run/* /tmp/* /ddbr/* /var/log/journal

You just have to create the nginx folder in /var/log with owner www-data (it is not created automatically): mkdir /var/log/nginx chown -R www-data:www-data /var/log/nginx systemctl restart nginx

With linux 6.12 the optimizations in /etc/rc.local do not apply anymore since some configuration options have vanished. So if you like to have a stable 2.5Gbit/s network connection without timeouts, linux-6.6 is still recommended (bookworm and trixie). You can build it yourself using an Armbian snapshot (from Dec. 2024) or download a recent linux-6.6.100 from here.

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.