malvcr

This is a picture with an R2 located in a RACK assembly.
 

 
The set has an Orange Pi Zero as a "communication/firewall device", together with a Banana Pi M2+ as the Application Server and the Banana Pi R2 (v1) as a Database/NFS/ClamAV server.  I am configuring a Moodle on the machine.
 
As a recommendation from TKaiser in a previous post, the R2 it is managing two 2TB hard disks with BTRFS and not RAID1 (really it is smoother and easier to configure than a software RAID).  The disks power it is provided directly by the 430W power supply (not the R2 power connectors) ... I know this is as a 12 cylinder engine in a Beetle :-) ... The enclosure has 3 fan, so no machine arrive to 50C degrees.
 
It can be improved.  There are details, but in the future things will be better.  In this moment only the power led it is attached to something, and the Power Supply has a wire in the CPU connector to "simulate" something there (if not, the Power Supply will not work).  The machines are located in a presentation cardboard piece painted with temperature resistance silver paint, as no screw post in the enclosure match the SBC machines holes.  They are suspended on the board with metal posts.
 
One if my "nightmares" with this machine has been the internal networking.  Basically the old style ifup-ifdown doesn't work.  Armbian it is a complex thing because it keeps the ifup-ifdown together with the NetworkManager and the SystemD.NetworkD, all at the same time.  So, sometimes you do something but it doesn't work because "the other guy" works against you and you really have no idea what it is happening, and things go wild when working three machines at the same time.
 
At the end, The M2+ and the Zero were configured with NetworkManager and the R2 with SystemD.NetworkD ... in this respect, they are not compatible in the Armbian setup methodology.
 
--
 
The Zero and the M2+ take their power from the R2 (later I will use the Power Supply directly).  I remember when having the legacy 3 kernels and the zero was possible to use the USB cables for networking with the g_ether module.  But I never was able to do this to work well with the 4 series kernels.  In fact, now Armbian comes loaded with the g_serial instead.  Could be interesting to recover that functionality, as this could reduce the complexity with this type of machine combinations.  By now, I am relying in the old friend RG45.
 

This is a picture with an R2 located in a RACK assembly.
 

 
The set has an Orange Pi Zero as a "communication/firewall device", together with a Banana Pi M2+ as the Application Server and the Banana Pi R2 (v1) as a Database/NFS/ClamAV server.  I am configuring a Moodle on the machine.
 
As a recommendation from TKaiser in a previous post, the R2 it is managing two 2TB hard disks with BTRFS and not RAID1 (really it is smoother and easier to configure than a software RAID).  The disks power it is provided directly by the 430W power supply (not the R2 power connectors) ... I know this is as a 12 cylinder engine in a Beetle :-) ... The enclosure has 3 fan, so no machine arrive to 50C degrees.
 
It can be improved.  There are details, but in the future things will be better.  In this moment only the power led it is attached to something, and the Power Supply has a wire in the CPU connector to "simulate" something there (if not, the Power Supply will not work).  The machines are located in a presentation cardboard piece painted with temperature resistance silver paint, as no screw post in the enclosure match the SBC machines holes.  They are suspended on the board with metal posts.
 
One if my "nightmares" with this machine has been the internal networking.  Basically the old style ifup-ifdown doesn't work.  Armbian it is a complex thing because it keeps the ifup-ifdown together with the NetworkManager and the SystemD.NetworkD, all at the same time.  So, sometimes you do something but it doesn't work because "the other guy" works against you and you really have no idea what it is happening, and things go wild when working three machines at the same time.
 
At the end, The M2+ and the Zero were configured with NetworkManager and the R2 with SystemD.NetworkD ... in this respect, they are not compatible in the Armbian setup methodology.
 
--
 
The Zero and the M2+ take their power from the R2 (later I will use the Power Supply directly).  I remember when having the legacy 3 kernels and the zero was possible to use the USB cables for networking with the g_ether module.  But I never was able to do this to work well with the 4 series kernels.  In fact, now Armbian comes loaded with the g_serial instead.  Could be interesting to recover that functionality, as this could reduce the complexity with this type of machine combinations.  By now, I am relying in the old friend RG45.
 

