OMV on rk3328 renegade board has a super slow upload speed!

  • So I built a renegade SCB with a usb 3.0 drive to replace my aging mycloud as a general network file and music server (movies are done on a dedicated plex). No fancy plugins aside from remote mount so I can use rsync to copy the old NAS folders over.


    The whole rsycn job took forever with speeds ~10Mbytes a second despite both devices wired to the same router. Even now when everything is all setup, data saved to it using samba shares is going at an abysmal 5Mbytes a second. Download speeds are zippy and are ~50Mbytes over wifi. What could be causing such a lop sided bottleneck?

  • No one has any ideas? Every other day I poke Google for some answers. Downloads are fast so that means transfer speeds over the usb3 and Ethernet are good, but any file saving is only a near 5-6 megabytes a second. Does not matter if it is ftp, SMB, or rsync (SSH?).

  • ~10Mbytes a second despite both devices wired to the same router

    Gigabit Ethernet uses two cable pairs so if one direction is fast and the other not, try to exchange the cable first (or switch the direction if you don't have another cable yet). Also change the switch port (if your router seems to be GbE capable its network ports are usually provided by a switch and not a hub). Trial&error at the lowest network layer is always the first and cheapest you can do... :)


    Then testing with iperf3 and iozone for both network and storage individually and also testing both combined with Helios LanTest would be a good idea. But do the most primitive stuff (blaming network layer 1 --> cabling) always first.

  • Ok so swapping cables and ports changed nothing. I used iper3 and saw amazing rates between it and the server I ran on my desktop (over wifi, too, yummy speeds). However I drew a loss as to how to use iozone. Mainly I have no idea WHAT it was testing on, and could not find any way to manually select the drive(s) tested.

  • However I drew a loss as to how to use iozone. Mainly I have no idea WHAT it was testing on, and could not find any way to manually select the drive(s) tested

    Given your USB3 attached drive is mounted at e.g. /srv/usb3 you would then do the following:


    Code
    cd /srv/usb3
    iozone -e -I -a -s 100M -r 128k -r 1024k -r 16384k -i 0 -i 1

    And then please provide data and not just subjective stuff like 'yummy speeds' :)


    Since you're running an ARM based OMV install you could provide output from armbianmonitor -u after iozone tests have finished.

  • Code
    cd /srv/usb3
    iozone -e -I -a -s 100M -r 128k -r 1024k -r 16384k -i 0 -i 1

    And then please provide data and not just subjective stuff like 'yummy speeds' :)


    Since you're running an ARM based OMV install you could provide output from armbianmonitor -u after iozone tests have finished.

    Sweet. Ok here is what I got.


    Include fsync in write timing
    O_DIRECT feature enabled
    Auto Mode
    File size set to 102400 kB
    Record Size 128 kB
    Record Size 1024 kB
    Record Size 16384 kB
    Command line used: iozone -e -I -a -s 100M -r 128k -r 1024k -r 16384k -i 0 -i 1
    Output is in kBytes/sec
    Time Resolution = 0.000001 seconds.
    Processor cache size set to 1024 kBytes.
    Processor cache line size set to 32 bytes.
    File stride size set to 17 * record size.
    random random bkwd record stride
    kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread
    102400 128 86273 88004 63384 110842
    102400 1024 92160 91480 71813 116400
    102400 16384 92844 89402 71426 114553


    I tried to use a bigger test file like 100Mbyte but was telling me it can't be larger then the buffer. Not sure why I would really wan't a buffer in a benchmark so maybe you can suggest the proper param? otherwise, disk speeds look spot on and my bottlenecks are elsewhere (my new build I am currently hitting 25-30Mbytes during long sustained transfers).


    EDIT: Ok, network test done. Iperf3 as far is default test show that proper expected 800mbit transfers are happening. File read transfers also do show to stay between 70 and 80mbytes a second. Write speeds are more stable but exhibit the spiral of death. Using a huge 4k video file I started a file upload (omv saving) and it started around 50Mbytes. After 6 minutes i had slowly slowed down to 31Mbytes a second and would still fall, probably until around 25ish (This is what I found when doing my initial file transfers into the NAS).


    So initial start speeds are spot on, there is a spiral going on files received that causes the renegade OMV to just slow down over a period of time.

  • 102400 128 86273 88004 63384 110842
    102400 1024 92160 91480 71813 116400
    102400 16384 92844 89402 71426 114553

    Pretty weird results (since read is a lot slower than reread). Anyway, still not enough information to help. I already asked for armbianmonitor -u output (after iozone test) and it's unclear to me how your whole setup looks like. Which protocol is used, which client OS (important since for example when using SMB between Linux boxes it's pretty easy to make a common mistake at the client resulting in very low performance).


    When providing the information and retesting you could open two other terminal windows and run htop and armbianmonitor -m in parallel to get a clue whether there's a CPU bottleneck (those ARM thingies implement so called cpufreq scaling and if for whatever reasons the CPU cores remain at 408 MHz this will affect NAS performance)

  • Hey! So thats it! Using those tools, I setup testing in mind that I was looking for any throttling. Nothing funny was going on with the clock speeds but the device would start at around 60c and then top out around 72c. It didn't drag the clocks down any but it was clear I was starting the file transfers at around 80Mbytes a second and %50 cpu load, only to have transfers drop to 50mbytes and not even %20 cpu load. htop didnt show anything like low memory or swap issues either. So I dragged a clippy fan to the shelf and pointed it right at the device, cooling it to 46c before starting again (24gig smb file transfer using fast copy). The transfer quickly hit 90Mbytes a second and did not start to drop. CPU load was able to maintain %80~.


    So the renegade board is a bit heavy handed in throttling and if I want to go faster, I will need to update to a solid block aluminum case. ^^

  • Nothing funny was going on with the clock speeds but the device would start at around 60c and then top out around 72c

    60°C in idle is way too much. I would assume we're talking about:

    • board in a tiny enclosure
    • no heatsink
    • no fan

    In case that's true I would suggest using an inexpensive heatsink like shown here (my standard SBC heatsink, you get them for 0.5 bucks on Aliexpress) and removing the board from the enclosure (put it together with the disk in a cabinet for example). Those tiny enclosures act like ovens, no idea why vendors started with this silly attempt.

  • Hi, I wanted to know if your problem has come back?


    Because, i've got the same problem and everything seems to be ok (Cpu Temperature/speed)


    At the beginning everything was great but now i've got slow upload speed for no actual reason

  • Mine did the same. I cooled it, speeds were good, then just the other a day an upload was going pretty slow (9mbit). At that point I scrapped my renegade. Its a failed project. OMV may have many programs you can install on it, but if it can't even do basic NAS reliably (It also locked up, or atleast was no longer connectable until I rebooted) than I cannot be bothered with it. My WD mycloud ran with fast speeds and needed no active cooling. Also working with my files on it is a mess..I copied all the data off through the renegade and ive got read only dir permissions for no god damn reason that windows has a huge problem with fixing.

Jetzt mitmachen!

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