Orange Pi Zero NAS Expansion Board with SATA & mSATA

[logjammin]

Excuse my ignorance, but would this board interface with the GPIO pins on a banana pi 1 and work?

 

I see a DC-in on the board, is that just to power the USB and SATA?  I understand the banana pi should not receive power input over GPIO.

[martinayotte]

I don't think so, although I didn't check on the BananaPi-1 schematic, because there are USB pins from SoC (not simple GPIO) that are present on PiZero which doesn't exist on BananaPi-1.

[willmore]

Hello, all.  My second OpiZ came today and brought a friend--a NAS shield.  I posted about it over in the "OpiZ comes to market" thread, but it probably makes more sense to talk about the NAS side of things over here and leave that thread OpiZ related.

 

Just looking at the board gives me the same questions as logjamin about the DC power.  Clearly it makes sense to put a 5V jack on the NAS board as getting power over a micro-USB connector->GPIO header->JST connector->drive is suicidal for your data.  I am curious if the 5V jack on the NAS back feeds the OpiZ.  If so, that removes one of the annoyances of the Z--power over micro-USB.

 

The kit I got came with three each: short male/female standoff, long female/female standoff, wide head screw.  The problem is the flange around the head of the screw is so big that it bumps into the SATA connector right next to it--the other two holes have sufficient clearance.  If they had stuck with using a second M/F standoff like in the picture at the start of this thread, all would have been fine.  Trying to save a penny.....  I clipped a small part of the screw flange off so that it could safely clear the SATA connector.

 

I think I'm going to take the board back off and probe out the GPIO connector to see about the DC power issue.  Surely they wouldn't expect the Z and the NAS to have separate power feeds.  That leads to so many grounding problems, it's not funny.

 

@tkaiser, you've asked this in a couple of threads and no one answered you, so I'll take a swing at it.  Yes, you *could* put USB3 over a GPIO header.  Most PC motherboards with USB3 have a header on them for a set of front pannel USB3 jacks.  So, it is doable.  Now, the spacing of the pins and the arrangement of them is likely to be sensitive and need some though (steal the layout the PC motherboards use ).  So, a higher performing NAS hat could work that way.

 

Heck, I should go look into that in more detail....  It might be as easy as adding the extra SS signals on another row of that connector which could yield a backwards compatable setup--where the new NAS board works on older 1x13 hosts and a 2x13 host can work with the old 1x13 NAS board.  Hey, Steven, you listening?  I'll test them for you?  Of course, we'll need a SoC with USB3.....

 

Okay, that's enough rambling.  I'll go fiddle around with the board and see what I can find out.

[tkaiser]

Yes, you *could* put USB3 over a GPIO header.

 

But not with this Expansion board since it seems (still no schematic available so also still no idea what the 2 USB type A jacks do exactly) SuperSpeed data pairs are not even routed to anywhere (I kept this as a test the whole time since until recently someone else constantly wrote around Zero and this Expansion board yelling 'USB3' without having the slightest idea what he was talking about).

 

Regarding USB front ports connected via cables just do a web search for 'usb front ports unreliable' for example. I had one customer where the admins responsible for the PCs (the minority there, 270 Macs vs 150 PC) put a sticky on every PC they deployed: "Don't use USB front ports, only use those on the back". And a friend of mine who started with SBC recently wrote me after he failed to even boot Armbian and I recommended Etcher (verifying image burning!) that he realized that he can not use an USB3 card reader on his PC's USB3 front ports without corrupted data on SD card while on the back everything was fine. But using an USB2 card reader the front ports seem to be reliable.

 

As usual: Expectations vs. reality. The average user has no clues about cable length, EMI, shielding but expects 5Gbps signaling working flawlessly even under worst case conditions (while it's not that easy, so let's not even think about this NAS Expansion board trying to make use of USB3 SuperSpeed )

 

