malvcr

That limitation on the two type A ports is an important detail. I have been using a good quality ANKER 30 cm USB cable, but I will check more carefully these details. What I think is that I had the wrong approach on this. One thing is to have ethernet USB based networking, and the other one is to be able of "safely" to power on three OPIZ machines from only one Pi+2E having only the Pi+2E power supply shared on all the resulting four machines. In this case it is not stable enough to be a practical solution. Then, if I like to produce such type of networking, I need to find a different method to power the computers to resolve that particular issue. I have been using the RPi-Monitor extensively after your recommendation. It is particularly useful when trying to understand how all these machines "heat" when they are working, an extra factor that always need to be addressed. Could be very interesting is some of these makers create a machine with many powered USB ports. Using OPIZ machines you could create an interesting type of cluster with such configuration (the alternative is just to add Ethernet dongles).

Today I was testing further my micro-usb-network, and I was very happy making three parallel transferences at 8.2 MB/s from the Pi+2E to each one of the OPIZ machines (this is 196.8 Mbps combined and without using the native Ethernet capacity) ... 18% CPU, 67 degrees max on the Pi+2E (with a passive dissipator) .... 1296 MHz (the machine is limited to that speed) ... until the first machine finished the transference. Then, the other two machines were, literally, frozen (in the exact moment the first one finished). After that, the surviving machine it is still working. I need to investigate with more detail what happened, but I think that the problem is with the electricity source on the Pi+2E. i will report my findings here after checking more.

After receiving several Orange Pi Zeros and a Pi+2E, I have been experiment on different ways to connect them using the g_ether and usbnet modules, and configuring the Zero OTG port as slave (mode 2). My last attempt was to use the Pi+2E as a data concentrator, connecting three different OPIZ on the independent USB channels, creating ethernet over USB links ... this have been my week's nightmare. By now these are my findings (could change with more information at hand). 1) The Pi+2E enables 4 different usb ports. The usb0 is the OTG microUSB port, and the usb1, usb2 and usb3 are the other exposed type A USB ports. 2) The usb0 has a particular MAC Address and all the other usb ports (1,2 and 3) share the same MAC Address. 3) Was impossible to have a reliable connection (with more than one OPIZ connected) when configuring the USB ports on different networks. 4) Was necessary to define a bridge on the three usb ports (1,2 and 3) to enable all the three OPIZ to see the Pi+2E (before that, "sometimes" one worked other times another one ... I was never capable to figure why or how). 5) When the bridge is on, everything works as a charm. 6) If one of the usb0 ports (in the OPIZ side) is disabled and re-enabled, the corresponding usbX port in the Pi+2E is separated from the bridge (disappear). And continue without working until the usbX por is re-added to the bridge manually on the Pi+2E side (brctl addif br0 usb0, when adding the usb0 to the bridge br0). 7) Oh yes ... I added hard disks on two of the OPIZ. When using PiDrives, have been necessary to provide external power with the WD special cable. With a SanDisk Z400s SSD this was not necessary. By now I have not been successful on enabling a dhcp server for the bridge on the Pi+2E side, although with static addresses everything work. The other thing I have no idea how to do is to automatically re-add some usb port that have been enabled by connecting something on the other side ... I have been thinking on creating a small daemon that pools on the bridge, but by now it is only an idea. I expect this to be of help for others, and any additional information will be welcomed. P.S. By the way, when connecting one Zero with another Zero from an OTG in one machine to the Type A in the other machine, everything is perfect. It is possible to add a PiDrive if the machine receiving electricity is the one with the drive. The other one will work well with the electricity offered by the OTG connector.

I have several usages in mind: 1) Small laboratory, to check different sort of things (much more flexible and cheap than with standard x86 machines, and even virtual machines). 2) Security enabled storage (in the works). 3) Enterprise grade - small distributed system (in the works). 4) Catastrophe management distributed system (by now I am collecting requirements and checking what the machine can do in that environment). That type of things :-)

Hi tkaiser To run these tests takes some time :-) I was reading the previous post about the PiDrive ... 10 MB/s it is not real. I have two sets of numbers here taken from a fresh PiDrive on a recently installed Orange Pi Zero and an SSD (Kernel 3 series, so I can't check the UASP right now ... although I will do it these days because it is important). According with my previous tests, these numbers (10 MB/s) are more for a Raspberry Pi with its inherent bottleneck, not for an Orange Pi, or because some network was in between. My guess is that the machine is the problem, not the disk neither its integrated circuits. About the second set of tests ... they are interesting because they belong to a SanDisk Z400s SSD with LUKS on an INITIO INIC 1618 based USB 2.0 Seagate bridge (I need to retest this without LUKS, but it seems that the bridge I am using for that it is "terrible" ... I don't think the SSD is the responsible for the slow numbers). And, in this case, the integrated Orange Pi card looks to be a wonderful idea. Also, while making the tests I was trying to replace the USB-SATA bridge with another one on the Z400s, but it reported a different geometry to Linux, making the LUKS to fail. In this case, to have USB hard disks it is nice, because the hardware combination it is married and that problem won't exist. For me both, the Xunlong and the WD solutions are good ones, maybe for different types of solutions (not all problems are nails neither the tools to resolve them are hammers). About the RAID discussion. I could use RAID (whatever number) inside a critical expensive centralized system, but for so small machines, I think it is much better to use DRDB. I can have two completely independent computing systems making automatic physical level backup between them ... IF ... the quantity of data it is reasonable, because they would need to work with USB 2.0. To put so many redundant systems INSIDE so small machines doesn't look to be a good idea; anyway, the external disk must be USB, so you can chain the machines using also USB and hence the difference in speed doesn't need to be so abysmal. And using these NAS expansion boards seems interesting, because you can have two semi-integrated storage nodes, one being a backup from the other one... but again, for data moving at USB 2.0 speed needs (small files, sensor data, not so heavy used databases ... ).

This is my first post here ... Recently I acquired some OPIZ, and I have been working with them for having cyphered storage. As my first attempt was using Raspberry Pi Zero machines, to jump to OPIZ machines was an improvement ( around 20 times the total speed ). Of course that when using the Fast Ethernet we have a clear bottleneck, but it depends on the usage. Also, it is possible to use g_ether (Ethernet over USB and to move more to the USB 2.0 limit that it is clearly higher than the Fast Ethernet one). In my case I have been linking two OPIZ with USB reprogramming the OTG to work as a client (mode 2), so one of them has a web server and the other a database and a cyphered database located in an USB hard disk. For that I am using Wester Digital PiDrives, that are native USB disks. However, could be useful to have more storage options, and I think that the mentioned expansion board is a good solution because it opens possibilities. One obvious advantage is to eliminate many cables that can make your life complicated. Not everything is about a lot of data in very short periods of time. There are plenty of cases where USB 2.0 based storage is more thank enough, and as the OPIZ H2+ inherits the separated channels for all its USB 2.0 ports from the H3 chip, it is really a very powerful contender in its league. Of course than to have USB 3.0 "separated" channels would be wonderful, but I think this moves the line to the next machine level we can work with if we need to do so. Oh, I prefer not to have internal hubs or switches in these small machines (as the Raspberry do) ... to be confident on the total bandwidth. I think this is the main cause of the dramatic performance difference between the Raspberry Pi Zero and the Orange Pi Zero.