Call for testers: OMV4 for ARM boards

  • The -R switch worked:
    iperf -c 192.168.0.13 -p 5201 -u -b 1000m -i 10 -t 60 -R


    Result is around 650-700 Mbits/s:


    htop:

  • Result is around 650-700 Mbits/s

    Also too low. And the htop screenshot confirms that IRQ affinity on this OS image needs some love. BTW: I was asking for iperf3 (not iperf) numbers for a reason: iperf3 also displays count of retransmits (nice to spot bad cables and/or switch ports).


    Anyway: it's obvious that there is a lot missing wrt ideal settings with the NAS use case and ODROID N2 in mind. Maybe someone with interest in this device (definitely not me) looks into this and applies the relevant optimizations (that are well documented since years).

  • I know a rpi is not a good device for nas, but I could set up and run some tests on a rpi2 and rpi3, if this is of any help

    Thanks but that's not helpful since the lousy performance of Raspberries as NAS is well known (reasons included). The crucial point here with this new ODROID N2 is the same as with every other more capable ARM SBC out there: default settings suck.


    The hardware is able to perform better than 99% of x86 OMV boxes but due to insufficient settings the board performs only at 33%-50% level. With the knowledge we collected it is rather easy to deploy settings that let the N2 perform as superior NAS. But someone has to do this (and that's definitely not me this time since dealing with Hardkernel in 2019 sucked so far and I'm not that much interested in the platform anyway :) )

  • Also too low. And the htop screenshot confirms that IRQ affinity on this OS image needs some love. BTW: I was asking for iperf3 (not iperf) numbers for a reason: iperf3 also displays count of retransmits (nice to spot bad cables and/or switch ports).


    My bad about mixing up iperf and iperf3, the windows machine had a iperf3 running, installed the wrong package on the Odroid-N2.


    iperf3_1000M.txt
    Lost/Total Datagrams are around 50% ... doesn't look good at all, probably the cables are not ok.
    The switch is a Linksys LGS108 Gigabit Unmanaged Switch.


    CPU usage is about the same as yesterday: +- 80% on CPU0



    iperf3_100M.txt a little "less worse" I suppose...


    I'll try with proper cables on the one I have at home.


    Anyway: it's obvious that there is a lot missing wrt ideal settings with the NAS use case and ODROID N2 in mind. Maybe someone with interest in this device (definitely not me) looks into this and applies the relevant optimizations (that are well documented since years).

    Would installing irqbalance help ?


    I checked the affinity for the IRQ of eth0 and it is set to a 3F mask, so 6 cores.
    for i in $(seq 0 300); do grep . /proc/irq/$i/smp_affinity /dev/null 2>/dev/null; done


    All other IRQ's were the same except for IRQ 14 which is Meson TimerF.
    Now this rings a bell as the driver for eth0 is listed as meson6-dwmac


    dmesg |grep eth


    Should I go ahead and put the same 3F affinity mask for IRQ 14 ?




    Also the 840 EVO SSD is not playing well with the Odroid-N2, my first guess is that it doesn't get enough power from the board.
    It takes ages to show up in the OMV4 disk list and performance over SAMBA was worse then the regular external USB3 disk I tested yesterday.
    Then regarding UAS/UASP, the USB3 enclosure uses an ASM1051E SATA 6Gb/s bridge for which I checked the UAS compatibility: Blacklisted / UAS disabled
    I'll pull it out and try with an USB3/sata dongle I have somewhere, maybe it uses another controller.


    The 4.9.170+ kernel has UAS suport : CONFIG_USB_UAS flag is set.



    Can't say about NFS yet, as shares would not show up on the Windows machine although the NFS components/services are installed.

  • Most probably the same recipe as for all the 'officially' supported SBC will help:

    • static IRQ affinity settings (putting network and USB3 on different big cores)
    • enabling Receive Packet Steering (RPS) and maybe also Receive-Side Scaling (RSS)
    • moving the filesharing daemons to big cores if the scheduler doesn't do this on his own
    • tweaking the IO scheduling of these daemons with ionice
    • Improved Samba settings

    That's what we did on the other SBC in the past as already linked to above. But as also already said I've no big interest in N2 and Hardkernel in general any more. USB(3) storage sucks, USB disks behind USB hubs suck even more (that's how every ODROID except HC1/HC2/MC1 is designed) and after I learned that Cortex-A73 saves ECC for L1 caches and most probably Amlogic also saved ECC for the L2 cache on the S922X my interest dropped even more (I love data integrity). Well, Amlogic does TV boxes not NAS :)

  • A question regarding the OMV_4_Odroid_XU4_HC1_HC2.img.xz image for my Odroid HC2.


    How can we set up a setup a static IP? The Armbianconfig tool isn’t installed?
    I’m probably missing something really obvious but the oMv GUI doesn’t display any network info.


    1 last question. I am using a 64gb microsd with only about 8-9gb being used by the os. Do I need to resize it or can I leave it as is? I purchased a larger card so it would last longer with rewrites.

  • How can we set up a setup a static IP?

    On the OMV images for ARM devices the best idea is to use nmtui (reasons why). You can also let your router assign always the same address to this device and this address really shouldn't matter since mDNS usually works. Can't you access your HC2 using the name odroidxu4.local?


    (armbian-config exists too but is useless for this network configuration stuff).


    I am using a 64gb microsd with only about 8-9gb being used by the os. Do I need to resize it

    No.

  • On the OMV images for ARM devices the best idea is to use nmtui (reasons why). You can also let your router assign always the same address to this device and this address really shouldn't matter since mDNS usually works. Can't you access your HC2 using the name odroidxu4.local?


    (armbian-config exists too but is useless for this network configuration stuff).


    No.


    Thanks TKaiser answering my questions. :)
    And sorry I forgot to mention I didn’t try to access the hc2 via the name above but it does work. I always try via IP address.

  • I didn’t try to access the hc2 via the name above but it does work. I always try via IP address

    Just why? While everyone is relying on DNS for accessing hosts/services on the Internet the same people think using the intelligent approach (remembering namens and not numbers) wouldn't work in their own network.


    With OMV4 you simply define the hostname and can then access the services using $hostname.local. In the meantime even with Windows since it took Microsoft just a decade to ignore mDNS/Zeroconf until they integrated it into Windows 10.

  • Just why? While everyone is relying on DNS for accessing hosts/services on the Internet the same people think using the intelligent approach (remembering namens and not numbers) wouldn't work in their own network.


    With OMV4 you simply define the hostname and can then access the services using $hostname.local. In the meantime even with Windows since it took Microsoft just a decade to ignore mDNS/Zeroconf until they integrated it into Windows 10.


    I’ve always done it this way because I didn’t know any better until I saw your post. Seems to work well using Firefox but can’t get it to work with opera browser.


    The more you know.

  • Further to above. If I use the hostname can I also use hostname to access specific ports on the server? Eg port 32400 for plex or rutorrent??


    I don’t believe you can without using the full ip address

  • If I use the hostname can I also use hostname to access specific ports on the server? Eg port 32400 for plex or rutorrent??

    Of course. Name resolutions simply works. Since decades. All of us use this feature each and every single day... on the Internet.


    But due to the Internet being flooded with shitty tutorials and weird advice almost everyone believes this wouldn't work at home. It's a mess.


    Given you assigned the hostname omv to your OMV install then you can access the web interface using http://omv.local, can reference your NAS as afp://omv.local from macOS or \\omv.local from Windows (starting with Windows 10) and can access Plex with http://omv.local:32400


    If this wouldn't simply work the whole WWW as we know it wouldn't work.

  • Hi All,


    I'm trying to configure wifi on new OMV4 install on my raspberry pi 3B (non-plus) version.


    Before you say so, I know rpi3b is not the best sbc out there (actually one of the worst).
    The pi has been laying on the shelf for good 2 years before I decided to use it at least as lightweight nas - torrent box specifically.


    I followed steps listed here very carefully.


    • I flashed SD card using etcher.
    • Connected Ethernet, put SD in rpi, powered up
    • waited ~1 hour before rpi rebooted sucesfully

    The install is working but I cannot get the wifi to work.
    I ignored all the outdated advices out there and followed nmtui-connect instruction.


    It doesn't work, unfortunatelly.
    When I issue nmtui-connect all I see is only Wired Connection 1, no signs of wireless connections (I'm sure, networks are in range, as I can see and connect to them, when using pure raspbian).


    Please can you help me to configure wifi?
    I'm using official 5.1V/2.5A power adaptor, trying to connect via onboard wifi.


    I'm running:

    Code
    Welcome to ARMBIAN 5.46 experimental Debian GNU/Linux 9 (stretch) 4.14.34-v7+

    Edit: this might be completely unrelated, but may be not.
    During boot I'm getting: [FAILED] Failed to start Realtek H5 bluetooth support.

  • 4.14.34-v7+

    Kernel too old so something went wrong since otherwise you would be on a more recent kernel version. You try to run as root via SSH the following
    https://github.com/ThomasKaise…ter/overlay/firstrun#L160 followed by apt upgrade and another reboot.


    Then Wi-Fi should work.

    [FAILED] Failed to start Realtek H5 bluetooth support.

    This is save to be ignored and is due to me having built the RPi image with the Tinkerboard image as basis.


    BTW: If the whole update procedure takes longer then 10 seconds you're most probably using an unferior SD card. Switching to an A1 rated SD card is highly recommended.

  • Hello @tkaiser,


    thanks for your awesome work and support.


    I flashed new card, let it run for good 90minutes on wired connection.
    When issuing the command, I got warning that file (and I don't remember it's name anymore) is in use, probably by another process.
    So I waited ~10mins and reran the command sucessfully.
    After it has downloaded, it was installing for ~10 minutes. Then apt upgrade took another ~10minutes.


    I rebooted and nmtui-connect still doesn't report any wifi networks.


    Wlan0 seems to be there:

    Code
    root@raspberrypi:~# nmcli device
    DEVICE           TYPE      STATE         CONNECTION
    enxb827eba8ed93  ethernet  connected     Wired connection 1
    wlan0            wifi      disconnected  --
    lo               loopback  unmanaged     --


    It doesn't detect any wifi though:

    Code
    root@raspberrypi:~# nmcli device wifi  list
    *  SSID  MODE  CHAN  RATE  SIGNAL  BARS  SECURITY


    Just out of curiosity checked the log file, in which firstrun writes and the last line says:

    Code
    ### [firstrun] Skipped swapfile creation since zram is available


    The firstrun job is already disabled. (systemctl status firstrun)


    Any ideas?

  • Isn't the nmcli device wifi list supposed to list available wifi networks?



    BTW: your SD card is really slow, I would replace it with an A1 rated one.

    Yes, I'm currently using old 4GB/class4 Kingston solely to install, update and backup - so my image is as small as possible.
    Once done, I will transfer (restore) the image to 32GB Sandisk Class10 / A1

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!