Edit: Almost forgot: Unshielded USB3 signaling is also great to interfere with 2.4GHz Wi-Fi band: http://uk.pcmag.com/networking-reviews-ratings-comparisons/13179/opinion/wireless-witch-the-truth-about-usb-30-and-wi-fi-interference

[willmore]

@tkaiser:  I had never heard that front pannel USB3 connections could be unreliable.  I have them in three machines and I've used them constantly with no issues.  I need to look into that.  Thanks for the head up.

[tkaiser]

I had never heard that front pannel USB3 connections could be unreliable.

 

I experienced that personally even with USB2. My former Armbian build PC started to corrupt images burnt via the built-in SD card reader (on the front, connected through internal USB2 cable), after I realized that I used an USB card reader on the front port and after wasting again a few hours with broken OS images (not total fails but strange symptoms later) I tried the back ports where this card reader still works flawlessly. I also learned to never ever burn an OS image again without verifying it.

 

USB 3.0 introduced several error handling mechanisms at both the Link and Protocol Layer and due to checksumming retransmits occur if data got corrupted on the wire if the used checksum was good enough (CRC5, CRC16 and CRC32 are used depending on type and size of the packets). With a really fast SSD you might be even able to measure differences between cable connected front and directly conected row USB ports. Anyway: the lesson here is that dealing with 5Gpbs signal rate is not fun without proper shielding and taking all these issues into account. Fortunately this NAS Expansion board is USB2 only

 

So let's focus back on the Expansion board and the areas of interest I already mentioned over there: https://forum.armbian.com/index.php/topic/2808-orange-pi-zero-went-to-the-market/?p=24584

[willmore]

Okay, I took a multimeter to my NAS board.  There isn't conductivity between the host side power and the jack on the board.  There are two diodes in parallel that isolate the NAS board jack from the 5V the host provides.  The diodes are in the direction that the jack *could* supply power back to the host.  The two diodes are Schottky devices, so the voltage drop through them should be fairly low for the currents the Z can pull.  That might be different for an H5 based host.

 

@tkaiser, you probably have better data on that.  My general observation is that the Z uses around half the current of the PC2.

 

I'm going to try powering things on soon.

[willmore]

With no drives attached, it does not show up on the USB bus.  I was wondering how they were going to multilex the two USB slots in there with the SATA.

 

I have no mSATA drives to test the slot with and I'm unsure how to hook up the power to a drive.  I think I'll need to fiddle around a bit before I have an actual SATA drive attached to it.

 

Also, yes, the host is backfed power from the NAS board.

[jkajolin]

frontpanel connectors are usually behind long cables and connected to the motherboards "external usb" connector headers.
backpanel connectors are soldered to the motherboard and overall very reliable.

 

example when doing new os installations to baremetal sometimes the frontpanel connectors just don't seems to be detected fast enough for the boot process to work

if you use mouse or keyboard on the frontpanel those are detected very late on the boot cycle so there a bit lag does not matter

 

the usb key's are not that reliable either they need to formatted from time to time other way they just slow down to non existing speeds

 

@tkaiser:  I had never heard that front pannel USB3 connections could be unreliable.  I have them in three machines and I've used them constantly with no issues.  I need to look into that.  Thanks for the head up.

[tkaiser]

@tkaiser, you probably have better data on that.  My general observation is that the Z uses around half the current of the PC2.

 

Well, on the first pages of the mainly mis-used 'Orange Pi Zero went to the market' thread there were some idle consumption numbers and everything else depends on usage. See difference between idle and 'full load' numbers for H3 here (and keep in mind that Zero default settings are for IoT and therefore low consumption) and add consumption of connected peripherals.

 

My understanding is that powering the NAS Expansion board through the 4/1.7mm barrel plug should provide 3.3V/5V to a connected mSATA disk, 5V to the SATA power port and also the Zero where this voltage is also available at the power pins of the Type A receptacle (without the usual 500mA restriction of USB2 ports on 'real computers' but providing more -- still too lazy to check schematics whether there is some sort of current control or not). Using Xunlong's 5V/3A PSU should suffice to power board, a mSATA SSD and 2 2.5" disks (one connected to SATA + SATA power port, the other via USB).

 

