18 18
gprovost

Helios4 Support

Recommended Posts

@matzman666 Thanks for pointing to your test. It's true OMV default settings are not the best to get the best performance out of Helios4. It's always a trade off between ease of use and expert mode tweaking. Will need to see if we can tweak those settings during OMV install, but not really our priority right now.

 

@Tom3kK Yeah it's on top of our TODO list now to implement WoL. Should be implemented in the next 2-3 weeks.

Share this post


Link to post
Share on other sites

Is it still a bad idea to run zfs on a 32bit CPU? I heard that there was a problem with memory allocation and that there were efforts to re-implement zfs on linux to fix it, but not sure if the zfsonlinux project on github is that one or still the old one. I have compiled it nonetheless and it seems to be working fine for a 4x1.5gb raidz configuration. Won't use it though because it won't integrate with OMV and folder sharing is only possible with file systems it recognizes, and I'm not that big of linux guy to set it up myself.

 

(the zlua module won't load because of some setjmp error, but I have temporarily disabled it and compiled it that way, only a newly implemented minor feature of zfs does not work because of it)

Edited by gabest

Share this post


Link to post
Share on other sites

Hi,

I'm not sure if this is a known bug or not, but just posting here FYI.

 

I've been tinkering with 'fancontrol' recently. During testing I found that 'fancontrol' leaves the fans full stop when it bails out on any error. The 'disablepwm' function seems to have a tiny bug that actually sets the PWM value to it's minimum value in case a 'pwmX_enable' file cannot be found - which is the case for Armbian on Helios4:

# ls /dev/fan-j1[07]/ /sys/class/hwmon/hwmon[23]/
/dev/fan-j10/:
device  name  of_node  power  pwm1  subsystem  uevent

/dev/fan-j17/:
device  name  of_node  power  pwm1  subsystem  uevent

/sys/class/hwmon/hwmon2/:
device  name  of_node  power  pwm1  subsystem  uevent

/sys/class/hwmon/hwmon3/:
device  name  of_node  power  pwm1  subsystem  uevent

This minimum value causes the fans on my box to come to a full stop.

 

For my box, in case 'fancontrol' bails out, I'd like the fans to go full speed.

# $1 = pwm file name
function pwmdisable()
{
        local ENABLE=${1}_enable

        # No enable file? Just set to max
        if [ ! -f $ENABLE ]
        then
                ##[BUG] echo $MINPWM > $1
                ##[BUG] return 0

                ##[begin] Fixup to make sure fans return to their full speed when we bail out
                for VALUE in "${MAXPWM:-}" "${MAX:-}" '255'
                do
                        if expr "${VALUE:-}" : '^[0-9][0-9]*$' > /dev/null
                        then
                                # VALUE looks like a numerical value
                                if ( echo "${VALUE:-255}" > $1 )
                                then
                                        echo "Successfully written value '${VALUE:-N/A}' to PWM file '${1:-N/A}'."
                                        return # to caller
                                fi
                                # ...try next method
                        fi
                done
                false
                return
            

 

The fixup above worked for me, but USE AT YOUR OWN RISK.

 

Groetjes,

 

Share this post


Link to post
Share on other sites

Hi, (happy) new Helios4 owner here. I have a questing regarding power consumption:

 

I'm running a new, clean setup based on Armbian_5.68_Helios4_Debian_stretch_next_4.14.88.img.xz.

 

With no additional drives powered up, a cheap power meter shows the following results:

  • System running idle: 4-5 W
  • System halted after "poweroff": 6-7 W.

 

With two WD Red 8TB EFAX (still unconfigured) and one SSD 128GB (root fs) I get

  • System running idle, disks spinning: 23 W
  • System halted after "poweroff": 9 W.

 

Why does the halted system consume that much energy?

 

TIA

   Heinz

 

Share this post


Link to post
Share on other sites
On 2/21/2018 at 6:18 AM, gprovost said:

@jnko

In regards to XOR engine :

Check your kernel message you should see the kernel has detected 2 XOR engines.


[    0.737452] mv_xor f1060800.xor: Marvell shared XOR driver
[    0.776401] mv_xor f1060800.xor: Marvell XOR (Descriptor Mode): ( xor cpy intr pq )
[    0.776570] mv_xor f1060900.xor: Marvell shared XOR driver
[    0.816397] mv_xor f1060900.xor: Marvell XOR (Descriptor Mode): ( xor cpy intr pq )

In the current mvebu kernel configs, mv_xor driver is part of the kernel, not a module.

But I agree there is no obvious way to say if the system offload on the hardware XOR engine.

 

Hi,

I'm building my second box and was going for a mdadm RAID setup there. After doing some throughput tests, I found that the mv_xor unit is not used when accessing data on a RAID array (in my case I'm trying RAID6 for now).

 

It's indeed a kernel builtin, but it looks like it's initialized after the other builtins are initialized.

Dec 14 08:56:44 localhost kernel: [    0.004541] xor: measuring software checksum speed
Dec 14 08:56:44 localhost kernel: [    0.043886]    arm4regs  :  2534.000 MB/sec
<...>
Dec 14 08:56:44 localhost kernel: [    0.163886] xor: using function: arm4regs (2534.000 MB/sec)
<snip>
Dec 14 08:56:44 localhost kernel: [    0.239983] raid6: int32x1  gen()   270 MB/s
<...>
<...>
Dec 14 08:56:44 localhost kernel: [    1.259902] raid6: neonx8   xor()  1041 MB/s
Dec 14 08:56:44 localhost kernel: [    1.259904] raid6: using algorithm neonx4 gen() 1349 MB/s
Dec 14 08:56:44 localhost kernel: [    1.259906] raid6: .... xor() 1377 MB/s, rmw enabled
Dec 14 08:56:44 localhost kernel: [    1.259908] raid6: using neon recovery algorithm
<snip>
Dec 14 08:56:44 localhost kernel: [    1.425179] mv_xor f1060800.xor: Marvell shared XOR driver
Dec 14 08:56:44 localhost kernel: [    1.461595] mv_xor f1060800.xor: Marvell XOR (Descriptor Mode): ( xor cpy intr )
Dec 14 08:56:44 localhost kernel: [    1.461694] mv_xor f1060900.xor: Marvell shared XOR driver
Dec 14 08:56:44 localhost kernel: [    1.493578] mv_xor f1060900.xor: Marvell XOR (Descriptor Mode): ( xor cpy intr )

The previous builtins do benchmarking without seeing the mv_xor modules and both choose a SW method for xor'ing.

 

This is also evident by checking if the xor units produce any IRQs during writing to RAID array: almost no IRQs for either xor module:

46:          2          0     GIC-0  54 Level     f1060800.xor
47:          2          0     GIC-0  97 Level     f1060900.xor

Unfortunately, I don't have the time to deep-dive into this, but from previous experience with building kernels and doing some optimizations with changing initialization order of kernel builtins, it would help if this module is linked before both 'crypto/async_tx' and 'raid6' (not sure about the latter builtin/module name) - Link order determines the initialization order for builtin kernel modules.

 

Where to address this?

 

Groetjes,

 

Share this post


Link to post
Share on other sites

Sorry guys for late reply. I'm getting soon married and I'm pretty overloaded between Helios4 delivery follow-up and taking care of this big personal event. So please bare the latency in the coming days. Everything will be back to normal in February.

 

@gabest To be honest we haven't done much experiment with ZFS but we have couple of people that reported good feedback and performance with ZoL on Helios4. Most of them where using mirror vdev instead of raidz mode, you can find plenty of discussion on this topic but it's an important factor in the case of Helios4. The other important factor for good ZFS perf on Helios4 is deduplication. Actually the dedup mode is the main reason why ZFS need so much memory, so with 2GB in Helios4, you need to disable dedup if you want good perf.

In regards to ZoL maturity / stability on 32bit system, I don't have much insight on this. I just know that starting v0.7.0 some improvement were made for 32-bit stability. So for this reason it is recommended to use ZFS from stretch-backports (https://packages.debian.org/stretch-backports/zfsutils-linux)

 

@djurny Actually we modified fancontrol on purpose in order to set the fan speed to 0 when fancontrol exit. This was to address the use case when someone power down the system, in this case you don't want the fan to go full speed. But after the message from Harvey and my response below, I think there is a bit of contraction in our logic. Let me think about this and we might just revert the fancontrol to its original behavior.

 

@Harvey Helios4 Power Management is rather simple since it was designed for a system that is running 24/7 (or in IDLE/DEEP IDLE state if you want to use Wake-on-LAN).  We didn't include a PMIC in our design to address this specific use case of powered off system. When you halt your system, the Helios4 SoC power domain will remain ON and since there is no more OS running so there no more CPU Dynamic Frequency Scaling (DFS), so my guess is the SoC is running at its highest clock when system is halted compared to idle. This would explain the difference between in power consumption System IDLE and System Powered-Off. However we will need to double check that.

 

@djurny Humm very good point. When I was doing benchmark during the early stage of the project, it didn't get to my mind to check the /proc/interrupts. Only later when working on the CESA engine I figured out checking the interrupts was the way to check if engines were used to offload operations. It completely slipped my mind to do the same check again for XOR engines. Well thanks to you, I can see my early assumption was wrong. We will need to investigate how to force system to use the MV_XOR and how it would improve performance and/or system load.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
18 18