malvcr

Members
  • Content count

    15
  • Joined

  • Last visited

About malvcr

  • Rank
    Member

Recent Profile Visitors

24 profile views
  1. I think that this information is important in the NAS environment, because I am not testing the OPIZ alone but attached to the NAS extension together with an mSATA storage device, a combination that more people than me will try with the OPIZ. OK ... let's see what I did ... First, I tweak the DRAM speed to 132 MHz ... then try one of the iozone tests ... although the machine gave me SSH access, after one hour without any iozone result, I stopped it (Ctrl-C). Then, I worked it at 300 MHz with "normal" results: ionice -c1 iozone -I -a -g 1500m -s 1500m -i 0 -i 1 -r 4K -r 1024K random random kB reclen write rewrite read reread read write 1536000 4 6432 6454 6383 6383 1536000 1024 35951 36170 36640 36632 ionice -c1 iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 random random kB reclen write rewrite read reread read write 102400 4 6353 6396 6357 6371 6367 6435 102400 16 17944 18064 18162 18196 18074 18032 102400 512 33952 34276 35159 35470 35425 34116 102400 1024 34747 34513 35979 36055 35984 34755 102400 16384 37208 37661 37465 37689 37734 37341 There are some differences with your numbers ... could be because I still have the swap on the USB Thumb drive (I am trying not to change many variables together). And this is the corresponding diagram: Before 9:00 I had the fan. Then the machine increase temperature until around 9:30 ... around 11:00 I have a peak at 62 celsius degrees (more or less when I quit the iozone test). As can be seen the temperature was bellow 60 degrees until around 15:00 when I put again the fan and a quick temperature reduction can be observed. The DRAM speed change works but if I reduce it very much, there are some type of instability that even makes the CPU to work harder; as can be seen, after the 62 degrees peak, the same iozone test made the CPU to work, but not so much. I need to check the dissipator paste (right now it is using the factory glue for new dissipators). I had some Artic CPU paste with me but right know I don't know where I put it, so I need to purchase some. When I have it I will repeat the test without the fan.
  2. 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.
  3. Swapping is the opposite of 'sequential' writing so your benchmark is still wrong :) And both fan and USB thumb drive are the wrong hardware to address the problems you face :) Swap Yeah ... the swap it is not sequentially used. It depends on what memory area are you using. That test only declared that the SanDisk Fit it is slower on writing. iozone -O -i 0 -i 1 -i 2 -e -+n -r 4K -s 2000m random random kB reclen write rewrite read reread read write 2048000 4 1010 0 8057 0 802 438 Compare it with the EVO random random kB reclen write rewrite read reread read write 2048000 4 8635 0 8013 0 1341 2165 The random read it is not so terrible ... the write ... mmmmm .... On my first system test I was using some file management primitives that worked all involved files in memory. This was a clear mistake that used all the computer virtual memory (i.e. swapping) and even crashed on big files. Then I took the memory size into consideration and made my own primitives that work on controlled-size segments, partial hash computing, etc. In this case, the memory usage it is under control, although I use more CPU. However, in my current prototyping version I am using a language that has automatic memory management and I have no 100% guarantee that the memory will be released immediately when I stop using it (this will change in further versions created with C and C++). So ... with a big quantity of small objects (tents of thousands) I still could use more than the base 512MB the OPIZ has in a short period of time. And this can happen, because I am working with source code files and version control systems that make a lot of tiny files from the source code. Also, the system has a web control interface that "also" uses memory. But it works well, just I need to have every detail into consideration. I even have been working this on a Raspberry Pi Zero (WD Node Zero), with an even smaller footprint than the OPIZ+NAS device, including very limited data bandwidth. Do I really need the swap? ... I will check it on heavy usage. Is the USB Thumb the best option? ... is it a good option? ... let me check with care and to put all factors in the balance. If this is not needed I will very very happy to quit it ... but also to quit the swap and to run on only RAM (swap in the EVO disk or the SD card are no options). Fan The fan ... each minute pass I realize this was not a good idea ... - noise, a lot of it - the machine doesn't have enough basic circuitry to control it (working 100% all the time), and if I try to add it, will become more complex and will lost sense. - extra electricity consumption, even when it is not needed - vibration that, eventually, could carry other problems - moving parts in a solid state device (including the storage). I am eating the golden eggs chicken. - more complex housing and wiring But the machine is hot even idling (240 MHz). However I noticed some details I will explore more. - the computer "natural" layout is horizontal, limiting how the air pass through it because by nature, the hot air go up and the NAS is a roof. When I put it vertically, it reduces temperature some degrees because it has a more natural way to cold down (partially using the principle Apple is using in their circular workstation). Together with a passive heatsink correctly oriented on the hot chips. - I will turn off WIFI and other subsystems I am not using (to reduce consumption -- hence temperature -- I understood your point in another thread). - the machine it is very sensitive to external temperature. I will try to keep internal temperature constant with an intelligent case, not just a box. - deactivating any Linux service it is not necessary. Maybe - Limiting highest CPU clock (not to arrive to limits). 1.0 GHz it is still fast enough. In general, to control limit conditions. - Controlling program loops, not to go (while(true){}) cases. Let's make the best with this tiny machine :-) .... And thanks for the guide and doubts ... I am trying to be open minded. If something is wrong, need to be resolved.
  4. I am downloading the OMV software ... let me try it these days. About endurance ratings for USB thumb drives, I remember to read something related but I don't remember where. I have been looking around for more data on the particular stick I am using (SanDisk Cruzer Fit 8G), but I still have no very detailed data. I know that for "bad USB" it is possible to have some tools to query about the flash microcontroller, but I am a little hesitant to run Russian low level software from an unknown source on a Windows machine :-) Without being very exhaustive, however, it is clear that this (USB 2.0 --- my mistake in a previous post) stick doesn't have a stellar performance on the writing phase: iozone -a -g 4000m -s 400m -i 0 -i 1 -r 4K kB reclen write rewrite read reread 409600 4 4898 5015 32269 32664 819200 4 4689 4583 32402 32385 1638400 4 4265 4294 32238 32248 3276800 4 4137 4147 32137 32138 Why this stick in particular? 1) ... why a USB stick? ... it is simple. It works. I have some Raspberry Pi machines with sticks running for around three years by now without any issue. They are Lexar 32GB. And they even have a mysql database there. 2) ... why not the Lexar? ... it is very big. I needed something small. And SanDisk is a very good brand. 3) ... why that model? ... I have been reading a lot of reviews. The main reason for having this was "reliability", not speed (anyway, for a USB 2.0 port I can't ask for so much). For example, the Fit Ultra models with USB 3.0 capacity overheat very often and even can stop operating, so they were automatically discarded from my "menu" of options. The Fit (without the Ultra), seems to be a very good option. 4) ... but it has low write speed. Yes. If you need that speed, this is not a good option. But if what I am looking is for something that can manage a "possible" swapping (that could not happen so often), in some particular conditions, I really don't care about the speed. The important is to make the work. And yes, will be faster on the EVO 850 but not if I am also reading and writing in the EVO at the same time that I am swapping, everything on the same USB bus (30+4 it is faster than 30). And really, if could exist a situation where the swapping will be constant, I prefer to burn a thumb Disk (replaceable in minutes without data lost) and not the SSD device (critical). However, we are learning many things about these small devices. Thanks for so much clues. I will complete and deliver my solution, but I will also monitor it carefully. On the run I will detect real enterprise-level usage conditions to make the appropriate adjustments. And if something is important to share I will write about it. Note: in this moment what I am fighting is with temperature. I have a small 5V fan connected to the SATA power source (where I don't have any SATA disk connected) in a temporary LEGO made box (to simulate enclosing) ... it reduces around 15 celsius degrees but makes a terrible noise is making me crazy.
  5. OK ... I remade some tests you suggested me in some previous post about USB bridges. They are performed with the native 1.2 GHz CPU speed and with 0.96 GHz speed. echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor iozone -a -g 4000m -s 400m -i 0 -i 1 -r 4K kB reclen write rewrite read reread 409600 4 44513 44710 33810 33877 819200 4 39321 39389 33811 33765 1638400 4 37320 36728 33568 33577 3276800 4 36094 35789 33567 33504 iozone -a -g 4000m -s 400m -i 0 -i 1 -r 1024K kB reclen write rewrite read reread 409600 1024 43676 43873 32540 32425 819200 1024 38948 38999 32455 32445 1638400 1024 36959 36812 32293 32122 3276800 1024 35803 35464 32204 32041 iozone -O -i 0 -i 1 -i 2 -e -+n -r 4K -s 2000m random random kB reclen write rewrite read reread read write 2048000 4 8788 0 8441 0 1439 2654 Now ... limiting the CPU speed ... echo 960000 >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq iozone -a -g 4000m -s 400m -i 0 -i 1 -r 4K kB reclen write rewrite read reread 409600 4 39426 41018 32133 32165 819200 4 38615 38702 32202 32119 1638400 4 36568 36454 32061 31985 3276800 4 35466 35281 31864 31786 iozone -a -g 4000m -s 400m -i 0 -i 1 -r 1024K kB reclen write rewrite read reread 409600 1024 42544 42910 31770 31848 819200 1024 38392 38339 31682 31685 1638400 1024 36314 36223 31606 31590 3276800 1024 35108 34901 31442 31414 root@orangepizero:~/x# iozone -O -i 0 -i 1 -i 2 -e -+n -r 4K -s 2000m random random kB reclen write rewrite read reread read write 2048000 4 8635 0 8013 0 1341 2165 The problem is not about the random write performance with the 850 EVO. The system will run there is an automated secure backup system that will process a lot of encrypting and compacting from several SAMBA, SSH, GIT sources, so it is very probable that the 512MB of RAM on the Orange Pi Zero won't be enough to run and will start swapping. And I prefer not to burn the EVO with the swapping to provide better reliability on the data storage device for several years (this is a security solution that must be trustworthy on the data storage part). Then, reliability on the long run it is paramount, but not so much the speed. If with the time, and because of swapping, the USB flash memory is damaged, it is something very easy to replace ... no permanent data stored there. However, I am not sure why it must be slow as I am not sharing the USB bandwidth as I would do if I put the data "and" the swap file in the same device connected to the same USB port (in this case, the Orange is working these devices with different USB bus 04 vs 03). This is similar to have more than one hard disks in different SATA controllers where a database has access to one disk and the swap is located in a different disk. /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=sunxi-ehci/1p, 480M |__ Port 1: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 480M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=sunxi-ehci/1p, 480M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 480M And this is the main reason to use an Orange Pi Zero with a NAS extension than to use a Raspberry Pi machine. Yes, the mSATA is fast :-) ... and with an independent Ethernet, this must work very well. I can't test the UAS thing because I need the mainline and there is no stable mainline kernel for the Zero machine (I need to work with stable versions for this particular product). And I will remade the WD Blue Disk tests, but with original Orange Pi cables that are still in the mail.
  6. 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).
  7. Hi tkaiser. Good reference on scargill ... What I see, in general, is the following: 1) SBC computers (as the Raspberry or the Orange machines) are usually created to work at 5V and to be used in a myriad of different conditions. And some of them were built with micro USB 5V electricity connectors because of the smartphone already available custom to recharge them with such ports (SBC and smartphones are cousins). 2) BUT, there is a combination of negative issues doing that, in particular because the micro USB 2.0 (the small one) was not created to work with more than 500 mA, and because there are many different types of USB cables around, some of them incapable to deliver more than 500 mA reliably because they were not designed for that. 3) When adding more responsibility to the (Power Supply/micro USB connector/USB cable) trio, and not having a guarantee for success on whatever of the parts, the troubles are at the door. One of them is the possibility for data corruption in the used storage devices, in particular those that depend also on the same power supply through the SBC where they are connected (typical problem for writing on SD cards). Although this was a common issue on the first Raspberry Pi generation, it was worked with some changes on software and hardware, but not definitively eradicated... again, it depends on working conditions and general requirements. SO 1) It is not possible to use any SBC for any solution. They are small and they have limitations that must be correctly understood and addressed. For example, the Raspberry Pi 3 has better WIFI than the Orange Pi Zero, but the Orange Pi Zero works better the USB bandwidth than the Raspberry Pi 3. 2) When needing to use a higher than usual quantity of electricity (for example when connecting a hard disk to the SBC), and there is more than one option for doing that, it is IMPORTANT to use the best option for the work. In the case of the Orange NAS together with an Orange Pi Zero, although the assembly works with the micro USB connection, the barrel in the Orange NAS is the right connector to use because it has been designed to power that set of devices in a more trustworthy way. AND, the right power cable and power supply devices must be used (because there are low power capacity 4.1/1.7mm cables and power supplies around). For example, this power supply with barrel 4.1/1.7mm adaptor will be, for sure, troublesome (http://www.navilock.de/produkte/G_41382/merkmale.html?setLanguage=en). Could be interesting to assemble some type of matrix with what resources are better to resolve this or that requirement. I am still waiting for some devices for testing (they arrived on holidays to my courier company) ... when having more practical data at hand I can work a first version of that. P.S. Yes, the "spin-up" period of time is critical because of the high electricity requirement.
  8. I really didn't use more time on that issue, just updated the OS because I needed to continue with my tests. And this only happened before the updating (who knows, maybe a side effect in something else). The data about your experiences is very useful. About to use a msata device, in my case it is really a useful measure because of the "size" factor. The Orange Pi Zero together with the NAS card and the msata provide a very compact combination without strange external cables around. You know, not always performance is "the" key factor :-) ... oh yes, and the NAS with the OPIZ and an external sata hard disk works well powering it from the OPIZ micro USB port from a 2.5 Amps 5V power supply (designed for a Raspberry Pi 2).
  9. 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.
  10. 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).
  11. 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.
  12. 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.
  13. 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 :-)
  14. 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 ... ).
  15. 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.