BTW: 3.5" disks with own PSU need just a small/cheap mechanical converter if the SATA port is already used:

 

 

I'm unsure how to hook up the power to a drive

 

There's a SATA power connector on the board and adapter cables exist, eg. https://www.aliexpress.com/item/SATA-Line-for-orange-Pi-Free-shipping/32248261533.html

 

Please be aware that 4 vendors sell these cables but polarity of the 5V lines differs! See https://forum.armbian.com/index.php/topic/3387-nas-on-banana-pi-need-advice-on-power-supply/?p=24467 for details.

 

Edit: Since Xunlong designed the original Banana Pi and used the same SATA connector on the first A20 based Orange Pi i would assume polarity of the SATA power connector to be compatible to the SATA cable kit they sell. But this needs to be confirmed!

[willmore]

@tkaiser, thanks, those links are very useful! Do you have a schematic of the NAS board? I didn't see one last time I was on the wiki. I'd love to look over that!

[tkaiser]

Do you have a schematic of the NAS board?

 

Nope, and usually when I add Xunlong stuff to the wiki it was Igor who got it since he communicates way more frequently with vendors than I do.

 

@Igor: Chinese New Year is over now. Could you please ask Steven to provide schematic for the NAS board?

[tkaiser]

Now there's a 'user manual' available at least explaining power scheme somewhat and the role of the 2 USB type A receptacles: http://www.orangepi.org/download/ORANGE_PI-Zero-NAS-V1_1_user_manual.pdf

 

So using (standards violating A-to-A) USB cables you could connect the NAS board to devices...

[tkaiser]

In the meantime FriendlyELEC provides something similar that is also much worse unfortunately:

 

It's an Expansion Board for their NEOs with DC-DC converter and an enclosure. Looks nice but a few details are awful:

