gprovost

Members
  • Content Count

    142
  • 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

851 profile views
  1. 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.
  2. 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.
  3. 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.
  4. 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
  5. @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.
  6. 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
  7. 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
  8. gprovost

    Helios4 Support

    @lanefu Humm yeah a bit tangential and honestly not really sure of the message you trying to share.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. @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.
  15. 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.