tkaiser

By comparing https://github.com/friendlyarm/linux/blob/sunxi-4.14.y/arch/arm/boot/dts/sun8i-h3-nanopi-duo2.dts and https://github.com/friendlyarm/linux/blob/sunxi-4.14.y/arch/arm/boot/dts/sun8i-h2-plus-nanopi-duo.dts the only real difference is replacing the crappy XR819 Wi-Fi with RTL8189 (the other change being H2+ being replaced by H3)
 
NanoPi Hero also features RTL8189 Wi-Fi, is limited to Fast Ethernet and has an I2C accessible voltage regulator allowing the board to clock at up to 1368 MHz (at 1.4V VDD_CPUX): https://github.com/friendlyarm/linux/blob/sunxi-4.14.y/arch/arm/boot/dts/sun8i-h3-nanopi-hero.dts
 
Maybe @mindee is so kind to provide an early picture of the latter?

There are four M.2 holes designed to mount the heatsink, two close to USB port, and the other two close to the gold fingers :)
 
Actually, we designed the heatsink as the enclosure and same with VIMs heatsink it support to mount a cooling fan on it.
 
the M.2/PCIE is on the bottom of the Captain carrier board.
 
More details will be update on Khadas Webiste soon.
 
Have fun!
 

This is something hopefully suitable to become a 'Board Bring up' thread.
 
