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

    • OMV 4.x
    • Resolved

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • 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?
    • JeffMD wrote:

      ~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.
    • JeffMD wrote:

      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:

      Source Code

      1. cd /srv/usb3
      2. 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.
    • tkaiser wrote:

      Source Code

      1. cd /srv/usb3
      2. 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.

      The post was edited 2 times, last by JeffMD ().

    • JeffMD wrote:

      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. ^^
    • JeffMD wrote:

      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.
    • New

      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.
    • Users Online 1

      1 Guest