OMV on NanoPi M4 (w/SATA Hat) - Temperature and Throughput (Issues?)

  • Hello everyone!


    Since I acquired the NanoPi M4 (w/ SATA Hat) recently, I've been running a few tests to determine stability of the system before committing to building a NAS out of it for my use. The information on his forum has been immensely helpful and so I thought of sharing my observations (and questions). So far the board has performed well, but I'm seeing some overheating issues on OMV specifically for operations on USB3 connected drives. The board is equipped with the large block heatsink that comes with it, and the SATA Hat also has a smaller heatsink on the respective chipset. I haven't added any additional fans or modifications (yet). The system runs headless, no HDMI or Keyboard/Mouse are connected - just ethernet (Gig), power (12V connected to SATA Hat) and SSD (see below).


    Here are my observations:

    • Idle temperature hovers around 50°C.
    • When trying to create an EXT4 filesystem on a 480GB SSD (connected via USB3):

      • From the OMV web console, it shows progress for about 5 minutes and then hangs. All http/ssh connections get severed in another 2-3 minutes. During this time the temperature peaks to above 85°C before it stops responding. After the board cools down and starts responding again, the filesystem is not visible in console. Surprisingly, the smaller heatsink over the SATA Hat chipset is also too hot to touch for more than a second (I do not know how to measure it's temperature), though no SATA drives are connected.
      • Exactly same thing happens when trying to create the filesystem with mkfs (over ssh). Peak temperature hits 87°C. System hangs after 5 mins, and http/ssh connections are closed in another 2-3 minutes.
      • Tried creating a fileystem over ssh with mkfs on the FriendlyDesktop OS instead of OMV. Works fine, process is completed within 3 minutes (did not note exact time) and temperature doesn't go over 70°C.
      • Mounted the partition on OMV, created a simple SMB share and ran the HELIOS LanTest, temperature stays at or below 68°C and system remains responsive. Avg. Write speed is 64.09 MB/s, and Avg Read speed is 66.75 MB/s over Gig Ethernet.
    • When trying to create an EXT4 filesystem on a 480GB SSD (connected via SATA Hat):

      • From the OMV console, the process completes in less than 2 minutes. Peak temperature hits 72°C. System remains responsive over both http/ssh. The smaller heatsink over the SATA Hat chipset is hot but not too hot to touch for a few seconds.
      • Process takes 15 seconds when trying to create the filesystem with mkfs (over ssh). Peak temperature hits 58°C. System remains responsive over both http/ssh.
      • Mounted the partition on OMV, created a simple SMB share and ran the HELIOS LanTest, temperature stays at or below 62°C and system remains responsive. Avg. Write speed is 64.33 MB/s, and Avg Read speed is 68.85 MB/s over Gig Ethernet.


    Questions:

    • Any idea why the board runs so hot when creating a filesystem for a USB3 connected SSD on OMV?
    • Are the speeds observed normal? Can they be better?
    • Is there a way to measure the temperature of the SATA Hat chipset?
    • Any suggestions on additional cooling?


    I haven't tried creating a RAID with multiple SATA drives yet, will share the observations when I get a chance to do so.
    Please feel free to ask if you have any questions, or want me to run additional tests. All recommendations / suggestions are welcome.


    Thank you!

  • The thermal pads FriendlyELEC provides are crap. If you want good passive heat dissipation you need to replace them with copper shims and some thermal compound or better performing heatpads.


    When you create an ext4 filesystem with the OMV UI since 3.0.7 'lazyinit' won't be used and as such the creation takes longer. With mkfs in a shell lazyinit will be used and as such large filesystem will be busy for hours.


    With Helios LanTest the settings you choose are important. I would suspect you used 'Gigabit Ethernet' (using 128k block sites) instead of '10 Gigabit Ethernet' (using 1024k block sizes and showing as such +100 MB/s).


    You might want to check cpufreq settings with armbian-config. I started with 2.0/1.5GHz on all the RK3399 devices last year but reverted back to 1.8/1.4GHz on NanoPi M4 and NEO4 after we had a bunch of instability reports. FriendlyELEC's OS images use the conservative 1.8/1.4GHz settings and as such both consumption and temperatures are lower. In case my try to 'fix' this didn't work you need to set 1.8GHz yourself. Run armbianmonitor -m in a shell to get current behavior.

    • Offizieller Beitrag

    Idle temperature hovers around 50°C.

    Mine idles at 33 C. Highest temp I saw when writing to an SSD connected to the sata hat was 41 C. I would guess your heatsink is not seated correctly.

    omv 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • Hi Everyone!


    UPDATE: So, I installed a 20mmx20mmx1.5mm copper shim along with MX-4 thermal compound on both sides of the shim replacing the stock thermal pad. Temperature has improved considerably. However, the issue of system freezing (no, crashing!) while formatting an SSD connected over USB remains.


    Observations:

    • Idle Temperature is now 38-41°C. Also noticed that once the board heats up (see below) it takes considerable time to get back to idle temps, possibly because the large block heatsink is holding onto the heat. Installing a fan is the very last thing I want.
    • Formatting a 480GB SSD connected via SATA takes <1 minute. Temperature hits 43°C, system remains responsive through out the operation.
    • Formatting a 480GB SSD connected via USB from the console runs forever and fails to complete.

      • Attempt 1: SSH becomes unresponsive after about 16 minutes. Console says an error has occured and becomes unresponsive after 19 minutes. Temperature hits 62°C as long as I could measure over SSH. After a while system becomes responsive again, but the filesystem doesn't show up.
      • Attempt 2: Connected to the system via FTDI serial connection and ran htop to see what is going on. htop was showing the temperature go up to 58°C before the board suddenly crashed and rebooted within 9 minutes! The output from the console shows writing inode table 2000/3578 takes only few seconds, but then slows down and the board crashed by the time it reached 2609/3578.
    • htop does show the CPU 1-4 maxing to 1.49GHz and CPU 5/6 maxing to 1.99 GHz, however I could see sustained 100% load only on CPU 5/6 during the format operation.
    • armbianmonitor -m run when idle also shows the CPUs periodically hit 1992/1512MHz.

    Questions:

    • Any idea why formatting an SSD connected over USB is taking so long and crashing the board in the process, while SATA goes through within less than a minute? I no longer think it's due to high temperature as that is at pretty reasonable level now.

    Next Steps:

    • As suggested earlier by @tkaiser will set the CPU freq using armbian-config to 1.8GHz/1.4GHz to see if anything changes wrt crashing.
    • Planning to replace the thermal pad on the SATA Hat chip with a copper shim too, but 20mmx20mm shims that I have are too large. I'll cut/file a thinner one (0.8-1mm) to appropriate size and then try installing it to see if it improves the heat dissipation on it.

    Thanks!

  • Any idea why formatting an SSD connected over USB is taking so long and crashing the board in the process

    Most probably since USB(3) sucks.


    Edit: there's a need to clarify: when you dealt with the SSD on the USB port did you then power the M4 via the SATA HAT or USB-C? If the latter then this is known to be M4's Achilles heel (undervoltage resulting in freezes under load). Since powering via USB-C (not USB PD compliant) is such a sh*t show FriendlyELEC now even sells an own PSU module for the board.

  • Most probably since USB(3) sucks.


    Edit: there's a need to clarify: when you dealt with the SSD on the USB port did you then power the M4 via the SATA HAT or USB-C? If the latter then this is known to be M4's Achilles heel (undervoltage resulting in freezes under load). Since powering via USB-C (not USB PD compliant) is such a sh*t show FriendlyELEC now even sells an own PSU module for the board.

    No, I still used my 12V 5A power supply connected to the SATA Hat - so there is definitely enough juice. I tend to agree with you that may be USB3 implementation on the board sucks. Next thing to try is setting the CPUs to lower freq and test again.


    Btw, I ran the LanTest again (on SATA / Gig Ethernet) with the LanTest Network option set to "Enterprise networks, e.g. 10 Gigabit Ethernet" and the throughput is showing very good with avg speeds at 108.14 MB/s (Read) and 97.72 MB/s (Write).


    EDIT: Question: How to I set the frequency to 1.8/1.4GHz? When I run the armbian-config only options it gives me for CPU speed is minimum (I set it to 600000), maximum (I set it to 1800000) and governor (I set it to ondemand) but I can't find any way to set separate speeds for big.LITTLE processors. Running armbianmonitor -m shows the big.LITTLE hitting 1800/1512 MHz.

    Einmal editiert, zuletzt von vko () aus folgendem Grund: question

  • Couldn't find a way to set specific speeds for big.LITTLE CPU sets separately with armbian-config but found an alternate way:
    cpufreq-set -c0 -u1.42GHz
    cpufreq-set -c1 -u1.42GHz
    cpufreq-set -c2 -u1.42GHz
    cpufreq-set -c3 -u1.42GHz
    cpufreq-set -c4 -u1.80GHz
    cpufreq-set -c5 -u1.80GHz


    Formatting over USB still fails, and the board crashes every time. It's not just a problem on OMV either, it fails almost immediately after running mkfs -t ext4 /dev/sda1 on the FriendlyElec's OS. Following dmesg is displayed continuously xhci-hcd xhci-hcd.11.auto: Ring expansion failed

  • Question: How to I set the frequency to 1.8/1.4GHz?

    Just set it to 1.8 GHz and you're done. Little cores at 1.4GHz or 1.5GHz doesn't change a lot, it's the big cores that make the difference.


    xhci-hcd xhci-hcd.11.auto: Ring expansion failed

    Known 'USB sucks on Linux' problem but this shouldn't occur with my OMV image since https://forum.armbian.com/topi…oherent-pool-memory-size/ -- if this also occurs with the Armbian based OMV image then please report this over at Armbian (I stopped contributing there)

  • if this also occurs with the Armbian based OMV image then please report this over at Armbian (I stopped contributing there)

    Just tested on the Armbian image (4.4.178-rk3399) for Nanopi M4. mkfs -t ext4 /dev/sda1 works successfully for the USB connected SSD in less than a minute (but that could be the lazyinit thing you mentioned earlier). Just to be clear this Armbian image doesn't have OMV on it (yet).


    Questions:

    • Is there a way to format without lazyinit, so I can test how OMV behaves?
    • How do I install OMV on Armbian? I like your image better, as all the optimizations are pre-built, but I hope to get to the bottom of this issue with USB.

    Thanks!

  • Is there a way to format without lazyinit, so I can test how OMV behaves?

    I should've Googled before asking. So I ran mkfs.ext4 -E lazy_itable_init=0,lazy_journal_init=0 /dev/sda1 on Armbian to format the drive without lazyinit, and it partly worked and then failed. It wrote inode tables and created the journal but failed while writing superblocks with error Warning, had trouble writing out superblocks. Took forever till the error, upwards of 45 minutes but the board didn't crash. At least that's one positive development.


    EDIT: I think it re-tried whatever it was doing and the board crashed right after I wrote the above post. At this point, I'm ready to give up on making the USB work. I'll probably have to live with the 4 SATA ports on the hat till a solution is found for USB.

  • Hi @tkaiser - question for you: I decided to install the OMV image on another microSD card. When booting I see the following messages on the serial console. Is this normal for first time boot? It's been over an hour, it's still going. I am able to get to the web console, and system is responding fine there, but I can't do anything on the serial console.


  • At long last, the NAS build is complete. Took a long time, because I needed specific parts and can only work on the project on weekends,but the experience was worth it. Parts used:

    • Nanopi M4 with the block Heatsink and acrylic cover that shipped with it
    • NanoPi M4 SATA Hat
    • 4x 480GB SATA SSDs (setup in RAID 5 configuration in OMV)
    • SATA data cables (angled ones to fit the design) and power cables
    • tkaiser's OMV image installed on a 32GB eMMC module
    • GeeekPi Cluster Case for Raspberry Pi (a few holes drilled by hand on the bottom sheet to mount the NanoPi M4's Heatsink), it fits perfectly and has enough space to add more SBCs in future on top. It also comes with fans for each cluster layer, I mounted one below the block heatsink (not visible).
    • Lots of M3 standoff spacers of various sizes and screws.


    Here is how it looks.


    [Without the drives]


    [With the drives]


    If anyone is interested in more details, please ask and I'll try to answer to the best of my ability. Hope this helps someone else created their NAS build.

    • Offizieller Beitrag

    I have been toying with the idea of a NanoPi M4 with SATA hat, and I have seen on another thread what seemed to indicate the OS can be run from one of the SATA/ssd's.
    1. Have you tried that? If so, how would you go about doing that. (Does somebody out there know if this is doable.) I seem to have read somewhere that running the OS on a SATA drive can be difficult to set up.
    2. Do you have a backup strategy on the emmc's? On my hc2's I dd my micro SC card and make a working backup from that, keeping a few versions back of the images just in case something breaks. Do you do pretty much the same using emmc as a OS drive?
    3. What are you using for your power source? I see in the photo that nothing is plugged in the front so something is plugged into the four-pin plug in the back.


    Thanks for any help

    • Offizieller Beitrag

    A couple of more questions:
    1. What thickness of shim did you wind up using, and what is the dimention needed for the chip?
    2. I noticed above you mentioned using 12v 5amp power supply. I plan to run 3.5" drives so that would not be enough amperage for at least two 3.5" drives. What do yo suggest?

  • I have been toying with the idea of a NanoPi M4 with SATA hat, and I have seen on another thread what seemed to indicate the OS can be run from one of the SATA/ssd's.
    1. Have you tried that? If so, how would you go about doing that. (Does somebody out there know if this is doable.) I seem to have read somewhere that running the OS on a SATA drive can be difficult to set up.
    2. Do you have a backup strategy on the emmc's? On my hc2's I dd my micro SC card and make a working backup from that, keeping a few versions back of the images just in case something breaks. Do you do pretty much the same using emmc as a OS drive?
    3. What are you using for your power source? I see in the photo that nothing is plugged in the front so something is plugged into the four-pin plug in the back.


    Thanks for any help

    1. You can easily do that. Just flash Armbian (don't use buster yet!) to an SD and use armbian-config to move the files to the SSD. Then use armbian-config to install OMV.
    3. Check my post for the power supply.

    • Offizieller Beitrag

    Thanks. I will try that in the next few days.


    In the long run however I’m wondering if my idea of running the OS on an ssd is a waste of a lot of solid state disk space and a good SATA port. I’ve never had a bad experience with an sd card or eMMC. I’ve found that regular backups are the key to reliable OS installs. But I will try it just to see how it goes.

  • It shouldn't be a problem to run it of the SD if you use the flash plugin from OMV. I haven't had a bad experience either. I am also running a few Docker containers on my M4 so a SSD makes more sense. An easier way to power it would be a power brick with a good power rating and the correct barrel jack. Saves you some time compared to my solution.

Jetzt mitmachen!

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