Notice: Function register_block_script_handle was called incorrectly. The asset file for the "editorScript" defined in "contact-form-7/contact-form-selector" block definition is missing. Please see Debugging in WordPress for more information. (This message was added in version 5.5.0.) in /home/vol9_8/ on line 5835
Orange Pi Mini 2 Disk Performance – Rajib's Blog Rajib's Blog

Orange Pi Mini 2 Disk Performance

Orange Pi Mini 2 Board with a coin for heat-sink

Orange Pi Mini 2 Board with a coin for heat-sink

The Orange Pi Mini 2 (OPi) is a more powerful alternative to the Raspberry Pi 2 B. It features a faster processor and Ethernet that has it’s own bus to the CPU. Due to this, the USB bus is not un-necessasarily loaded with network traffic and storage devices connected to the USB bus can perform to the maximum as per USB 2.0 specifications. Since I intend to use the OPi primarily as a single-user NAS server, I ran a bunch of disk read-write tests on USB Pen-Drives to check disk-performance of the OPi and tabulated the results.

The findings are eclectic and revealing.


  • lshw indicated that all the four USB ports of the OPi are connected to the same USB Hub.
  • Every write was redirected to a new file and no files were over-written.
  • Every operation resulted in the CPU frequency scaling up-to 1.5 GHz, resulting in the OPi running very hot. However, the OPi did not shut-down or get burned out. All tests were done with the OPi exposed to ambient air and a few coins stacked on-top the CPU to absorb some of the heat (as in photo).

Read-Write Performance on USB Pen-Drives

For this test, I used two pen drives;

  • Sandisk 8 GB Class 4 USB 2.0 Pen-drive formatted as FAT32 partition having block-size of 32 KB
  • Sandisk 16 GB Class 10 USB 3.0 Pen-drive formatted as FAT32 partition having block-size of 32 KB

All tests were performed using dd command and timed using time command. A typical command that wrote a 102.4 MB file using 32 KB blocks filled with random-number data looked like:

dd if=/dev/urandom of=/media/orangepi/usbdrive/out-32768.txt bs=32768 count=3125 conv=fsync

  • the urandom device generated a random number ensuring that each data-unit was unique and no internal data-compression algorithms would be effective
  • conv=fsync forced a buffer flush ensuring that background disk-writes were ineffective and the time calculated would be realistic.


  • Impact of Block Size: Block-sizes below 4 KB were slower (512, 1024, 2048 bytes). Optimum performance for the 16 GB Pen-drive was achieved with block-size of 16 KB and optimum performance for the 8 GB Pen-drive was achieved with block-size of 8 KB.
    • It appears that the combination of urandom and fsync slowed writes down dramatically. The 16 GB drive achieved a maximum of write-speed of 2.2 MB/sec and the 8 GB drive achieved a maximum write-speed of 2.1 MB/sec.
  • Virtual to Physical File Transfer (Pure Write Speed): Files were generated on the 16 GB Pen-drive, using dd if=/dev/urandom of=/media/orangepi/usbdrive/out-32768.txt bs=32768 count=6000 conv=fsync.
    • Using /dev/urandom and conv=fsync parameters, the write-speed reported as 1.9 MB/sec.
    • Removing the conv parameter actually reported a lower write-speed of 1.8 MB/sec.
    • Replacing /dev/urandom with /dev/zero improved write-speed to 14.5 MB/sec, indicating the reduction in the overhead created by the random number generator.
    • Keeping /dev/zero parameter and removing the conv parameter reported a marginally higher write-speed of 15.5 MB/sec.
  • Physical to Virtual File Transfer (Pure Read Speed): A 1 GB file was generated on the 16 GB pen-drive using dd if=/dev/urandom of=/media/orangepi/16GB-USB3/out1048576a.txt bs=1048576 count=1000 conv=fsync command. This file was used as the input file (if=/media/orangepi/16GB-USB3/out1048576a.txt) and output file was set to /dev/null (of=/dev/null) for pure USB read-speed tests.
    • By keeping the command-line parameters of bs, count and conv intact, a read-speed of 34 MB/sec was observed.
    • By removing the conv=fsync parameter, a read-speed of 33.7 MB/sec was observed.
    • By removing all additional parameters (block-size defaults to 512 Bytes), a read-speed of 35.5 MB/sec was observed.
    • The cp command resulted in a read-speed of 35.17 MB/sec.
  • Physical to Physical File Transfer (Real World Read-Write Speed): A file was generated on the 8 GB pen-drive using urandom and fsync with bs=32768 and count=6000 (196.6 MB file, write-speed = 2.1 MB/sec). This file was copied to the 16 GB pen-drive.
    • Using dd command with the conv=fsync parameter, the write-speed reported was 12.4 MB/sec
    • The dd command without the conv parameter resulted in a write-speed of 13.53 MB/sec
    • The simple cp command performed faster with a write-speed of 14.68 MB/sec

Major Issue Faced

I could not take up testing using bus-powered USB External Portable HDDs. For some reason, the HDD which appeared to work perfectly (albeit very slowly) yesterday, refused to even get detected today and HDD noises indicated issue with insufficient power being supplied by the USB bus.

The HDD was not detected even when I removed all other devices connected to the USB ports to see if the situation improved.


  • The USB 2.0 bus on the OPi performs well and it is capable of reaching it’s theoretical maximum speed of 480 Mbps (approximately 48 MB/sec), if paired with input/output devices whose capability exceeds the specifications of USB 2.0.
  • Actual USB read-speeds are more than sufficient for two simultaneous streams of Blue-ray quality videos over the in-built 10/100 Mbps Ethernet. In-fact, the bottle-neck here is the Ethernet port.
  • Actual write-speeds are almost entirely dependent on the capability of the physical device.
  • I will be taking up throughput testing of USB External HDDs later on. Meanwhile, I strongly recommend that you use a Powered USB-Hub if you want to connect bus-powered Portable HDDs to the OPi board.

You may also like...

1 Response

  1. xeros says:

    Thanks for test. It’s quite hard to find proper benchmarks for such boards for taking decision to buy or not to buy for own purpose requirements.
    I looked for some board to run Linux for NAS as main purpose + some Linux server stuff and I was looking for OPi (mostly for cheapest OPi PC), but these boards seem to suffer having built-in USB HUB that could have problems with power to external devices & throughput when few devices do some I/O on USB.
    I was hoping that these H3-based OPi boards would be sufficient, but looks like I will have to buy “good old” A20-based Banana Pi Pro / M1+
    The only limitation is that A20 is dual-core clocked at 1GHz so running more things could be bottleneck (especially if I would consider it to use as a desktop alternative also).
    I’ve read that A20-based BPi’s Pro are able to use even disks which were not working with other boards (including more power demanding 3TB disks connected to SATA) and getting read disk performance up to more than 200MB/s on SSD & 950MBps throughput on built-in Gigabit Ethernet.
    But I’ll also buy heat-sinks for main components (and maybe find some cooler) to overclock it to at least 1.2GHz (at normal clock speeds they don’t seem to overheat).

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.