gprovost

Members
  • Content Count

    145
  • Joined

  • Last visited

 Content Type 

Forums

Member Map

Store

Crowdfunding

Raffles

Applications

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

    What you say concern people mounting on a 64bit Kernel a File System created on 32 bit Kernel. This is not the issue we are talking about. Our limitation is that simply you cannot address a File System > 16TB with a 32bit Kernel because of page cache limitation. I'm not aware of possible work around even with other File System than EXT. The only solution is to use a FUSE union file system to merge two or more partitions into one big volume. MergerFS : https://github.com/trapexit/mergerfs (It's available as a Debian package.) @9a3eedi @fpabernard You guys don't want to give a try to MergerFS ?
  3. gprovost

    Helios4 Support

    @tuxd3v Don't turn ON 64bit feature on partitions mounted on a 32bit system, this is completely wrong.
  4. gprovost

    Helios4 Support

    @9a3eedi Thanks for your feedback. Sooner or later we will do a refresh of Helios4 with a 64bit SoC... but it's not going to happen so soon. Have you tried MergerFS ? It could be used to union your different volumes into a single one. I'm not sure though if there might be some limitation because of the 32bit arch.
  5. 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.
  6. Just for info I updated the libssl1.0.2 cryptodev patch to work with latest libssl1.0.2 debian deb (libssl1.0.2_1.0.2r) https://wiki.kobol.io/cesa/#network-application-encryption-acceleration So if some people wanna test offload crypto operation while using apache2 or ssh for example ;-) You can also find a pre-build dpkg here if you want to skip the compile steps.
  7. gprovost

    Helios4 Support

    I just told you what the patch does, so you should be able to figure if the target file was modified or not. If you are unsure then better wait the next OMV LUKS plugin upgrade, hopefully this new feature might be added by then.
  8. gprovost

    Helios4 Support

    @jimandroidpc Well does the patch get applied ? the patch just modifies 2 lines in /usr/share/php/openmediavault/system/storage/luks/container.inc to add -c aes-cbc-essiv:sha256 to the crypsetup luksFormat command. Anyhow I just rise a change request on the OMV LUKS plugin and it seems the maintainer is going to make the improvement since this change could benefit many ARM SoC based board : https://forum.openmediavault.org/index.php/Thread/11592-LUKS-disk-encryption-plugin/?postID=198390#post198390 @fpabernard Well hopefully one day there will be a refresh revision of Helios4.
  9. gprovost

    Updated mvebu-next kernel

    Helios4 changes : Add support for Wake-on-LAN Enable WoL by default on eth0 Adjust fancontrol config to make fan spin even in idle Thanks @Igor
  10. @Igor Could we imagine another mechanism than to use git as an "upload front-end" ? Using git as some kind of spool folder is really not ideal. For instance if I clone today the armbian upload git project the size of the objects is already reaching 1.2 GB for a project that is essentially just a structure of empty folders. I even see the following error during cloning Cloning into 'upload'... remote: Enumerating objects: 75, done. remote: Counting objects: 100% (75/75), done. remote: Compressing objects: 100% (61/61), done. kex protocol error: type 7 seq 49316022.52 MiB | 6.67 MiB/s remote: Total 844 (delta 33), reused 40 (delta 14), pack-reused 769 Receiving objects: 100% (844/844), 1.22 GiB | 6.03 MiB/s, done. Resolving deltas: 100% (251/251), done. The easier would be to provide a FTP service with the same structure and limited access to people you grant right to upload.
  11. gprovost

    Helios4 Support

    @jimandroidpc I attached a dirty patch to hard code the right cipher in OMV LUKS plug-in. So when you create an encrypted device under OMV it will use the right cipher : aes-cbc-essiv:sha256 It's far to be the ideal way, we should actually request to the developer of the OMV LUKS plug-in to add the possibility for user to choose the cipher. To apply the patch sudo patch -d/ -p0 < helios4-omv-luks.patch helios4-omv-luks.patch
  12. gprovost

    Helios4 Support

    Hahah cool to hear that. The idea of Helios4 was to fulfill one specific scope : NAS. There are a lot of awesome boards out there but often they are trying to do too many things. For instance if we do a refresh of Helios4 with a new SoC that has some display output, I'm pretty sure we would decide to not expose it... in order to stick to a pure headless NAS server concept. Well we hope we will carry on this path of "disruptive" DIY NAS solution with future project, but it's not tomorrow that we will steal the market share of entry level proprietary NAS
  13. gprovost

    Helios4 Support

    @lanefu Humm yeah a bit tangential and honestly not really sure of the message you trying to share.
  14. gprovost

    Helios4 Support

    I don't think the OMV interface allows you to specify which cipher. You need to create the encrypted device via command line. Will need to check if we can tweak OMV in some way to make it use by default the cipher that can be accelerated by the CESA engines.
  15. gprovost

    Helios4 Support

    @jimandroidpc Please refer to this thread where quite a bunch of benchmarking numbers and important remarks were shared : https://forum.armbian.com/topic/8486-helios4-cryptographic-engines-and-security-accelerator-cesa-benchmarking/ Did you used the right cipher : aes-cbc-essiv:sha256 ? Other cipher won't be accelerated by the CESA engine. Anyway I encourage to follow up on the thread I shared.
  16. gprovost

    Helios4 Support

    @movanet You can first define deadtime = 10 in /etc/samba/smb.conf which is recommended to close inactive connections and avoid exhausting server's resources.
  17. gprovost

    Helios4 Support

    @movanet Based on your 2 log files, your system is completely overloaded by way too many rclone and smbd instances which trigger Out-of-Memory killer (oom-killer) which in turn will start to kill processes to try to free memory... this will make the system unstable and unresponsive. It seems it's even generating some mmc (sdcard) error, maybe because of the continuous swapping. So you need to do some proper setting / tunning for rclone to insure it doesn't kill your system.
  18. gprovost

    Helios4 Support

    @movanet Please run armbianmonitor -u command and share the link it will generate here. Ideally you run it when the issue appear.
  19. @djurny Yeah my test with irqbalance shows that at startup it pints some IRQ to CPU1 and some to both (see table below). I don't witness any dynamic change while stressing the system. When the SMP affinity is set as both cpu (value = 3) then the IRQ is allocated by default to CPU0. So it means with irqbalance, the only good thing I see is that the network device interrupt will be not on the same than CPU than ATA, XOR and CESA. But you right maybe doing manual pining of the IRQ to certain CPU would help performance in case of heavy load. But before doing such tuning there is a need to define a proper benchmark to measure positive and negative impact of the such tuning.
  20. Interesting point. Are you using smp_affinity to pin an IRQ to a specific CPU ? Some reference for this topic : https://www.arm.com/files/pdf/AT-_Migrating_Software_to_Multicore_SMP_Systems.pdf I'm honestly not sure you will gain in performance, you might see some improvement in the case of high load... but then I would have imagined that irqbalance (if installed) would kick in and starts balance IRQ if really needed. I will need to play around to check that.
  21. gprovost

    Helios4 Support

    @bramirez Ok, well unless you are very unlucky and got 2 drives which end up being faulty at the same time, I would say it’s an issue with the 5V HDD power rail on the carrier board. There is also the possibility the issue is coming from the AC adapter. Anyway, if you don’t want to waste more time troubleshooting and us trying to guess the issue, please PM me and we will arrange to replace/fix the faulty part ;-)
  22. gprovost

    Helios4 Support

    @bramirez well the next step would be to use a voltmeter (if you have ?) to the check the voltage of the 5V and 12V rails is correct. Even though it's pretty simple, you need to be sure of what you doing in order to not short circuit the board. Let us know first if with the other cable you still have the issue.
  23. gprovost

    Helios4 Support

    Humm, sounds like some power issue, maybe something wrong with the 5V HDD rail on the Helios4 board. Would be the first time, but it could be a faulty buck converter. Before jumping to conclusion, did you try with each SATA power cable, just to be sure it's not a cable issue ?
  24. gprovost

    Helios4 Support

    @bramirez I would first try to narrow down for sure where the sound is coming from. 1. shutdown gracefully the system (sudo halt from the console) and then switch off the power. 2. Open the front case panel and disconnect all the SATA power cables from the disks. 3. Power-up your system and check if you are still hearing this “buzzing” sound you describes. If you don’t hear anymore the sound we can conclude the problem comes from one of the HDDs. Otherwise the issue comes from something else, maybe faulty power. So please check the above first.
  25. I would suggest the following but I'm sure I'm missing your overall vision Let it as master, and master branch remain the default branch. Later this current master will be renamed as old Rename it as dev When ready to make the pivot following this RFC, copy the dev branch and name it master (which will be then the default branch) Only accept PR on dev branch Merge dev to master when ok to do. To be considered : - maybe there is not need of a distinction between next and dev, therefore next become also dev - moving all the current 'next kernel' as 'default kernel'. Cleaning up old distrib also.