• According to their wiki page the USB-to-SATA bridge used is a JMicron JM20329 (designed for USB2, therefore lacking UAS capabilities. Insane when you think about that Allwinner SoCs with mainline kernel can make use of UAS even on USB2 ports. A JMicron JMS567 or JMS578 would've been a way better choice)
• This enclosure would've be the perfect choice to make use of NEO's design. Due to the SoC placement the enclosure could dissipate the heat to the outside by putting a simple thermal pad between SoC and enclosure. Putting a heatsink on NEO and both into an enclosure looks like a joke.
• On their product page (here or look at the picture above) you see that they talk about H3. Nasty since the H3 based NEO has only Fast Ethernet so it's a pretty bad choice for a NAS. The only NEO suitable for this use case fitting in that enclosure would be H5 based NEO 2. But on the other hand: if you're already bottlenecked by ultra slow network the crappy USB-to-SATA bridge doesn't matter any more.
• FriendlyELEC provides an OMV OS image ('OpenMediaVault' claims to 'make NAS easy', everytime I tried it performance was horribly low since the necessary parameter tuning hasn't been done -- I hope FriendlyELEC looked into this). This OS image is based on kernel 3.4.39! Are you kidding me? Why not mainline kernel for this? There's not a single reason to use a smelly Android kernel with this use case (no display and no audio) and especially not that outdated/unpatched 3.4.39 when there's a community patched 3.4.113 also available.

I'm sure this thing will sell even if it will perform badly. And of course it's better than any Raspberry Pi based NAS but it's really sad that FriendlyELEC starts to target a clueless audience. If there would be a better USB-to-SATA bridge inside this thing combined with NEO 2 running mainline kernel and a custom OMV build that sets parameters correctly would make a great low-end NAS. Unfortunately we're talking about something different here

 

Screenshot showing kernel version used on their OMV build:

 

 

 

 

 

[abramq]

I guess there is no possibility to put NanoPi NEO 2 onto that NAS expansion board?

[tkaiser]

16 minutes ago, abramq said:

I guess there is no possibility to put NanoPi NEO 2 onto that NAS expansion board?

 

Sure can you put NEO 2 onto that board, it's just a different front panel that's needed since for whatever reasons the Ethernet jack on NEO 2 has been moved by a few mm:

The enclosure is even large enough to add a 2nd 2.5" disk so maybe they come up with a different front panel, 2 better USB-to-SATA bridges, 2nd PCB to mount 2nd disk and sell this as 'NAS Box Plus' or something like that. The power design already relying on external 12V could be an indication.

 

Anyway if you want to use a NEO 2 with that box it's time for some 3D printing. And I still hope FriendlyELEC replaces the JMicron bridge with an UASP capable variant since users can add Gigabit Ethernet easily to the normal NEO too by spending another $7 for a simple RTL8153 dongle (performance numbers and information here: https://forum.armbian.com/index.php?/topic/1440-h3-devices-as-nas/)

 

[abramq]

And maybe screw the Nano board screws to the housing, instead using separated heatsink as you mentioned before :-) (a little bit longer pins or socket should be then)

[malvcr]

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.

 

[manuti]

10 hours ago, malvcr said:

When I have a msata at hand I will include more numbers.

 

Nice info, we are expecting more results from you. Thanks for sharing!

[tkaiser]

On 6.4.2017 at 0:40 AM, malvcr said:

Before updating the armbian, the hard disk was working as an 1.1 USB device

 

Well, there is no relationship (though I don't know what went wrong). In the meantime I got also such a board and made some experiences: https://forum.armbian.com/index.php?/topic/3953-preview-generate-omv-images-for-sbc-with-armbian/&do=findComment&comment=29569

 

[malvcr]

6 hours ago, tkaiser said:

Well, there is no relationship (though I don't know what went wrong).

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

[tkaiser]

3 hours ago, malvcr said:

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)

 

No, you just didn't realize that this is asking for troubles and will cause troubles! If it seems to work for you then fine. But please don't spread the word since others will try the same and get data corruption, freezes or crazy symptoms (eg. negotiation of only Full-Speed instead of Hi-Speed at drive spin-up time caused by a huge voltage drop). It really gets annoying to constantly have to explain what a shitty connector Micro USB is (more related to the cables people connect between 'some charger' and the Micro USB port).

 

There's a 4.1/1.7mm power barrel on the NAS board and this combined with a quality 5V/3A PSU is the only way you should try to power Zero + disks if you like reliable operation. Forget about Micro USB in this situation. A great resource of information regarding this problem (that is related to others eg why RPi owners don't trust in SD cards) is the comments section here: http://tech.scargill.net/a-question-of-lifespan/

[malvcr]

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.

 

 

 

 

[malvcr]

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

 

 

 

[tkaiser]

6 hours ago, malvcr said:

it is a little slower than the WD Blue hard disk

 

Nope, using hdparm for 'benchmarks' is just fooling yourself. A 'benchmark' that lasts only 3 seconds is a joke. With hdparm you generate numbers without meaning. It's great to generate data but there's no information. And focusing on sequential reads only is strange anyway (since this is most probably not what you will ever do with your application later?).

 

The 850 EVOs show excellect random write performance so why do you sacrifice an USB3 thumb drive to potentially slow your system down (is it swapping?)

 

BTW: With mainline kernel sequential writes and reads will exceed 37 MB/s (maybe even more after increasing DRAM clockspeed) but I ran into the problem that for whatever reasons the JMS578 controllers on the board weren't detected as UAS capable (which is bad since it affects both sequential and random IO performance especially with SSDs).

[malvcr]

Quote

Nope, using hdparm for 'benchmarks' is just fooling yourself. A 'benchmark' that lasts only 3 seconds is a joke. With hdparm you generate numbers without meaning. It's great to generate data but there's no information. And focusing on sequential reads only is strange anyway (since this is most probably not what you will ever do with your application later?).

 

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 

 

Quote

The 850 EVOs show excellect random write performance so why do you sacrifice an USB3 thumb drive to potentially slow your system down (is it swapping?)

 

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.

 

 

[tkaiser]

Since I figured out how stupid I was (deactivated mainline patches on my old build host) now I was able to build an OMV image for OPi Zero on my new build host: http://kaiser-edv.de/tmp/NumpU8/ (beware that some things are different here, eg. root pwd is 'openmediavault' you'll have to change yourself, no user creation by default and SD card is not resized to full capacity but rootfs stays within 4GB and a 2nd partition will be created behind).

 

For whatever reasons kernel thinks the JMS578 is not UAS capable:

/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 480M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 480M

Also for whatever reasons max cpufreq with the device tree we're using is 1008 MHz but this can be changed:

cd /boot/dtb/
dtc -I dtb -O dts -o sun8i-h2-plus-orangepi-zero-patched.dts sun8i-h2-plus-orangepi-zero.dtb
sed -i 's/0xf6180/0x124f80/' sun8i-h2-plus-orangepi-zero-patched.dts
dtc -I dts -O dtb -o sun8i-h2-plus-orangepi-zero.dtb sun8i-h2-plus-orangepi-zero-patched.dts
reboot

Then it looks like this with onboard JMS578 (no UASP):

                                                              random    random
              kB  reclen    write  rewrite    read    reread    read     write
         1536000       4     9348    10285    10563    10506
         1536000    1024    33435    33455    36695    36684
          102400       4     8268    10512    10633    10502     7997    10421
          102400      16    18041    20989    21252    21265    21309    20667
          102400     512    33688    34081    36589    36661    36716    34085
          102400    1024    34866    35043    36879    37148    36823    34953
          102400   16384    35275    36786    37369    37604    37586    36634

And now with JMS567 (UAS):

                                                              random    random
              kB  reclen    write  rewrite    read    reread    read     write
         1536000       4     7959     9802     9835     9843
         1536000    1024    36134    36207    40032    40020
          102400       4     7913    10273    10628    10565     7992    10332
          102400      16    21075    24388    21700    21628    18273    23406
          102400     512    34742    33692    39484    39663    39339    33151
          102400    1024    36976    37078    39965    40336    40163    37056
          102400   16384    36224    37784    41031    41083    41052    37668

I used 'ionice -c1 iozone -I -a -g 1500m -s 1500m -i 0 -i 1 -r 4K -r 1024K' and 'ionice -c1 iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2'. The 1500m settings to use 3 times more test size as DRAM available to verify the quick test with 100MB is also reliable and the '-I' switch to ensure that not just RAM is tested (as in your examples above with '-s 400m' that fit nicely into memory).

 

So obviously there's something missing to get JMS578 recognized as UAS capable and JMS567 is slower when it's about small block sizes.

 

Wrt swapping: Does it really happen? You can use the OMV image above that contains all latest and greatest Armbian features eg. better reporting, just watch the end of http://sprunge.us/ICGF or search for 'swap' in the logs (or inspect the output from 'free' command or use 'armbianmonitor -d sda' on this image to get real write activity at the block level for sda, something I implemented just recently to get an idea how efficient log2ram/folder2ram are in reality)

 

And then SSD vs. USB thumb drives: Do you have any endurance ratings seen for USB thumb drives? Are you able to query the thumb drive's controller? With an SSD all this is possible, simply check the relevant SMART attributes (they differ by vendors). Some good reading:

• https://superuser.com/questions/1037644/samsung-ssd-wear-leveling-count-meaning
• http://ssdendurancetest.com/ssd-endurance-test-report/Samsung-840-EVO-120

[malvcr]

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.

 

[tkaiser]

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   

[malvcr]

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.