gprovost

Members
  • Content Count

    113
  • Joined

  • Last visited

1 Follower

About gprovost

  • Rank
    Elite member

Contact Methods

  • Website URL
    http://kobol.io

Profile Information

  • Gender
    Male
  • Location
    Singapore

Recent Profile Visitors

729 profile views
  1. gprovost

    Helios4 Support

    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.
  2. gprovost

    Slow lan speed transfer rate

    @Mirco As discussed with you on FB, the mii-tool command you did confirmed that the Helios4 is connected at 1Gbps full duplex with your router/switch. $> sudo mii-tool eth0 eth0: negotiated 1000baseT-FD flow-control, link ok You did your iperf measure from a laptop connected by wifi to your router, so the perf you get is due to the low throughput with your wifi connection. Do your perf test with a computer or laptop that has a gigabit LAN interface.
  3. @Igor I think need to be careful here to no encourage people to already take in consideration upgrade path. Before (current master branch) board tweaks were only applied during build. So any changes in those tweaks would not get propagated to users with apt upgrade. Only choices for them were either to do fresh install or to manually change the tweak on target. Now with this RFC, tweaks are move to deb package. Those board deb packages I supposed will get published in the APT repo, and their version will increment through time ?? Some of those tweaks implies to modify some files in the rootfs with via pre/postinst scripts. Therefore it's important to take in consideration the fact that during board package upgrade maybe those files which require tweaks have already been modified by the pre/postinst scripts of previous board package version. I'm pretty sure some of the pre/postinst script out there will mess up files in the rootfs by trying to apply tweak on an already tweaked file. So to avoid any future nightmare, you should encourage people to already take in consideration the upgrade path. The other benefit to do so, is that this new RFC would then also maybe work for upgrading pre-RFC system. Maybe it was clear to everyone but I think it's worth to be clarified. Update: Here an example : https://github.com/armbian/build/blob/tvboxes/config/packages/99-board/dedicated/cubietruck/armbian.postinst.bash At every upgrade this postinst script would add an additional MACADDR line with a new MAC address in file /etc/default/brcm40183. I guess this is not what you want, so it's why it's important to emphasis upgrade path handling.
  4. I noticed that once in a while I receive Jenkins notification from some build machine under lollipopcloud.solutions domain. I guess I receive notification whenever my email is in some commits covered by the build. Is this build machine some armbian official build machine ? In any case I cannot access the linked jenkins portal. http://jenkins.build.lollipopcloud.solutions:8080/job/Armbian/38/
  5. Yes correct, we remove postinst script in u-boot package. Then in armbian-config / nand-sata-install we add a new option with title "Update u-boot on $BOOT_DEVICE". This option will just do write_uboot_platform $DIR $BOOT_DEVICE. Update: If you ok then I will do a PR.
  6. @Igor The approach of just extracting u-boot dpkg intead of installing it will then only concern fresh install then. What about people with an already running system where u-boot dpkg is installed ? Then when they do an upgrade their u-boot will still get updated ! If the idea is to avoid auto update of u-boot for all board, then removing the post-inst script from u-boot package is the best approach. In any case what the point to keep it moving further ?
  7. Instead why not keep installing the u-boot package for all boards but we remove the postinst script from u-boot package and replace it by a message saying to user to use armbian-config to write new version of u-boot to target. I would make things simpler.
  8. gprovost

    Revisiting the installation process

    Yes it's one way to go, download only from APT the u-boot package matching the install armbian version, then extract the u-boot.bin from the deb and then write to target. But then what about bootscript update ? Current u-boot preinst and postinst scripts were a way to update bootscript. What will be the new way post RFC ? I was mixing up, it's armbian-bsp pre/postinst dpkg that updates bootscript :/ So all good...
  9. gprovost

    Revisiting the installation process

    I just want to linked up an important comment here from ongoing RFC WIP disucssion, this way we know what additional use case we need to address in nand-sata-install (or whatever new name).
  10. gprovost

    Helios4 Support

    @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.
  11. @matzman666 Very interesting findings and well broke down tests 1. I wasn't aware that with LUKS2 you can define sector size bigger than 512b, therefore decreasing the number of IO operations. 2. I never investigate how RAID perf can be impacted with nowadays HDD that support block size of 4K (Advanced Format). Non-aligned 4K disk can effectively show a significant performance penalty. But I'm still a bit surprise that you see that much perf difference (26%) with and without disk alignment on your tests without encryption. https://raid.wiki.kernel.org/index.php/A_guide_to_mdadm#Blocks.2C_chunks_and_stripes Would you be interested to help us improve our wiki, on the disk alignment part and then on the disk encryption part ? https://wiki.kobol.io/mdadm/ https://wiki.kobol.io/cesa/
  12. @djurny Thanks for the benchmark, very useful number. It reminds me I need to indicate on the wiki the correct cipher to use with cryptsetup (preference for aes-cbc-essiv over aes-cbc-plain*) when people create their LUKS device since on latest version of cryptsetup the default is cipher is aes-xts-plain64. Time to combine both benchmark tests together as suggested by @Koen BTW you don't need to load mv_cesa module. This is an old module which is replaced by marvell_cesa.
  13. gprovost

    Helios4 Support

    @thermalz please PM me and we see from there if we should proceed to a replacement of the board. Just reminder to all, as mentioned on our wiki in several place :
  14. gprovost

    Helios4 Support

    @GeckoX Good to hear you figure it out. Yes OMV is the easiest approach to setup your NAS without the need to be too much Linux savvy. @Koen No there is no microSD card included in the kit. Some users of the 1st batch got a free microSD card but it was a free goodie from the PCBA factory to apology from their repeated delay.
  15. gprovost

    Helios4 Support

    @hatschi1000 Happy to hear all going smoothly.