Hi Guidol ...
 
I have been doing a loooot of things as the ones you are describing for years by now.  However, things are becoming more complex and the solutions are not so crystal clear anymore.
 
When working them with the OPI-Zero, latest Armbian version (no problem in legacy ones), to remove the network managers resulted in so unstable environment that I was forced to reinstall the OS.  And ... as Armbian is oriented to NetworkManager, I preferred to learn how to work it.
 
About the R2, what happens is that it is a "work in progress" unsupported device.  So you have no guarantees about what could happen if you break something.  Also, it is more complex that other machines because it has an exotic networking equipment... in those cases, when it works it is better not to try strange things on it unless it is laboratory hardware (I have other machines for that).
 
The specified instructions work for standard Ubuntu on a very regular machine, but not necessarily will work perfectly in a constrained SBC computer where the OS has been fine-tuned to perform well.
 
---
I would prefer if Armbian let me "choose" what networking method I like to use, and in an orderly way disables all other ones.  However, I understand that such thing would involve a lot of work and it is not a priority.
 

i've got second gmac working in 4.19 and with some advice from a DSA-Maintainer, i changed it (back) to mdio_device (johns patch uses platform_device).
 
http://forum.banana-pi.org/t/help-for-testing-4-19-on-r2/7339

First.  Thanks for so great work in the ARMBIAN community.  Any word of gratitude will not be enough.

I have been installing Linux on different SBC.  Some of them are supported by ARMBIAN, others not.  There are some that never will be supported (as the Parallella 16).  And the ARMBIAN process it is very clean for the already refined machines.  However, when trying to bring up some other machine, it is complicated to understand what to do, how and where, as the process have been evolving for a long period of time.

Recently I began to work with @chwe on the BPI-R2, and my first job is to make the nand-sata-install to work.  So, I prepared an image to check this, to study the internal parts of the script and what is the purpose of it.  For my surprise, the script do several things, but it seems to accumulate also old stuff, maybe about previous ways to do certain things.  How to work this without breaking something else?  There, I realized how important is the /etc/armbian-release file, but also the /usr/lib/nand-sata-install directory (for all possible cards, as the ones are not a10 or a20 receive the a20 treatment).  And there is also the /usr/lib/u-boot directory with some operations that could be used in ... I suppose u-boot ..., although I am not sure in what way, as u-boot it is the first thing to run in the machine.
 
As a "reader", my perspective is that the vital system information it is not well organized.  At least it doesn't follow a unified standard, and carry the possibility of side effects as some elements could be located in not well known places.  I still need to make a catalog for all possible system parameter sources, and I figure that I will find some redundant elements in some place.  And redundancy it is not only about saving resources, but about breaking something when not following a referential methodology where any change must be system wide (i.e. universal).
 
Maybe ... and this is the reason for the discussion ... it is important to create a unified system information backbone where all processes in the system can obtain trustworthy information to work with (/proc only works with the kernel stuff).  This could also reduce the complexity of the different processes, as it could provide reusability of some information gathering functions (instead of repeating them in different scripts and or programs).  To install a system in a disk looks similar to reconfigure it in an already installed place or even to query how it have been installed.
 
What is the opinion of people here?  There are related discussions but they seems to be a little lost in time.  I am not really interested in the historical solutions (this can be written in some book), but in the actual problems and how to resolve them correctly.  There is a related thread about naming, although this one is about operating.
 
Thanks
 

First.  Thanks for so great work in the ARMBIAN community.  Any word of gratitude will not be enough.

I have been installing Linux on different SBC.  Some of them are supported by ARMBIAN, others not.  There are some that never will be supported (as the Parallella 16).  And the ARMBIAN process it is very clean for the already refined machines.  However, when trying to bring up some other machine, it is complicated to understand what to do, how and where, as the process have been evolving for a long period of time.

