gprovost

Members
  • Content Count

    113
  • Joined

  • Last visited

 Content Type 

Forums

Member Map

Store

Crowdfunding

Raffles

Everything posted by gprovost

  1. gprovost

    Helios4 Support

    Main thread for general questions related to Helios4 setup and usage. Note : Before asking a question please insure the information is not already available on HELIOS4 Wiki or addressed in a previous post in this forum. Latest Build : Check : https://dl.armbian.com/helios4/ (Build by Armbian Team) Check : https://wiki.kobol.io/download/ (Build by Kobol Team) We might sometimes release ahead of Armbian official release in order to make people enjoy latest fix or feature. Known Issues : During SATA heavy load, accessing SPI NOR Flash will generate ATA errors. Temporary fix : Disable SPI NOR flash by default. Refer to following page to use SPI NOR Flash : https://wiki.kobol.io/spi/ SDcard High Speed timing have compatibility issue with some brands. Temporary fix : Disable UHS option/support by default. Refer to following page to enable UHS mode : https://wiki.kobol.io/sdcard/ Wake-on-LAN is not yet implemented.
  2. 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.
  3. It's been a while I have on my TODO list : write a guide on how to activate and use the Marvell Cryptographic Engines And Security Accelerator (CESA) on Helios4. Previously I already shared some numbers related to the CESA engine while using @tkaiser sbc-bench tool. I also shared some findings on the openssl support for the kernel modules (cryptodev and af_alg) that interact with the cesa engine. My conclusion was : 1. performance wise : effectively cryptodev performs slightly better than af_alg. 2. openssl / libssl support : very messy and broken, it all depends which version of openssl you use. Since many Debian Stretch apps depend on "old" libssl (1.0.2), I felt taking the cryptodev approach was the best way since it could expose all encryption and authentication algorithms supported by the cesa engine... even though it requires some patching in openssl. Plus cryptodev implementation in new LTS openssl version 1.1.1 has been completely reworked, so long term it should be the right way. Anyhow I'm not going to describe here the step by step setup, I'm already writing a page on our wiki for that, once it's ready I will post the link here. Also I won't risk myself talking about the relevance of some of ciphers, it deserves a topic on its own. I'm just going to share benchmark number on a concrete use case which is HTTPS file download : So I setup on my Helios4 Apache2 to serve a 1GB file hosted on a SSD drive. Then I did 3 batch of download tests, for each batch I configured Apache2 to use a specific cipher that I know is supported by the cesa engine. AES_128_CBC_SHA AES_128_CBC_SHA256 AES_256_CBC_SHA256 For each batch, I do the following 3 tests : 1. download without cryptodev module loaded (100% software encryption) 2. download with cryptodev loaded and libssl (openssl) compiled with -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS 3. download with cryptodev loaded and libssl (openssl) compile only with -DHAVE_CRYPTODEV, which means hashing operation will still be done 100% by software. Here are the results : Note: CPU utilization is for both cores. Obviously each test is just a single process running on a single core therefore when you see CPU utilization around 50% (User% + Sys%) it means the core used for the test is fully loaded. Maybe i should have reported the number just for the core used, which would be more or less doing x2 of the value you see in the table. For reference: Using AES_128_GCM_SHA256 (Default Apache 2.4 TLS cipher. GCM mode is not something that can be accelerated by CESA.) CPU Utilization : User %42.9, Sys %7.2 Throughput : 30.6MB/s No HTTPS CPU Utilization : User %1.0, Sys %29.8 Throughput : 112MB/s CONCLUSION 1. Hashing operation are slower on the CESA engine than the CPU itself, therefore making HW encryption with hashing is less performant than 100% software encryption. 2. HW encryption without hashing provides 30 to 50% of throughput increase while decreasing the load on the CPU by 20 to 30%. 3. Still pondering if it's worth the effort to encourage people to do the move... but i think it's still cool improvement.
  4. 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.
  5. 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/
  6. @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.
  7. 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.
  8. @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 ?
  9. 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.
  10. 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...
  11. 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).
  12. 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.
  13. @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/
  14. @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.
  15. 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 :
  16. 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.
  17. gprovost

    Helios4 Support

    @hatschi1000 Happy to hear all going smoothly.
  18. gprovost

    Helios4 Support

    @lanefu Thanks for the anecdote, always nice to hear some feedback from user. Would be great if you can post a picture of your setup on our FB page or/and our Twitter. Cheers.
  19. Is it the objective to address upgrade from previous bsp package to new bsp++ packages ? If I grasped correctly the new approached, then I guess will need then to replace the current armbian-bsp package by a metapackage pointing to armbian-bsp.deb + family.deb + board.deb. This should address the upgrade path... but might still create some tricky use cases.
  20. @Igor Are you going to define a deadline when all the different board maintainers must have migrate&adapt whatever stuff they have in build/packages/bsp/ into build/config/packages/ ?
  21. gprovost

    Revisiting the installation process

    I think it would be helpful to list all the u-boot + rootfs location combinations possible. Something like that : Then for each board we define in a definition file what combination is supported. We could use bitmap hex value. For example 0x13 will means the board only support MMC/MMC, MMC/Block Device and Block Device/Block Device. Regarding the utility feature, for example today on Helios4, it takes 2 steps to completely move away from SDcard 1st - Install U-boot in SPI (menu 5 Install the bootloader to SPI Flash) 2nd - Move RootFS to other device than USB (menu 6 Boot from SPI - system on SATA, USB or NVMe) I think it's ok that way, but we could have imagined this to be done in one step, where the user would choose through the interactive menu : U-Boot Location + RootFS Location, then from there the script take care to fulfill the new locations. As you described it, the new script should be designed to address only the generic use cases, any board specific use case should be address via a plug-in / sub-script. I also agree with you, when user choose the partition type for the new rootfs target, he should be able to choose LUKS. However, your point on hardware crypto off-load is off topic and only related to kernel crypto framework, it has nothing to do with u-boot | rootfs migration. I understand the utility name is up to discussion, but if it ends up being just a subset of armbian-config then maybe yes the name doesn't matter. I will still venture to coin a name : uboot-rootfs-manage.sh
  22. gprovost

    Helios4 Support

    @Zykr you could also replace the content /boot with the one you extract from an image. Under linux you can mount .img file with a loop device and browse its content.
  23. gprovost

    Helios4 Support

    @Zykr to complement what I wrote before. You could use following u-boot commands to boot manually on the correct kernel. Then once booted as wrote above, you should fix the wrong symlink in /boot ;-) setenv bootargs "console=ttyS0,115200 root=/dev/mmcblk0p1 rootwait rootfstype=ext4 ubootdev=mmc scandelay loglevel=1" load mmc 0:1 ${fdt_addr} /boot/dtb-4.14.83-mvebu/${fdtfile} load mmc 0:1 ${ramdisk_addr_r} /boot/initrd.img-4.14.83-mvebu load mmc 0:1 ${kernel_addr_r} /boot/vmlinuz-4.14.83-mvebu setenv fdt_high 0xffffffff setenv initrd_high 0xffffffff bootz ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr}
  24. gprovost

    Helios4 Support

    @Zykr It is very strange and not normal that the upgrade installed a 4.4.y instead of a 4.14.y kernel. Did you do apt-get upgrade or did you manually choose the linux-image package ? So it could be something similar that what pointed out Tido above. The ext4ls mmc 0:1 /boot/ command doesn't show the symlink target unfortunately. But based on the load sizes in your uboot log, u-boot is loading the initramfs (uIinitrd) ver 4.14.83 and loading kernel (zImage) ver 4.4.153 which is completely wrong and explain why the boot fails. The easiest would be to mount the microSD Card on your personal computer and check / fix that the following symlinks in /boot are as follow: dtb -> dtb-4.14.83-mvebu uInitrd -> uInitrd-4.14.83-mvebu zImage -> vmlinuz-4.14.83-mvebu @Igor Is it an issue you experienced before ?
  25. @Koen Good point, will do a benchmark one of those days.