gprovost

Members
  • Content Count

    113
  • Joined

  • Last visited


Reputation Activity

  1. Like
    gprovost reacted to djurny in Helios4 - Cryptographic Engines And Security Accelerator (CESA) Benchmarking   
    @matzman666 Sorry, no measurements. From memory the numbers for raw read performance were way above 100MB/sec according to 'hdparm -t'. Currently my box is live, so no more testing with empty FSes on unencrypted devices for now. Perhaps someone else can help out?
     
    -[ edit ]-
    So my 2nd box is alive. The setup is slightly different and not yet complete.
     
    I quickly built cryptsetup 2.x from sources on Armbian, was not as tough as I expected - pretty straightforward: configure, correct & configure, correct & ...
     
    cryptsetup 2.x requires the following packages to be installed:
    uuid-dev libdevmapper-dev libpopt-dev pkg-config libgcrypt-dev libblkid-dev  
    Not sure about these ones, but I installed them anyway:
    libdmraid-dev libjson-c-dev  
    Build & install:
    Download cryptsetup 2.x via https://gitlab.com/cryptsetup/cryptsetup/tree/master.  Unxz the tarball. ./configure --prefix=/usr/local make sudo make install sudo ldconfig  
    Configuration:
    2x WD Blue 2TB HDDs. 4KiB sector aligned GPT partitions. mdadm RAID6 (degraded).  
    Test:
    Write 10GiB 4GiB worth of zeroes; dd if=/dev/zero of=[dut] bs=4096 count=1048576 conv=fsync. directly to mdadm device. to a file on an XFS filesystem on top of an mdadm device. directly to LUKS2 device on top of an mdadm device (512B/4096KiB sector sizes for LUKS2). to a file on an XFS filesystem on top of a LUKS2 device on top of an mdadm device (512B/4096KiB sector sizes for LUKS2).  
    Results: See attached table.
     
    Caveat:
    CPU load is high: >75% due to mdadm using CPU for parity calculations. If using the box as just a fileserver for a handful of clients, this should be no problem. But if more processing is done besides serving up files, e.g. transcoding, (desktop) applications, this might become problematic. RAID6 under test was in degraded mode. I don't have enough disks to have a fully functional RAID6 array yet. No time to tear down my old server yet. Having a full RAID6 array might impact parity calculations and add 2x more disk I/O to the mix.  
    I might consider re-encrypting the disks on my first box, to see if LUKS2 w/4KiB sectors will increase the SnapRAID performance over the LUKS(1) w/512B sectors. Currently it takes over 13 hours to scrub 50% on a 2-parity SnapRAID configuration holding less than 4TB of data.
     
    Groetjes,
     

  2. Like
    gprovost reacted to hatschi1000 in Helios4 Support   
    Talking about anecdotes: Some of you might remember the issue of booting my helios4 with 2 HGST Deskstar HDDs I had approx. half a year ago (https://forum.armbian.com/topic/6033-helios4-support/?do=findComment&comment=57981).

    After we weren't able to find a solution on why the specific problem appeared here on the forum, I got in contact with @gprovost directly and after some back and forth messaging he kindly asked for the defective board to be sent back to Singapore. Soon after I received a fixed board back with which the problem did not appear anymore.

    Right now I'm still tinkering around my setup (2x2TB HDD in btrfs-RAID1 underneath OMV4 with (at some point at least) an automated offsite backup using btrfs-snapshots), without having had any significant problems - a big thumbs up to @gprovost and the entire helios team for the straightforward communication and flawless exchange of the faulty carrier board.
  3. Like
    gprovost reacted to lanefu in Helios4 Support   
    just an anecdote.    I received my Helios4 (from second production run) on Christmas eve.. what a present!

    Anyway I've got it up and running with just the stable armbian stretch image with OMV running raid 5 on 3x3TB enterprise drives and the thing is just a work of art.   I wish we'd get more SBCs on the market like this thing... not everyone needs a TV box.
  4. Like
    gprovost reacted to Caribou in Helios 4 connection TV   
    Hello @gprovost Thanks for your answer. Then, for me It will be a raspberry with raspian + kodi.
     
     
    Strongly the 3rd batch
  5. Like
    gprovost got a reaction from JakeK in Helios4 Support   
    We have been investigating the issue of the network interface that is sometimes not properly initialized (as reported by @JakeK) and we found the issue. During u-boot board initialization, the network PHY is supposed to be reset by toggling a GPIO (GPIO19). Unfortunately in our u-boot implementation the PHY reset call was happening too early when the SoC pin muxing wasn't completed yet, which means the GPIO pull up and pull down wasn't physically happening.
     
    We have added the fix to our u-boot repo  : https://github.com/helios-4/u-boot-marvell/commit/15c179624b28ddab7d212a0ef0571bcec91cf2ed
     
    @Igor Any chance you can trigger a build of just Helios4 u-boot and publish the u-boot .deb in the armbian repo ? This way everyone can easily get the fix by doing an upgrade. Thanks.
  6. Like
    gprovost got a reaction from tkaiser in Benchmarking CPUs   
    @tkaiser Here the link of my latest benchmark of Helios4 : http://ix.io/1jCy
     
    I get the following result for OpenSSL speed
    OpenSSL results: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-cbc 1280.56k 5053.40k 18249.13k 52605.27k 102288.04k 109390.51k aes-128-cbc 1285.51k 5030.68k 18256.13k 53001.90k 100128.09k 109188.44k aes-192-cbc 1276.82k 4959.19k 18082.22k 51421.53k 96897.71k 103093.59k aes-192-cbc 1290.35k 4961.09k 17777.24k 51629.74k 95647.06k 102596.61k aes-256-cbc 1292.07k 5037.99k 17762.90k 50542.25k 92782.59k 98298.54k aes-256-cbc 1281.35k 5050.94k 17874.77k 49915.90k 93164.89k 98822.83k  
    In order to leverage on hw crypto engine, I had no choice but to use OpenSSL 1.1.1 lib (openssl-1.1.1-pre8) and I decided to use cryptodev-linux instead of AF_ALG since it gives me slightly better result (+5-10%).
     
    Here a bit of findings regarding OpenSSL engines implementation :
     
    As stated in the changelog
    Changes between 1.0.2h and 1.1.0 [25 Aug 2016] *) Added the AFALG engine. This is an async capable engine which is able to offload work to the Linux kernel. In this initial version it only supports AES128-CBC. The kernel must be version 4.1.0 or greater. [Catriona Lucey] So using Debian Stretch package OpenSSL 1.1.0f, or any more recent 1.1.0 version, the only cipher supported by AFALG engine was effectively AES-128-CBC
    $> openssl engine -c (dynamic) Dynamic engine loading support (afalg) AFALG engine support [AES-128-CBC]  
    Starting OpenSSL 1.1.1, even though it is not mentioned anywhere in the changelog, AES192-CBC and AES256-CBC is supported by the AFALG engine
    $> openssl engine -c (dynamic) Dynamic engine loading support (afalg) AFALG engine support [AES-128-CBC, AES-192-CBC, AES-256-CBC]  
    But one thing much more exiting about OpenSSL 1.1.1 is the following
    Changes between 1.1.0h and 1.1.1 [xx XXX xxxx] *) Add devcrypto engine. This has been implemented against cryptodev-linux, then adjusted to work on FreeBSD 8.4 as well. Enable by configuring with 'enable-devcryptoeng'. This is done by default on BSD implementations, as cryptodev.h is assumed to exist on all of them. [Richard Levitte] So now with the 1.1.1 is pretty straight forward to use cryptodev, no need to patch or configure anything in openssl, openssl will detect automatically if module cryptodev is loaded and will offload crypto operation on it if presents.
    $> openssl engine -c (devcrypto) /dev/crypto engine [DES-CBC, DES-EDE3-CBC, BF-CBC, AES-128-CBC, AES-192-CBC, AES-256-CBC, AES-128-CTR, AES-192-CTR, AES-256-CTR, AES-128-ECB, AES-192-ECB, AES-256-ECB, CAMELLIA-128-CBC, CAMELLIA-192-CBC, CAMELLIA-256-CBC, MD5, SHA1] (dynamic) Dynamic engine loading support  
    Based on those info, and making the assumption that sooner than later openssl 1.1.1 will be available in Debian Stretch (via backports most probably), i think the best approach to add openssl crypto engine support in Armbian is via the cryptodev approach. This way we can support all the ciphers now. I will look how to patch properly dpkg openssl_1.1.0f-3+deb9u2 to activate cryptodev supports. @zador.blood.stained maybe you have a different option on the topic ?
     
     
  7. Like
    gprovost got a reaction from tkaiser in Benchmarking CPUs   
    @zador.blood.stained I think there isn't any distro OpenSSL packages that is built with hardware engine support.
    Also, even if engine is installed, OpenSSL doesn't use any engine by default, you need to configure it in openssl.cnf.
    But you right about cryptsetup (dm-crypt), it uses AF_ALG by default. I was wondering why so much delta between my 'cryptsetup benchmark' and 'openssl speed' test on Helios4.
     
    I just did a test by compiling openssl-1.1.1-pre8 with the AF_ALG (... enable-engine enable-afalgeng ...) and here are the benchmark result on Helios4 :
     
    $> openssl speed -evp aes-xxx-cbc -engine afalg -elapsed
    type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-cbc 745.71k 3018.47k 11270.23k 36220.25k 90355.03k 101094.74k aes-256-cbc 739.49k 2964.93k 11085.23k 34178.05k 82597.21k 90461.53k  
    The difference is quite interesting, with AF_ALG it performs much better on bigger block size, but poorly on very small block size.
     
    $> openssl speed -evp aes-xxx-cbc -elapsed
    type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-cbc 44795.07k 55274.84k 59076.27k 59920.04k 59719.68k 59353.77k aes-256-cbc 34264.93k 40524.42k 42168.92k 42496.68k 42535.59k 42500.10k  
    System : Linux helios4 4.14.57-mvebu #2 SMP Tue Jul 24 08:29:55 UTC 2018 armv7l GNU/Linux
     
    Supposedly you can even have better perf with cryptodev, but I think Crypto API AF_ALK is more elegant and easier to setup.
     
    Once I have a cleaner install of this AF_ALK (or cryptodev), I will run sbc_bench and send you ( @tkaiser ) the output.
  8. Like
    gprovost reacted to Igor in Helios4 Second Campaign is ON !   
    And updated images with many bugfixes.
     
     
  9. Like
    gprovost got a reaction from iNTiGOD in Helios4 Support   
    @iNTiGOD which build / image version are running ? 
    Maybe you can refer to the following blog post to check if the files on your system show to correct settings.
  10. Like
    gprovost got a reaction from chwe in Helios4 Support   
    @nemo19 Ok no need to look any further, you found the issue. There should be a thermal pad between the CPU and the Heatsink as shown below. Without the thermal pad no proper heat transfer can happen, therefore the CPU might have reached above Maximum Junction Temperature (115C) resulting by it to get unstable and crash. I'm really sorry about this missing thermal pad, this should definitively not have happened, I will report / complain to the company that handled the board assembly for us.
     
    FYI the thermal pad dimension we are using is 20x20x1mm.
     
    Please provide me by private message your complete shipping address. I will send you this missing thermal pad. In the meantime you can try using thermal paste, even though the gap between CPU and Heatsink is a bit too big for thermal paste.
     

  11. Like
    gprovost reacted to nemo19 in Helios4 Support   
    I received and mounted the thermal pad from SolidRun on Tuesday. My Helios4 now runs cooler and quieter under maximum load than when idling before. It's been running for 1 day 16 hours at 70% to 100% cpu load hashing files, staying below 80C and without crashing.
     
    If it keeps going like this I'll be very happy. Thank you for the great board and the great service!
  12. Like
    gprovost got a reaction from chwe in Helios4 Support   
    @bigheart Is the serial issue you described happens all the time after over night running ?
     
    The helios4 board has an onboard FTDI USB-to-UART bridge (FT230X), this way you don't need to have a RS232 port on your computer or to buy a USB-to-Serial converter.
    The FT230X is actually power supplied by the USB port of your computer that you connect to the Heliso4 micro-USB console port, so even if the Helios4 board is not powered-on the FTDI USB-to-UART bridge will still come to live and should be detected by your computer.
     
    Assuming your computer is a Linux machine, as soon as you connect the Helios4 console port you should see the following in your kernel messages
    $> dmesg -w [...] [684438.411938] usb 1-2: new full-speed USB device number 18 using xhci_hcd [684438.547622] usb 1-2: New USB device found, idVendor=0403, idProduct=6015 [684438.547631] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [684438.547636] usb 1-2: Product: FT230X Basic UART [684438.547639] usb 1-2: Manufacturer: FTDI [684438.547643] usb 1-2: SerialNumber: DN00KDNN [684438.551627] ftdi_sio 1-2:1.0: FTDI USB Serial Device converter detected [684438.551703] usb 1-2: Detected FT-X [684438.552290] usb 1-2: FTDI USB Serial Device converter now attached to ttyUSB0  
    If you unplug you should see the following USB disconnect message
    [684398.900050] usb 1-1: USB disconnect, device number 17 [684398.900432] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 [684398.900463] ftdi_sio 1-1:1.0: device disconnected  
    So when the serial issue you described happens again, you should try to unplug / plug the console port and see if you see the above messages appearing in you kernel messages.
     
    If the expected kernel messages appear but you still can't access the shell console of the Linux running on your Helios4, then the issue is somewhere else than the onboard FTDI USB-to-UART bridge (unless a very unlikely issue with the Dual-Buffer IC between the FTDI chip ans the SoM) . In this case you should post the full dmesg ouput of your Helios4 when the issue appear (use https://pastebin.com/ to share the output to us).
  13. Like
    gprovost reacted to tkaiser in Support of Helios4 - Intro   
    Good news: @zador.blood.stained imported (cherry-picked) vendor provided software support for Helios4 into our build system recently, I let on my host build an OMV image and it seems it's working out of the box: https://github.com/armbian/build/pull/812#issuecomment-342006038 (though some minor issues present we can focus now on).
  14. Like
    gprovost got a reaction from tkaiser in Support of Helios4 - Intro   
    Here some fresh benchmarks with Helios4 configured as RAID6, then as RAID5 with 4x HDDs Western Digital RED 2TB.
     
    Note : This is also a 1GB RAM version clocked at 1.6GHz.
     
    RAID 6
    md0 : active raid6 sdd1[3] sdc1[2] sdb1[1] sda1[0]
          39028736 blocks super 1.2 level 6, 128k chunk, algorithm 2 [4/4] [UUUU]
     
    With buffer cache
    iozone -e -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
    random random kB reclen write rewrite read reread read write 102400 4 112166 182202 878938 897663 720385 46844 102400 16 126067 193562 907704 1068469 1001711 98934 102400 512 118358 182862 985050 1006993 1001779 170459 102400 1024 117394 176268 875566 888008 889065 169862 102400 16384 114508 169885 818170 817925 827517 172793  
    With DIRECT IO
    iozone -e -a -I -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
    random random kB reclen write rewrite read reread read write 102400 4 5830 5826 34179 37669 2839 602 102400 16 12445 19215 66829 71497 10074 2198 102400 512 106759 116574 199069 281008 61111 124175 102400 1024 129763 105815 173525 237719 96948 139462 102400 16384 177544 171003 284953 315916 286591 164939  
    RAID5
    md0 : active raid5 sdd1[3] sdc1[2] sdb1[1] sda1[0]
          58543104 blocks super 1.2 level 5, 128k chunk, algorithm 2 [4/4] [UUUU]
     
    With buffer cache
    iozone -e -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
    random random kB reclen write rewrite read reread read write 102400 4 115183 170676 904434 895645 722963 51570 102400 16 119682 172369 1063885 1084722 1002759 116063 102400 512 123952 201012 989143 992372 1001279 148636 102400 1024 116065 197683 874443 885162 886703 198021 102400 16384 129151 199118 830783 845355 838656 180389  
    With DIRECT IO
    iozone -e -a -I -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
    random random kB reclen write rewrite read reread read write 102400 4 9552 10938 36978 39222 28551 530 102400 16 11185 20621 64135 77590 33906 2159 102400 512 40443 51534 96495 533923 536836 43272 102400 1024 84312 78308 122916 486366 440706 83712 102400 16384 196534 207664 598961 597055 619819 206123  
     
    On small block operation, my setup shows CPU utilization 50% and memory usage 50%.
     
    I know there is no obvious way to say if the system offload on the hardware XOR engine. Check your kernel message you should see the kernel has detected 2 XOR engine.
    [    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 armbian mvebu kernel config, mv_xor driver is part of the kernel, not a module.
     
    I'm still trying to figure out a more concrete way to confirm that the system offload on hardware engine, but based on benchmark it does.
     
     

     
  15. Like
    gprovost got a reaction from lanefu in Support of Helios4 - Intro   
    Hi Guys,
     
    That's nice to see the effervescence around Helios4. We have a pretty good start for the first 48hours, we are very optimistic.
     
    Thanks @tkaiser for being so proactive and already answering most people questions. I saw you were very active on CNX ;-) I have so many question to reply through KS, it's hard to catch-up.
     
    I take note of all your feedback. Regarding the HDD vibration absorbers and the filter screen, it's something I had already in mind but haven't found yet the right solution. Take note that the thickness of the acrylic plate is much ticker than usual PC metal case, so standard absorber won't fit. If I can find the right solution we might put these as part of the kit by default.
     
    Haha i see someone really wants its ECC RAM, but yes agree It would be a great stretch goal.
    We were also planning in the stretch goal list to include a OLED i2c screen.
     
    But well, first we need to see how the campaign progress in the next few days before dreaming too big.
     
    Cheers.
  16. Like
    gprovost got a reaction from zador.blood.stained in Support of Helios4 - Intro   
    Awesome Helios4 is successfully funded !!!
     
    We still accept orders till the end of the campaign : July 19, 2017
     
    https://shop.kobol.io/
     
    Thanks for the support.
  17. Like
    gprovost got a reaction from zador.blood.stained in Support of Helios4 - Intro   
    Awesome Helios4 is successfully funded !!!
     
    We still accept orders till the end of the campaign : July 19, 2017
     
    https://shop.kobol.io/
     
    Thanks for the support.
  18. Like
    gprovost got a reaction from zador.blood.stained in Support of Helios4 - Intro   
    Awesome Helios4 is successfully funded !!!
     
    We still accept orders till the end of the campaign : July 19, 2017
     
    https://shop.kobol.io/
     
    Thanks for the support.
  19. Like
    gprovost got a reaction from zador.blood.stained in Support of Helios4 - Intro   
    Awesome Helios4 is successfully funded !!!
     
    We still accept orders till the end of the campaign : July 19, 2017
     
    https://shop.kobol.io/
     
    Thanks for the support.
  20. Like
    gprovost got a reaction from zador.blood.stained in Support of Helios4 - Intro   
    Awesome Helios4 is successfully funded !!!
     
    We still accept orders till the end of the campaign : July 19, 2017
     
    https://shop.kobol.io/
     
    Thanks for the support.
  21. Like
    gprovost got a reaction from Igor in Support of Helios4 - Intro   
    @tkaiser The discount code (KSBACKER10) is valid till July 3rd.
     
    Like you, we were surprised to see such positive response to the ECC model, but it looks like the majority of our backers understood the added value and how it was differentiating even more the Helios4 from proprietary entry level NAS. So thank you to have suggested (many times) this upgrade ;-)
     
    Regarding 'getting more attention', it isn't that trivial unfortunately... we think that once the first Helios4 batch is received and used by our backers it will improve our exposure.
  22. Like
    gprovost got a reaction from zador.blood.stained in Support of Helios4 - Intro   
    Hey guys,
     
    Awesome news, our Kickstarter campaign is finally live. Be amount the first backers and enjoy our early bird deals :

    Our kickstarter page :  Helios4
     
    For some specs : Helios4_Specifications.pdf
     


    Basic Kit - 1GB (USD$125)
    (Save 16% off the $149 Retail - Limited to 50 units)

    Full Kit - 1GB (USD$139)
    (Save 18% off the $169 Retail - Limited to 130 units)

    Full Kit - 2GB (USD$165)
    (Save 11% off the $185 Retail - Limited to 70 units)
     
    Our kickstarter page :  Helios4
     
    Cheers ;-)
     
  23. Like
    gprovost got a reaction from zador.blood.stained in Support of Helios4 - Intro   
    Hey guys,
     
    Awesome news, our Kickstarter campaign is finally live. Be amount the first backers and enjoy our early bird deals :

    Our kickstarter page :  Helios4
     
    For some specs : Helios4_Specifications.pdf
     


    Basic Kit - 1GB (USD$125)
    (Save 16% off the $149 Retail - Limited to 50 units)

    Full Kit - 1GB (USD$139)
    (Save 18% off the $169 Retail - Limited to 130 units)

    Full Kit - 2GB (USD$165)
    (Save 11% off the $185 Retail - Limited to 70 units)
     
    Our kickstarter page :  Helios4
     
    Cheers ;-)
     
  24. Like
    gprovost got a reaction from zador.blood.stained in Support of Helios4 - Intro   
    Hey guys,
     
    Awesome news, our Kickstarter campaign is finally live. Be amount the first backers and enjoy our early bird deals :

    Our kickstarter page :  Helios4
     
    For some specs : Helios4_Specifications.pdf
     


    Basic Kit - 1GB (USD$125)
    (Save 16% off the $149 Retail - Limited to 50 units)

    Full Kit - 1GB (USD$139)
    (Save 18% off the $169 Retail - Limited to 130 units)

    Full Kit - 2GB (USD$165)
    (Save 11% off the $185 Retail - Limited to 70 units)
     
    Our kickstarter page :  Helios4
     
    Cheers ;-)
     
  25. Like
    gprovost got a reaction from zador.blood.stained in Support of Helios4 - Intro   
    Hey guys,
     
    Awesome news, our Kickstarter campaign is finally live. Be amount the first backers and enjoy our early bird deals :

    Our kickstarter page :  Helios4
     
    For some specs : Helios4_Specifications.pdf
     


    Basic Kit - 1GB (USD$125)
    (Save 16% off the $149 Retail - Limited to 50 units)

    Full Kit - 1GB (USD$139)
    (Save 18% off the $169 Retail - Limited to 130 units)

    Full Kit - 2GB (USD$165)
    (Save 11% off the $185 Retail - Limited to 70 units)
     
    Our kickstarter page :  Helios4
     
    Cheers ;-)