Recently I began to work with @chwe on the BPI-R2, and my first job is to make the nand-sata-install to work.  So, I prepared an image to check this, to study the internal parts of the script and what is the purpose of it.  For my surprise, the script do several things, but it seems to accumulate also old stuff, maybe about previous ways to do certain things.  How to work this without breaking something else?  There, I realized how important is the /etc/armbian-release file, but also the /usr/lib/nand-sata-install directory (for all possible cards, as the ones are not a10 or a20 receive the a20 treatment).  And there is also the /usr/lib/u-boot directory with some operations that could be used in ... I suppose u-boot ..., although I am not sure in what way, as u-boot it is the first thing to run in the machine.
 
As a "reader", my perspective is that the vital system information it is not well organized.  At least it doesn't follow a unified standard, and carry the possibility of side effects as some elements could be located in not well known places.  I still need to make a catalog for all possible system parameter sources, and I figure that I will find some redundant elements in some place.  And redundancy it is not only about saving resources, but about breaking something when not following a referential methodology where any change must be system wide (i.e. universal).
 
Maybe ... and this is the reason for the discussion ... it is important to create a unified system information backbone where all processes in the system can obtain trustworthy information to work with (/proc only works with the kernel stuff).  This could also reduce the complexity of the different processes, as it could provide reusability of some information gathering functions (instead of repeating them in different scripts and or programs).  To install a system in a disk looks similar to reconfigure it in an already installed place or even to query how it have been installed.
 
What is the opinion of people here?  There are related discussions but they seems to be a little lost in time.  I am not really interested in the historical solutions (this can be written in some book), but in the actual problems and how to resolve them correctly.  There is a related thread about naming, although this one is about operating.
 
Thanks
 

Well ... I have a msata connected to the NAS device ... and these are the numbers:
 
Now, with a real mSATA.
root@orangepizero:~# hdparm -Tt /dev/sda1 /dev/sda1: Timing cached reads: 684 MB in 2.00 seconds = 341.73 MB/sec Timing buffered disk reads: 92 MB in 3.02 seconds = 30.47 MB/sec As can be seen .. it is a little slower than the WD Blue hard disk with my custom cable, but so near that can be a comparable speed.
 
The disk is a V-NAND SSD 850 EVO 250GB mSATA from SAMSUNG (i.e. a good device).
 
Now, the two main reasons this setup is a good one:
 
1) No spin-up electricity consumption.  Although not so detailed checking (I don't have better measuring tools), but with a USB power tester, the machine maximum consumption was around 0.80 Amp from start-up, including the hdparm test.
 
2) Look at it (picture bellow) ... no SATA cables, extremely compact.
 
About my configuration:
 
This setup has also a SanDisk Cruzer Fit USB 3.0 8G Disk (the short one on one of the USB ports --- the one is not shared with the mSATA device ---).  This is for the swap and other temporary stuff, so I don't need to degrade the OS SD card by constant rewriting there.  And a 3A power supply.
 
And it is important to add some screws on the mSATA storage card.  When you put it, the card remain at 45 degrees from the NAS device plane, so you must pull it down and keep there with "something" ... in this case, two Nylon screws with a nut between the mSATA and the NAS, and a short standoff bellow.
 
I still need to add a 5V fan and the case, and my setup is ready to go production (with my particular information system there).
 
 
 

Well ... I have a msata connected to the NAS device ... and these are the numbers:
 
Now, with a real mSATA.
root@orangepizero:~# hdparm -Tt /dev/sda1 /dev/sda1: Timing cached reads: 684 MB in 2.00 seconds = 341.73 MB/sec Timing buffered disk reads: 92 MB in 3.02 seconds = 30.47 MB/sec As can be seen .. it is a little slower than the WD Blue hard disk with my custom cable, but so near that can be a comparable speed.
 
The disk is a V-NAND SSD 850 EVO 250GB mSATA from SAMSUNG (i.e. a good device).
 
