USB networked oranges Pi+2E and Zero

[malvcr]

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.

 

 

[malvcr]

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.

[tkaiser]

I think that the problem is with the electricity source on the Pi+2E.

 

I would try to rule this out first (IIRC there are different current limitations on 2 of the type A ports compared to the vertical one). Also important: good Micro USB cables (AWG rating as low as possible, distance as short as possible) since the normal ones lead to severe voltage drops. We have a couple of reports from Zero users where things are clearly failing due to crappy cables (and I would believe the reason why we don't see this with NanoPi is that FriendlyELEC ships with good cables where Xunlong doesn't).

 

BTW: When I made tests g_ether throughput easily exceeded 120 Mbits/sec, you could use monitoring (it's as easy as 'sudo armbianmonitor -r' to get a full RPi-Monitor installation on each of your boards) to see whether network throughput correlates with cpufreq. And I would recommend using iperf3 for such tests since it shows actual throughput and retransmit numbers every 2 seconds together with a final result.

[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).