The NanoPC T4 was the smallest RK3399 board around featuring full set of interfaces (Rock960 was smaller but there you can't use GbE without a proprietary expander) but in the meantime he got two smaller siblings: NanoPi M4 and the cute NEO4.
 
Pros:
Another RK3399 board so software support is already pretty mature Rich set of interfaces (2 x USB2 without shared bandwidth, 2 x USB3, triple display output and so on) No powering hassles due to 12V (2A) PSU requirement 16GB superfast eMMC 5.1  Usable and performant Wi-Fi (dual band and dual antenna so MIMO can be used, for numbers see here) All 4 PCIe lanes exposed (M.2 M key connector on the bottom, suitable for NVMe SSDs, or to attach a 4 port SATA controller or a PCIe riser card)  
Cons:
A bit pricey (but if you compare with RockPro64 for example and order all Add-Ons you end up with a similar price) High idle consumption (4W PSU included in idle), maybe this is just bad settings we can improve over time heatsink too small for continous loads  
I started relying on @hjc's work since he's currently using different kernels than we use on RockPro64 or ODROID-N1 (though all the 4.4 kernels are more or less just RK's 4.4 LTS branch with some modifications, with mainline I didn't had a look what's different in Heiko's tree and 'true' mainline).
 
Tinymembench numbers with RK 4.4 vs. mainline kernel (the latter both showing lower latency and higher bandwidth).
 
Internal 16 GB eMMC performance:
eMMC / ext4 / iozone random random kB reclen write rewrite read reread read write 102400 4 23400 28554 26356 26143 27061 29546 102400 16 48364 48810 85421 85847 84017 47607 102400 512 48789 49075 273380 275699 258495 47858 102400 1024 48939 49053 290198 291462 270699 48099 102400 16384 48673 49050 295690 295705 294706 48966 1024000 16384 49243 49238 298010 298443 299018 49255 That's what's to be expected with 16 GB and exactly same numbers as I generated on ODROID-N1 with 16 GB size. When checking SD card performance it maxed out at 23.5 MB/s which is an indication that no higher speed modes are enabled (and according to schematics not possible since not able to switch to 1.8V here -- I didn't try to adjust DT like with ODROID-N1 where SDR104 mode is possible which led to some nice speed improvements when using a fast card -- see here and there)
 
Quick USB3 performance test via the USB-3A port:
Rockchip 4.4.132 random random kB reclen write rewrite read reread read write 102400 4 24818 29815 33896 34016 24308 28656 102400 16 79104 90640 107607 108892 80643 89896 102400 512 286583 288045 285021 293431 285016 298604 102400 1024 315033 322207 320545 330923 320888 327650 102400 16384 358314 353818 371869 384292 383404 354743 1024000 16384 378748 381709 383865 384704 384113 381574 mmind 4.17.0-rc6-firefly random random kB reclen write rewrite read reread read write 102400 4 37532 42871 22224 21533 21483 39841 102400 16 86016 104508 87895 87253 84424 102194 102400 512 274257 294262 287394 296589 287757 304003 102400 1024 294051 312527 317703 323938 323353 325371 102400 16384 296354 340272 336480 352221 339591 340985 1024000 16384 367949 189404 328094 330342 328136 139675 This was with an ASM1153 enclosure which shows slightly lower numbers than my usual JMS567 (all currently busy with other stuff). Performance with RK 4.4 kernel as expected, with mainline lower for whatever reasons. I also tried to test with my VIA VL716 enclosure directly attached to the USB-C port but ran into similar issues as with RockPro64 but since my enclosure and the cable also show problems when using at a MacBook Pro I suspect I should blame the hardware here and not USB-C PHY problems with RK3399.
 
This is NanoPC T4 with vendor's heatsink, lying flat on a surface that allows for some airflow below, running cpuburn-a53 on all 6 cores after half an hour:
13:57:31: 1008/1416MHz 8.44 100% 0% 99% 0% 0% 0% 91.1°C 0/5 13:57:40: 1008/1416MHz 8.52 100% 0% 99% 0% 0% 0% 91.1°C 0/5 13:57:48: 1008/1416MHz 8.51 100% 0% 99% 0% 0% 0% 91.1°C 0/5 13:57:57: 1200/1416MHz 8.47 100% 0% 99% 0% 0% 0% 90.6°C 0/5 13:58:05: 1200/1416MHz 8.47 100% 0% 99% 0% 0% 0% 91.1°C 0/5 So with heavy workloads you most probably need a fan to prevent throttling. 
 
Development related questions: IMO we should try to rely on single sources for all the various RK3399 boards that are now available or will be soon. And I would prefer ayufan's since he's somewhat in contact with RK guys and there's a lot of great information/feeback provided by TL Lim. What do others think?
 
Also an issue is IRQ affinity since on boards where PCIe is in use those interrupts should clearly end up on one of the big cores while on other boards USB3 and network IRQs are better candidates. I already talked about this with @Xalius ages ago and most probably the best idea is to switch from static IRQ affinity set at boot by armbian-hardware-optimization to a daemon that analyzes IRQ situation every minute and adopts then dynamically the best strategy.
 
Wrt information for endusers. All RK3399 boards basically behave the same since the relevant stuff is inside the SoC. There's only different DRAM (matters with regard to consumption and performance), different interfaces exposed and different power circuitry (and obviously different settings like e.g. cpufreq behaviour but I think we should consolidate those for all RK3399 boards). So you already find a lot of information in my ODROID-N1 'review', my SBC storage performance overview and most probably also a lot around RockPro64. No idea where to inform about RK3399 GPU/VPU stuff since not interested in these areas at all (hope others add references or direct information).

Ok, thanks for the hint.
 
Oh, since I haven't found one I made a little tool to dump the bootrom from userspace (tested on Armbian for H2+/H3, but should work on other SoCs too). I leave it here, just in case someone wants to play with this stuff 
 

Ok, so it's confirmed:
 
Powering also possible through pins 2 and 4 so since the SoC is at the right side and heat dissipation is no problem @mindee could evaluate a 'SATA HAT' using the 2 PCIe lanes, a Marvell 88SE9235 SATA controller (x2 PCIe to host, 4 x SATA 3.0 to disks) and power circuitry with 12V input able to feed board and 4 x 3.5" disks.
 
If I understood correctly RK3399's VPU capabilities make it interesting as transcoding NAS (once video support is ready in Linux, though no idea how far things are. @JMCC do you know about the state of video transcoding with RK3399?)

@tkaiser I did not forget it. We update ficus to v1.1 adding some requests from customers and now it's out. We will send you the new boards soon after some testing.

Well, then I would prefer to use ODROID design since the NAS case for NEO/NEO2 unfortunately does not attach the SoC to the enclosure to efficiently dissipate heat away.
 
(still waiting for someone designing a RK3399 'NAS board' with a JMS561 attached to each USB3 port to provide 4 SATA ports for spinning rust and a M.2 key M slot for a fast NVMe SSD or alternatively something like this to provide another 4 SATA ports)

This is how I've currently set up my u-boot:
setenv bootcmd 'run boot_armbian' setenv boot_armbian 'run get_images; run set_bootargs; run load_script2; booti $kernel_addr $ramfs_addr $fdt_addr' setenv get_images 'tftpboot $kernel_addr $image_name; tftpboot $ftd_addr $ftd_name; run get_ramfs' setenv get_ramfs 'if test "${ramfs_name}" != "-"; then setenv ramfs_addr 0x8000000; tftpboot $ramfs_addr $ramfs_name; else setenv ramfs_addr -; fi' setenv set_bootargs 'setenv bootargs $console $root ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:none nfsroot=$serverip:$rootpath $extra_params' setenv load_script2 'if test -e mmc 0:1 boot/boot.scr; then echo "... booting from SD-card"; setenv boot_interface mmc; else echo "booting from SATA"; scsi scan; setenv boot_interface scsi; scsi dev 0:1; fi; if test -e $boot_interface 0:1 boot/boot.scr; then ext4load $boot_interface 0:1 0x00800000 boot/boot.scr; source; fi' # A suggested, but untested SATA-boot (try MMC first, then USB, then SATA): setenv load_script3 'if test -e mmc 0:1 boot/boot.scr; then echo "... booting from SD-card"; setenv boot_interface mmc; else usb start; if test -e usb 0:1 boot/boot.scr; then echo "... booting from USB"; setenv boot_interface usb; else echo "booting from SATA"; setenv boot_interface scsi; scsi scan; scsi dev 0:1; fi; fi; if test -e $boot_interface 0:1 boot/boot.scr; then ext4load $boot_interface 0:1 0x00800000 boot/boot.scr; source; fi' There might be typos, because I don't have any copy-and-paste from my serial terminal and in addition, load_script3 has not been tested, so it may contain errors as well.
-But you should get the idea; it's in fact just a tiny addition to armbian's default setup.

I've set up my local EspressoBIN with 18.04 Bionic (Armbian_5.44_Espressobin_Ubuntu_bionic_next_4.14.40.7z).
 
My impression is that it's very much like setting up Xenial and the same issues seem to be present.
I mention them in the order of importance.
1: #reboot sometimes hang, so does #poweroff. It would be great to get this fixed, because it would be a disaster if a device hangs on rebooting from remote (eg. the device is 200km away).
2: sudo apt-get update && sudo apt-get upgrade destroys the network setup. No network access is possible after doing this. I think a fix is important, because people would likely issue those commands.
3: Network seem to be configured slightly different than on Xenial; it seems I cannot configure a static IP on the WAN port (see my other post specifically on static IP). For now, I'll be using a static IP address on the br0, this works, so it's not the highest priority.
 
I definitely also need to write some good stuff.
 
1: 3Gbit JMB321 Port Multipliers work well with Xenial (and likely also Bionic); just remember to connect the boot device to SATA0 and there should be no problems.
2: 6Gbit JMB575 (StarTech) works great with Bionic (and likely also Xenial); again connect the boot device to SATA0.
 
 
For those, who want to boot "directly" from SATA, this is what I do on both boards; it's fairly easy and there are plenty of ways you can do it.
The first time, I just made a 'dd' from my SD-card's partition to my harddisk's partition. This works fine and the partition will be expanded when Armbian boots.
My preferred way, though, is to make a tarball of the unmodified SD-image's partition, boot my EspressoBIN from the SD-card and extract the files onto my desired partition. This gives me a different UUID from the SD-card, thus inserting the Armbian SD card won't confuse my boot-up sequence.
 
To create a tarball, this can be used (mounted as /mnt/sd) ...
cd /mnt/sd && sudo tar -cpzf /data/armbian-bionic-rootfs.tar.gz .
 
To extract onto your partition (mounted as /mnt/rootfs), this can be used ...
cd /mnt/rootfs && sudo tar -xpzf /data/armbian-bionic-rootfs.tar.gz -C .
 
Those will preserve permissions, timestamps and other attributes as necessary, but this will only happen if you're root, otherwise permissions will be messed up and you'll get a half-working system (quite useless).
 
I use a custom UUID on my own setup, so that I only need to set it once in u-boot. I highly recommend using UUID for identifying the boot device, especially is you use a port multiplier, because you never know if a USB-drive suddenly get /dev/sda instead of the drive you expect.
 
In your startup boot sequence, I recommend a 3-stage check ...
1: Check for SD-card (SD/MMC slot)
2: Check for USB-boot
3: Use a 'scsi scan; scsi dev $bootdev:$bootpart;' then check for your SATA-device here.
 
Personally I only have step 1 and 3, since I often mount my SD-card as a USB-drive when I do not want to boot from it.

Buying a fast board to operate it slow is an option? Really?
 
I would cap max frequency of the big cores from 2.0 GHz to 1.8 GHz or maybe 1.6GHz (/etc/default/cpufrequtils) and then check again. The upper DVFS operating points have to use a much higher voltage to get CPU cores working stable so the amount of heat the SoC dissipates at the top clockspeeds is much higher than slightly below.
 
I would prefer a 5% or 10% performance drop instead of running slow all the time.
 
And yeah, the fansink is a joke since not sufficient to provide appropriate cooling. With demanding workloads throttling will always occur (you can't run anything really heavy at 2.0 GHz with the fansink) and the sound is annoying.
 
BTW: To diagnose and optimize behaviour running 'armbianmonitor -m' in a shell is always a good idea.
 
In case the CPU cores run at high clockspeeds with ondemand even when idle this might be another occurence of 'sampling_rate' being inapppropriate with recent kernels.

Well, then I would prefer to use ODROID design since the NAS case for NEO/NEO2 unfortunately does not attach the SoC to the enclosure to efficiently dissipate heat away.
 
(still waiting for someone designing a RK3399 'NAS board' with a JMS561 attached to each USB3 port to provide 4 SATA ports for spinning rust and a M.2 key M slot for a fast NVMe SSD or alternatively something like this to provide another 4 SATA ports)

@tkaiser I had something messing with the GPIO pins, after a good cleaning we're back to the proper function.  I hadn't tried it on the S yet, my early test board would shut down if you tried to power it via GPIO so I was overly suspicious I think.

**UPDATE August 9 2018**
After some messing around I determined I had some sort of contaminant on my Tinker Board GPIO pins interfering with their conductivity.  I have rerun my GPIO powering test and added the results below, there is no additional drop ( @tkaiser, @Frank Wu  I apologize for the bad information)  Other small updates include a possible reason for the small voltage reporting measurement error.
 
After having received an official Tinker Board Power supply, I submit my findings:
 
Test load hardware:  Tinker Board S with internal voltage monitoring
Condition:  No peripherals save mouse/keyboard/small cooling fan to prevent throttling
Load:  minerd --benchmark
Measurement:  For this I diverged from my typical labor-intensive periodic check with a meter and instead allowed the Tinker S to do the work.  It for sure added noise to the measurement, and so some uncertainty, however I think for the purpose here it is sufficient.
The Tinker S reads low when you get to the 5.0V area.  I measured the system voltage at 5.11V using the chassis supply, Tinker reported 5.02, however the values converged as they approached 4.7 Volts.  This is possibly due to the reference voltage for the ADC drifting ever so slightly with or without load.  With the new GPIO information, my meter and the Tinker Board were registering almost exactly the same voltage (within 0.02 volts) during the test, at 5 volts under load.  
As to the supply itself:
      
Laser marked info is a nice touch, molded strain reliefs at the adapter and the plug, rocker switch for power, and 18 AWG wire.
 
Electrical:
5.0 V 3.0 A.  This will be operating near the bottom end of the spec for USB peripherals on the Tinker due to voltage drop. The wire is heavy gauge and is in a "lamp cord" format, the jacket is flexible so I don't foresee too many internal strain breaks in anyone's future while using this supply. Data:

Analysis/Commentary (very loose format):
 
Using a 5.25 V chassis supply with my standard issue 1.5 meter 20 AWG cable that has seen a few hundred mate/unmate cycles for comparison, you can see that the system really needs to see more than 5V at the microUSB connector, and that cable age and wire gauge matter (my cable showed significantly more than 200 mV of drop, the new Tinker Board supply is showing a good bit less (the 4.9+ V spike is an anomaly I am attributing to the sudden release of electrical load)
 
Keeping an eye on the dmesg for indications of my USB peripherals resetting yielded no complaints.  It is experiencing excursions just below the acceptable minimum, so that will be something to look out for.  There is also the simple reality that the Tinker Board is not adequately cooled to pull this sort of current continuously, it goes into thermal throttling within seconds under full CPU load.
 
Recommendations for consumers: 
 
This supply will work, and is at least on par with the other similar units on the market.  The large conductors reduce one of the most common causes of voltage drop, and connector, I assume, is validated to exceed the 1.8 Amp minimum spec requirement for micro USB as per @Frank Wu.  Such a validation provides some insight into the voltage loss, as increased voltage loss results in increased power dissipation at the connector, the thing being actively minimized by such design/test work.
 
Recommendation to ASUS: 
 
If it is at all possible request the supplier increase the output voltage of this supply by 250 mV.  At that point it could be considered the "go-to" supply for anyone wanting to maintain the micro-USB RPi form-factor compatibility. 
 

OrangePi One Plus BSP 4.9, kernel 4.9.56 stock for analisys. 
Here is DRAM initialization in use (hope is what you meant):
[271]PMU: AXP806 [275]set pll start [278]set pll end [279]rtc[0] value = 0x00000000 [282]rtc[1] value = 0x00000000 [285]rtc[2] value = 0x00000000 [288]rtc[3] value = 0x00000000 [292]rtc[4] value = 0x00000000 [295]rtc[5] value = 0x00000000 [298]DRAM VERSION IS V2_5 [300]PMU:Set DDR Vol 1200mV OK. [304]PMU:Set DDR Vol 1200mV OK. [314]BYTE0 GATE ERRO IS = 00000002 [318]BYTE1 GATE ERRO IS = 00000002 [321]BYTE2 GATE ERRO IS = 00000002 [324]BYTE3 GATE ERRO IS = 00000002 [336]DRAM CLK =744 MHZ [338]DRAM Type =7 (3:DDR3,4:DDR4,6:LPDDR2,7:LPDDR3) [343]DRAM zq value: 003b3bfb [350]IPRD=006f006e--PGCR0=00000f5d--PLL=b0003d00 [354]DRAM SIZE =1024 M,para1 = 000030fa,para2 = 04000000 [366]DRAM simple test OK. [369]dram size =1024 tinymembench, running first time with interactive governor:

CPU:
Running subsequent tinymembench with performance governor:
 
CPU:
 
 
Things you should consider in your analysis that could favor some results or not.
 
* axp806 not detected by kernel
[    0.431724] [axp806] chip id not detect 0xff ! [    1.496996] input: axp80x-powerkey as /devices/platform/soc/pmu0/axp80x-powerkey/input/input0 [    4.925539] axp80x_aldo1: unsupportable voltage range: 858992688-3300000uV * eth not functional
[    0.816207] sun50iw6p1-pinctrl pio: expect_func as:gmac0, but muxsel(5) is func:csi0 [    0.824909] sun50iw6p1-pinctrl pio: expect_func as:gmac0, but muxsel(5) is func:mdc0 [    0.833599] sun50iw6p1-pinctrl pio: expect_func as:gmac0, but muxsel(5) is func:mdio0 [    0.843450] gmac-power2: NULL [   11.600421] libphy: gmac0: probed And the usual:
 
 
I am pretty sure it runs at 1.8 GHz:
CPU1 freq      : 1800 MHz  CPU2 freq      : 1800 MHz  CPU3 freq      : 1800 MHz  CPU4 freq      : 1800 MHz  CPU count      : 4   Governor       : performance   SOC Temp       : 55 C  Next time i get results from 3.10...

I am running @Icenowy kernel, 1.5 GHz, 3.10.65 with some minor modification and 4.4.y 4.9.y without ethernet and axp805/6 not recognized .
I will run  tinymembench possibly tomoorow (lack of time)...

BTW (off topic of this post) the NS1068 quirk in kernel cmdline can be dropped now, as it's mainlined by me.
 
NS1066 one should still be kept as I didn't get a quirky NS1066 (my NS1066 just doesn't announce UAS).

@tkaiser Here the link of my latest benchmark of Helios4 : http://ix.io/1jCy
 
I get the following result for OpenSSL speed
OpenSSL results: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-cbc 1280.56k 5053.40k 18249.13k 52605.27k 102288.04k 109390.51k aes-128-cbc 1285.51k 5030.68k 18256.13k 53001.90k 100128.09k 109188.44k aes-192-cbc 1276.82k 4959.19k 18082.22k 51421.53k 96897.71k 103093.59k aes-192-cbc 1290.35k 4961.09k 17777.24k 51629.74k 95647.06k 102596.61k aes-256-cbc 1292.07k 5037.99k 17762.90k 50542.25k 92782.59k 98298.54k aes-256-cbc 1281.35k 5050.94k 17874.77k 49915.90k 93164.89k 98822.83k  
In order to leverage on hw crypto engine, I had no choice but to use OpenSSL 1.1.1 lib (openssl-1.1.1-pre8) and I decided to use cryptodev-linux instead of AF_ALG since it gives me slightly better result (+5-10%).
 
Here a bit of findings regarding OpenSSL engines implementation :
 
As stated in the changelog
Changes between 1.0.2h and 1.1.0 [25 Aug 2016] *) Added the AFALG engine. This is an async capable engine which is able to offload work to the Linux kernel. In this initial version it only supports AES128-CBC. The kernel must be version 4.1.0 or greater. [Catriona Lucey] So using Debian Stretch package OpenSSL 1.1.0f, or any more recent 1.1.0 version, the only cipher supported by AFALG engine was effectively AES-128-CBC
$> openssl engine -c (dynamic) Dynamic engine loading support (afalg) AFALG engine support [AES-128-CBC]  
Starting OpenSSL 1.1.1, even though it is not mentioned anywhere in the changelog, AES192-CBC and AES256-CBC is supported by the AFALG engine
$> openssl engine -c (dynamic) Dynamic engine loading support (afalg) AFALG engine support [AES-128-CBC, AES-192-CBC, AES-256-CBC]  
But one thing much more exiting about OpenSSL 1.1.1 is the following
Changes between 1.1.0h and 1.1.1 [xx XXX xxxx] *) Add devcrypto engine. This has been implemented against cryptodev-linux, then adjusted to work on FreeBSD 8.4 as well. Enable by configuring with 'enable-devcryptoeng'. This is done by default on BSD implementations, as cryptodev.h is assumed to exist on all of them. [Richard Levitte] So now with the 1.1.1 is pretty straight forward to use cryptodev, no need to patch or configure anything in openssl, openssl will detect automatically if module cryptodev is loaded and will offload crypto operation on it if presents.
$> openssl engine -c (devcrypto) /dev/crypto engine [DES-CBC, DES-EDE3-CBC, BF-CBC, AES-128-CBC, AES-192-CBC, AES-256-CBC, AES-128-CTR, AES-192-CTR, AES-256-CTR, AES-128-ECB, AES-192-ECB, AES-256-ECB, CAMELLIA-128-CBC, CAMELLIA-192-CBC, CAMELLIA-256-CBC, MD5, SHA1] (dynamic) Dynamic engine loading support  
Based on those info, and making the assumption that sooner than later openssl 1.1.1 will be available in Debian Stretch (via backports most probably), i think the best approach to add openssl crypto engine support in Armbian is via the cryptodev approach. This way we can support all the ciphers now. I will look how to patch properly dpkg openssl_1.1.0f-3+deb9u2 to activate cryptodev supports. @zador.blood.stained maybe you have a different option on the topic ?
 
 

I would never buy a S912 device. Pretty underwhelming 'performance' especially with single threaded applications that land on the wrong cores and the usual Amlogic cheating: https://github.com/ThomasKaiser/sbc-bench/blob/master/Results.md#the-bigger-picture
 
And if you buy cheap TV boxes it shouldn't be surprising that components inside are also cheap. Same with SSDs BTW

Rock64 (but their eMMC is neither super fast nor would I trust too much into it). Based on your other post the obvious choice is still Rock64 + their SATA cable + a great SSD.

mSATA defines two sizes and both fit. Each JMS578 chip on the expansion board is just like an 'external USB disk' so all the information available talking about USB disks also applies to the situation here. If your Zero has SPI NOR flash and you manage to burn u-boot into it you can load everything else from USB. But this requires you doing some research and is not automated by nand-sata-install (what a stupid name these days).
 
If there's something I would put my swap on it would be the fastest storage available (especially wrt random IO). On those USB2 boards without superfast eMMC that's always an UAS attached SSD.
 
Compare here with there:
Close to 3,000 4K IOPS with a good SSD behind a good USB-to-SATA bridge (like JMS578) behind an Allwinner USB2 port A SanDisk Extreme A1 SD card behind a standard (bottlenecked) DDR50 SDIO controller only scores ~1000/~2500 4K IOPS. It would need a better SDIO interface mode for better performance but that's nothing any of those cheap Allwinner boards provides On boards with super fast eMMC this is also an option. Recent Samsung 5.1 eMMC provides +7000 4K IOPS (see ODROID-N1 numbers -- you have to divide numbers through block size to translate from KB/s to IOPS) If you avoid cheap crap SSDs it's 100% save to use them since unlike SD cards or USB pendrives you can query them about their health and replace them before they finally die. The magic word is SMART: https://forum.openmediavault.org/index.php/Thread/23724-Run-OS-and-database-on-SD-card-to-prevent-HDD-spin-up/?postID=180003#post180003

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

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:
 

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:
 

 
 
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!

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

'1080p video' is resolution but doesn't tell anthing regarding bitrates (depends on encoding/codec used). So you have to check how high bitrate requirements of your media files are. Please note: most people confuse codecs with file/container formats. If you have files lying around with names ending on .mp4 that still doesn't tell anything: https://en.wikipedia.org/wiki/MPEG-4_Part_14#Data_streams
 
The good news: bitrate requirements for most media formats are rather low so even Fast Ethernet should suffice (since this stuff is meant for streaming and the usual encoders are configured to not exceed a specific bitrate anyway -- in case 'the scene' needs higher bitrates than allowed the encoder partially decreases image quality to remain below the bitrate treshold).
 
Fast Ethernet means 8 MB/s at least. With current cpufreq settings in Armbian images actual values might be lower since cpufreq might remain at the lower 240 MHz most of the time. Switching to performance governor might help: http://linux-sunxi.org/Cpufreq#The_.22performance.22_governor
 
But even the 5 MB/s reported by @jimandroidpc should be sufficient for most media files (please remember that there are many Android TV boxes with only Fast Ethernet around and the bitrates that work reliably over crappy 2.4GHz Wi-Fi have to be even lower).
 
I won't comment on RAID used with SBC since I did it too often already. TL;DR: RAID has nothing to do with 'data safety', this is only about availability (business continuity) and people constantly fool themselves with RAID (if you're interested in my opinions a web search for 'tkaiser crap raid availability' or something like that should help).
 
Again: I really hope that Xunlong already prepared a new board with Gigabit Ethernet and Zero form factor since with current Zero the NAS Expansion board seems somewhat strange (the JSM578 is capable of SAT and therefore also SMART, supports TRIM/UNMAP and also UAS which is nice since Allwinner SoCs can make use of UAS even with USB 2.0 when running mainline kernel. Normally you find this feature only on USB3 capable devices). But JMS578's potential is wasted on a board with only Fast Ethernet and crappy Wi-Fi.