Now, the two main reasons this setup is a good one:
 
1) No spin-up electricity consumption.  Although not so detailed checking (I don't have better measuring tools), but with a USB power tester, the machine maximum consumption was around 0.80 Amp from start-up, including the hdparm test.
 
2) Look at it (picture bellow) ... no SATA cables, extremely compact.
 
About my configuration:
 
This setup has also a SanDisk Cruzer Fit USB 3.0 8G Disk (the short one on one of the USB ports --- the one is not shared with the mSATA device ---).  This is for the swap and other temporary stuff, so I don't need to degrade the OS SD card by constant rewriting there.  And a 3A power supply.
 
And it is important to add some screws on the mSATA storage card.  When you put it, the card remain at 45 degrees from the NAS device plane, so you must pull it down and keep there with "something" ... in this case, two Nylon screws with a nut between the mSATA and the NAS, and a short standoff bellow.
 
I still need to add a 5V fan and the case, and my setup is ready to go production (with my particular information system there).
 
 
 

It is good to know that the R2 it is being taken seriously.  This machine has important things and, although there are very good alternatives, it has a market place.
 
I have been sending maybe 100 times by now an 825 megabytes ubuntu iso file from one R2 to another and between an R2 and a Mac Mini machine, testing different types of configurations (in the while I am creating the system I will use the R2 for).
 
Here there have some numbers that could be useful:
 
(AES 256 bit):
 
without /dev/crypto
100% CPU max
- real 0m53.189s
- user 0m44.210s
- sys  0m8.030s
 
with /dev/crypto
75% CPU max
- real 0m27.015s
- user 0m2.290s
- sys  0m17.750s
 
Checking at this test alone, it is clear that with the cryptodev driver active (and with the right openssl compiled for it), the machine it is faster processing.  And then it is the top 100% capacity when using only the CPU ... I was trying to figure how to test that remaining 25% ... so, I made a multithread program that received the data (running in a R2), and executed 4 parallel sets of openssl+sending data from the other R2.
 
The "general "throughput" for all the "bundle" gives around 45.8 MB/s.  This is much higher than the around 17 MB/s I can have with only one similar session.
 
The issue here is that the final speed can't be calculated only taking into consideration the crypto engine.  A final test would need software designed for this, because when I cypher with openssl and then send the file on ethernet, I need to "write" the file to disk and to re-read it, and the DISK is a key factor on the overall transmission speed.  An extra write is really heavy here.
 
So, if I like to see a wonderful speed without sacrificing the machine, the disk must speed up.  The final numbers for secure transmission of data must involve all the key factors : CRYPTO+DISK+NET+CPU.
 
But ... in general, I think it is good enough for my purposes.  When I have a better software platform to test all together (without punishing any of the factors), I will come to show my numbers.
 

A38X ClearFog
 
I think I understand now this board.
- It is not an integrated board, but a "carrier" based one.  You purchase the carrier board and the SOM (System on Module) to make it to works as you expect.
It uses only one line for mSATA interface, the same as the R2.  Then, why the difference in speed?
It is necessary to add a mSATA to SATA adaptor to connect standard SATA drives, or to use mSATA drives.  And uBoot must be modified to allow the PCIe slot to work as mSATA.
 
- SolidRun Armada SOM A388 with eMMC : $69
- With ClearFog Base Carrier $129
- With ClearFog Pro Carrier $189
 
HummingBoard Edge
 
Similar scenario than ClearFog (using SOM).
- Only has 1 ethernet
- Quad 1 GHz NXP i.MX6 version 2GB RAM and 8GB eMMC: $191
- Needs M.2 to SATA adapter
- No USB 3.0 (only 2.0)
 
For a multi-ethernet scenario with storage, the HummingBoard is limited by the lack of native multiple RJ45 and USB 2.0 (where the second ethernet could be attached).
When only needing two ethernet, the ClearFog with Base Carrier seems to be enough.  Cost is around 50% higher than the R2.  And the Pro around 100% higher.
 
ROCK64 ... not yet available for purchase (ships until November 3 if purchased in October 16 - Pine has their history on delays)
 
- $60.89 without shipping ( 2GB version + 16 GB eMMC + USB-SATA cable ) ~ still lacks a secondary ethernet.
- It only has one USB3 port, so the bandwidth must be shared between SATA and any secondary ethernet.
 
ExpressoBin
 
- $49 in amazon
- Dual Core
- Three Gigabit Ethernet ports (1 WAN, 2 LAN)
- Independent SATA interface with its own Power Supply
- Proper 12V barrel power connector
- Mini PCIe
- Has the place to add the eMMC but it seems must be soldered there
 
--
R2 still has a place in its price/availability/performance ratio.
 
If there is an ExpressoBin with eMMC included, Quad Core and 2GB, maybe it could cost around $80.  In that case, would be a better option than the R2.
The ROCK64 lacks interfaces to provide good bandwidth when the multi-ethernet scenario is included.
It is not possible to have HummingBoard with multiple Gigabit Ethernet connections.
The Armada SOM is Dual core ... could be possible to use the HummingBoard SOM with the ClearFog carrier?
 
The main important elements are to determine if an improvement in the software can work the problems detected with the R2 for the full performance capacity.
 
In my particular case, although performance has some importance, it is not the main driver to choose one or another product.  The processing unit is more important (hence 4 cores would be better than 2), together with the integrated eMMC (I can't deal with soldering these tiny things) and the availability for connecting devices.
 
Today all them are not so perfect (taking all factors into consideration) options.  I am sure than in 6 months this will be a completely different world.
 

BPI-R2 in Armbian forun has been as a thunderstorm.  It is sad things are not in good terms, as the machine looks nice and I am sure that it could have a nice horizon with Armbian.
 
I am working a security device on these devices (an appliance containing a small network), and by now, this is the best hardware option available:  eMMc, many gigabit ethernet ports (two different networks and, in the future, different VPNs in one of them), USB 3, 2 GB RAM, SATA support, 12V power, GPIO, etc... for less than $100.
 
It is clear that the machine is a new one and it has some problems, but it is possible to deal with them.
 
- Wrong number in the partition configuration when trying to boot from eMMc fix:(http://forum.banana-pi.org/t/cant-boot-from-emmc/3826)
- Have no idea how to turn on a connected FAN in the FAN socket, although the secondary SATA has 5v and 12v and there are the GPIO pins.
- Very long time pressing the power button for the machine to start - optional fix (soldering): (http://forum.banana-pi.org/t/bpi-r2-boot-power-suppy/3647/22)
- Two SATA interfaces in the same SoC line (as a workaround, use a SATA and a USB disk, not two SATA)
- The software distribution from BPI is a mix of things ... there are even parts for Raspberry that I am sure have no relationship with the R2.  Here the grease must be cleaned.
 
There are other details, but I really don't care on them.  The machine form factor it is not really to make an entertainment center, and the only I need is to be able to check the console with the debug pins or to connect through the network.
 
If BPI and MTK could create a server distribution and not the full Mate based Ubuntu, would be very useful.  And there is a LEDE available also, although it is a different point of view.
 
--
P.S. I am waiting for some machines to make a deeper test.  In this moment I have an OPi Zero in the entrance point, so I can't check the total bandwidth ... later I will provide more data, including my own disk throughput tests.

1) The included Android image gives a lot of CPU failures when checking with the TTL cable.

2) When adding an Gigabit Ethernet dongle (in this case a Plugable one ~ ASIX Electronics Corp. AX88179 Gigabit Ethernet), the interface name will something similar to  enx+Mac address.  To replace this a file as the following one must be created:

/etc/udev/rules.d/70-persistent-net.rules

Containing (remember to replace THE_REAL_MAC_ADDRESS for the displayed enx+Mac interface address:
 
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="THE_REAL_MAC_ADDRESS", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

3) When making an apt-get update ; apt-get upgrade, some errors can be displayed ... but it works in general.

Unpacking linux-headers-dev-sun50iw2 (5.31) over (5.27) ...
dpkg: warning: unable to delete old directory '/usr/src/linux-headers-4.11.0-sun50iw2/scripts/mod': Directory not empty
dpkg: warning: unable to delete old directory '/usr/src/linux-headers-4.11.0-sun50iw2/scripts/kconfig': Directory not empty
dpkg: warning: unable to delete old directory '/usr/src/linux-headers-4.11.0-sun50iw2/scripts/basic': Directory not empty
dpkg: warning: unable to delete old directory '/usr/src/linux-headers-4.11.0-sun50iw2/scripts/dtc': Directory not empty
dpkg: warning: unable to delete old directory '/usr/src/linux-headers-4.11.0-sun50iw2/scripts': Directory not empty

Before update:
Linux orangepizeroplus2 4.11.0-sun50iw2 #3 SMP Sun May 14 17:34:53 CEST 2017 aarch64 aarch64 aarch64 GNU/Linux
After update:
Linux orangepizeroplus2 4.11.1-sun50iw2 #17 SMP Thu Jun 15 03:10:38 CEST 2017 aarch64 aarch64 aarch64 GNU/Linux
 
4) Before or after the upgrade, the micro usb port DOES NOT WORK even in host mode.
 
5) After working for a while, the temperature it is normal.  (39 in the H5 machine, with a NAS extension and an USB SSD attached there).
 
6) armbianmonitor really doesn't work (all, but the temperature, it is zero, and CPU frequenncy is ---).

7) The nand-sata-install works well.  No SD is needed after that.

I will check the micro-usb to see what happens.  In the while I will ask for some H3 models of this card.

Just as a reference.
 
I put the machine with the NAS in the bottom part and the Pi on top (it seems to be more reasonable this way), and increased clearance on both sides some millimeters.  It reduced temperature around 2 degrees.
Then, I added a nice aluminum heatsink on top of the CPU ... and it worked with another 3 degrees when the machine was exposed.
And ... remade my LEGO prototype box, with the SSD in the bottom and clear exposed areas at each side of the OPI ... and let the machine working (really doing nothing ... just the rpimonitor on) for one and a half hours around 2:00 p.m. in a tropical country.
 

 
.... the result.  63 celsius degrees ...  very near the security temperature threshold (70).
 
Looking around, I found a bigger (around 4 cm wide) 12V fan ... then I connected it to the SATA electricity connector (it even has the right socket).  As this is under-voltage, it runs slowly and makes almost no noise neither vibration, and the fan area is bigger than the 5V tested before.
 
Now, the temperature is 42 celsius degrees ... around 20 degrees less than without the fan.  As can be seen on the old data (before 8:00), this temperature is a little lower than the one with the small JET fan.
 
What I see is that the OPI is, by itself, a hot machine.  When you add the NAS extension and put everything inside an enclosed box, this doesn't help very much to keep the assembly cold.
 
Another test is to put a much bigger heatsink on the machine, maybe covering all the OPIZ square (this is not a strange solution, the Parallella 16 do that).  But by now, it seems that I really need active cooling.
 
Here is the LEGO (and clones) box with the bigger fan.
 

 
I will check the VDD_CPUX to see how it changes the scenario.

Well ... I have a msata connected to the NAS device ... and these are the numbers:
 
Now, with a real mSATA.
root@orangepizero:~# hdparm -Tt /dev/sda1 /dev/sda1: Timing cached reads: 684 MB in 2.00 seconds = 341.73 MB/sec Timing buffered disk reads: 92 MB in 3.02 seconds = 30.47 MB/sec As can be seen .. it is a little slower than the WD Blue hard disk with my custom cable, but so near that can be a comparable speed.
 
The disk is a V-NAND SSD 850 EVO 250GB mSATA from SAMSUNG (i.e. a good device).
 
Now, the two main reasons this setup is a good one:
 
1) No spin-up electricity consumption.  Although not so detailed checking (I don't have better measuring tools), but with a USB power tester, the machine maximum consumption was around 0.80 Amp from start-up, including the hdparm test.
 
2) Look at it (picture bellow) ... no SATA cables, extremely compact.
 
About my configuration:
 
This setup has also a SanDisk Cruzer Fit USB 3.0 8G Disk (the short one on one of the USB ports --- the one is not shared with the mSATA device ---).  This is for the swap and other temporary stuff, so I don't need to degrade the OS SD card by constant rewriting there.  And a 3A power supply.
 
And it is important to add some screws on the mSATA storage card.  When you put it, the card remain at 45 degrees from the NAS device plane, so you must pull it down and keep there with "something" ... in this case, two Nylon screws with a nut between the mSATA and the NAS, and a short standoff bellow.
 
I still need to add a 5V fan and the case, and my setup is ready to go production (with my particular information system there).
 
 
 

Hi ... I acquired more OPIZ and some NAS (just before they offered the H3 and H5 ... well, next purchase maybe for these machines).
 
When receiving them, I realized the need for the special SATA cable, so I made a small Frankenstein with some old cables I had around (just for primary testing purposes while I have real supported cables).
 
I have an Orange Pi power supply, but attached to a 2E device that I can't turn off right now, so I decided to risk myself a little and to power only the OPIZ (no power to the NAS device).  And both work with a Canakit 2.5A microUSB power adaptor.  The OPIZ powering the NAS worked, at least turning it the tiny green leds.
 
Next test:  To put USB memories on all the USB ports (3 of them) ... and they work well, as 480 Mbps devices.  OK, this means, the power from OPIZ to NAS it is enough, at least for that.  And then, the big test ...
... a WD Blue 500GB 2.5 inch hard drive connected to the NAS.  And ... it works!!  Even together with another USB memory on the same machine.  Without using the NAS dedicated power connector.
 
NOTICE: Before updating the armbian, the hard disk was working as an 1.1 USB device ... painfully slow ... so, update the operating system before testing this.
 
OK ... how fast is this? (after the update)
root@orangepizero:~# hdparm -Tt /dev/sda1 /dev/sda1: Timing cached reads: 686 MB in 2.00 seconds = 342.52 MB/sec Timing buffered disk reads: 74 MB in 3.03 seconds = 24.41 MB/sec root@orangepizero:~# hdparm -Tt /dev/sdb1 /dev/sdb1: Timing cached reads: 684 MB in 2.00 seconds = 342.08 MB/sec Timing buffered disk reads: 94 MB in 3.05 seconds = 30.80 MB/sec root@orangepizero:~# In this case, sda1 is a Lexar 32GB memory stick and sda2 is the WD Blue.
 
Then, the raw speed on the hard disk it is good enough for many purposes.
 
NOTICE: When attaching a USB memory stick on the USB port next to the SATA connector, the SATA disk it is expelled in some way (remains mounted but with i/o errors).  This must be the multiplexed ports that was previously indicated in this post.  Then, I imagine (still doesn't have one of them to test), that the msata will disable the "other" USB port on the NAS card (or the USB will disable the msata devices).  So, be careful when using these ports if there are sata devices connected to the NAS card.
 
A final "initial" test ... to copy with scp from a Mac Mini through ethernet a big file.
 
The average speed it is 10 MB/s this is 80 Mbps (when reducing the ssh and operating system overhead, it is not so bad) .  However, it is clear that the network it is a real bottleneck when observing the raw sata speed.
 
In this case, and with a regular OPIZ - H2+,512MB device, the speed it is good enough for not so demanding backups, some media files and other usages that have a good behavior on 100 Mbps.  OR ... when the OPIZ perform the tasks on the hard disks, as with databases when the 100 mbps it is not in the accessing equation.
 
When I have a msata at hand I will include more numbers.