infinity

Hi,
i have seen some interest in the ASM1351 Sata to USB3.1 Gen2 controller, and as i have a USB 3.1 case with this controller i did some power consumption tests.
In this case a HGST Travelstar 5K1000 1TB 2,5" HDD is mounted.
Test where done with a headless RaspberryPi 3 (only power supply and the tested USB device connected),  a KD302 wall power meter (measuring the complete power including the power supply) and a Drok USB 3.0 power meter (measuring only the power consumed by the USB device).
"delta KD302" means the difference between headless Raspberry and the Raspberry with this USB device.
USB3_BRDIGE is the empty case, without the HDD; only the  bridge PCB
USB3_HDD  is the complete case, bridge PCB + HDD
 
                                                   KD302       |   delta KD302   |    Drok
---------------------------------------------------------------------------------
Power Supply idle                     :  0.2W                                
RaspPi3                                     :  1.8W                              
RaspPi3 + USB3_BRDIGE           :  2.35W      |    0.55W           |    0.34W
RaspPi3 + USB3_HDD                :  2.75W      |    0.95W           |    0.67W
 
The differences between the delta of the KD302 and the values of the Drok result probably mainly from the effeciency of the power supply (~70% ?).
Also some extra power consumption of the Raspberry when a USB device is connected or the precision of the power meter could have a influence.
 
So it seems that the ASM1351 have a lower idle power consumption compared the JMS578 and maybe also show better performance.

No idea. I tried the script on ODROID-XU4 and Banana Pi and it always fails in the same situation: 
hdparm --fallocate $whatever file always returns with 'File too large' regardless of the size. Since the very same happens on the Banana Pi also when the SSD is connected via SATA maybe it's just a bug in hdparm v9.43 (that's the version Jessie and Stretch use, had no time to test with Ubuntu yet)

Hmm... not really since this should happen at the driver layer. He uses a script describing 'We need a very modern hdparm, for its --fallocate and --trim-sector-ranges-stdin flags' which is interesting since I'll try TRIM with my JMS578 then soon  

Well, with SuperSpeed I doubt there will be any real differences since 5 Gbps with 8b10b encoding means USB bottelenecking here with ~400MB/s maximum. And if the host is SuperSpeed Plus capable (10 Gbps with 128b132b encoding) then the SATA 3.0 controller on the other side of the chip will be the bottleneck (6 Gbps with 8b10b encoding --> ~480 MB/s max, no idea how/why benchmarks show up to 520 MB/s here). Though there might be differences wrt random IO but honestly: if I need high random IOPS then eliminating the USB bottleneck is a better idea.
 
These numbers here show that 'native SATA' provided by Marvell SoCs outperforms any USB3 solution easily especially wrt random IO (and I doubt ASM1351 will make a real difference here). BTW: same test with an EspressoBin shows only slightly lower numbers than the Clearfog from my link.
 
 
Is needed at both ends of the USB cable (and AFAIK it's still missing in Linux for USB)
 

I bought two of them just to realize that they're based on crappy Norelsys chips (the reason why Armbian in the meantime does UAS blacklisting on its own -- the same happens on ayufan OS images for ROCK64 though there it's done differently). The JMS578 ORICO thingie looks different: http://www.orico.cc/goods.php?id=6355
 
Please read through this carefully again. The guy has one JMS567 and there's something wrong with it (queue size limited to 14 for whatever reasons). When comparing ASM1153 and JMS567/JMS578 they perform both pretty identical (JMS578 should be able to support TRIM but AFAIK there's still software support missing in Linux)

No idea. I've one ASM1153E here but never measured consumption (only pretty unprecise and then I didn't notice differences to JMS567 or JMS578). Since the basic problem is always one USB3 SuperSpeed PHY and one SATA 3.0 PHY being active I also doubt that there are real power savings possible,
 
Though for JMicron SATA bridges we learned recently that there exists the possibility to update/modify the firmware so maybe there are some tweaks possible. While I'm currently in direct contact with JMicron (issue here) I don't want to ask these questions now since waiting for firmware fixes that provide full SAT compliance for JMS567/JMS578.

Got some nice feedback from JMicron explaining firmware versions.
0.1.x is for self-powered SATA HDD/SSD device 0.2.x is for bus-powered SATA HDD/SSD device  0.4.x is for self-powered SATA HDD/SSD/ODD device application (ODD --> optical disk) $higher-number.x means custom firmware (enclosure maker) I only asked for the firmware revisions of a couple of devices I've access to so not all possible variations are listed above (eg. 0.3.x or 0.5.x could mean 'bus-powered HDD/SSD/ODD device). But at least this explains a lot already.
 
When comparing 0.1.0.5 on ODROID HC1 and 0.4.0.5 with ROCK64 SATA cable the firmware revision (x.x.0.5) is the same while the ROCK64 cable firmware should also deal with optical drives. And the 0.2.x firmware being meant for bus-powered vs. self-powered suddenly explains the different behaviour I observed wrt JMS chip being present on the USB bus or not depending on whether there's a SATA drive connected or not (different consumption in different modes).
 
Anyway that needs some more understanding and testing but at least we don't need to be concerned about one JMS578 device (ODROID HC1) having a horribly outdated firmware 0.1.0.5 while ROCK64 SATA cable has a way higher (0.4.0.5) since FW revision is actually the same.
 
JMicron is still busy testing with a newer firmware revision solving the HDD spindown issues, once I get news or something to test I'll update this thread.

The above thing is a $10 accessory that can be ordered together with ROCK64 (and maybe other Pine Inc. devices like Pine64 or Pinebook?). It's an USB-to-SATA bridge (JMicron JMS578 based) to be used together with 2.5" SSD/HDD or 3.5" HDD. For the latter purpose it's equipped with a separate power jack suitable for the usual 12V 5.5/2.1mm power barrels (centre positive) you find PSUs with literally everywhere.
 
TL;DR: If you want to add storage to your ROCK64 order this cable too. It works great with both 2.5" and 3.5" disks and it's somewhat sad it's not available separately since it's a great storage companion for many other devices too.
 
Basics first:
Mechanical quality of USB jack is excellent, Pine folks took care that the jack fits really tightly in USB receptacles so USB3 contact issues should not be an issue here (tested on ODROID-XU4 which is my worst device in this regard. The Pine adapter worked great and these pretty nice XU4 USB3 storage performance numbers were produced with Pine's adapter) The device is not really black but it's just a very dark but translucent plastic. If it's connected to an USB port and thereby powered a solid blue led is shining through. Disk activity is shown with a blinking red led in parallel. If you hate blinking leds like me turning the device 180° over is sufficient JMS578 as USB-to-SATA bridge is an excellent choice since amazingly fast, 'USB Attached SCSI' capable, same with 'SCSI / ATA translation' and even TRIM (though software support for this still missing in Linux) When combined with 2.5" disks the whole power consumption happens through the USB cable. Keep in mind that USB2 ports are rated for 500mA and USB3 ports for 900mA max. ROCK64 AFAIK allows 650mA on the USB2 ports and 950 mA on the USB3 ports. In other words: chances are great to run in underpowering problems when you connect 2.5" disks to the USB2 ports and run heavy loads on it (see below). 3.5" HDDs need not only 5V but also 12V. Usually the motor spinning the platters is on the 12V rail while internal electronics and the stepper motors to move around the head(s) are on the 5V rail. Please always keep in mind that Pine's SATA cable unlike any 'real' 3.5" HDD disk enclosure uses the separately provided 12V only to feed pins 13-15 on the SATA power connector. 5V consumption for the JMS578 and the disk's 5V rail has still to be provided by the device the SATA cable is connected to since coming from the USB power lines. On 'real' disk enclosures the 12V are internally also used to generate the 5V so an external disk is NOT powered in any way by the connected host. With this cable it's different!  
Below is the standard SATA power connector pinout. 3.3V are usually not used, 12V are needed for 3.5" HDDs and 5V are always required. The JMS578 bridge chip needs some 5V juice too which is also taken from the connected host/board via USB power lines.
 

 
We already have a lot of performance numbers with fast SSDs connected to JMS578 (see https://forum.armbian.com/index.php?/topic/1925-some-storage-benchmarks-on-sbcs/&do=findComment&comment=34192 or there for example) so let's focus on real-world use cases this time: A large 3.5" HDD connected to a ROCK64 serving as a NAS or backup disk.
 
Let's start with some consumption numbers with an idle ROCK64. In the meantime I've 3 different ROCK64 generations on my desk (1st dev sample with 2GB and unusable USB3, 2nd gen dev sample with 4 GB and now a production board with 1 GB DRAM and a different Gigabit Ethernet PHY). Measurements done without PSU taken into account:
 
Pre-production board, 4GB, RTL8211E PHY:
Idle, Fast Ethernet active, nothing connected: 1100mW Idle, GbE active, nothing connected: 1430mW   
Production board, 1GB, RTL8211F PHY:
Idle, Fast Ethernet active, nothing connected: 1180mW Idle, GbE active, nothing connected: 1300mW Idle, GbE active, JMS578 connected: 1720mW Idle, GbE active, JMS578 with sleeping disk: 2850mW With RTL8211E PHY the difference between GbE and Fast Ethernet was 330mW (on most GbE boards with 8211E it's exactly like this: ~350mW) and now with RTL8211F the difference is just 120mW (difference on ODROID-C2 which also uses 8211F is 230mW). When adding the JMS578 cable w/o connected disk consumption increases by 400mW. In this (rather useless) mode the JMS578 hides itself on the USB bus (lsusb output shows nothing -- interestingly on ODROID HC1 which also relies on JMS578 this is different) and obviously JMS578's USB and SATA PHYs are powered off. As soon as a disk is connected but sent to sleep JMS578 now consumes +1.5W and appears on the USB bus (now JMS578 has to power 2 highspeed PHYs: USB3 and SATA 3.0).
 
So with production ROCK64 boards minimal idle consumption is 1.2W (PSU's own consumption excluded). But as soon as we connect this cable with a disk behind idle consumption more than doubles (+1550mW) even if we send the disk to sleep. That's bad news for use cases that require a connected disk only running from time to time since now the JMS578 consumes more energy than the board itself.
 
Edit: I discovered recently that the HDD I was testing with has a rather high standby/sleep consumption so the +1550mW are not JMS578 alone but maybe even largely the Seagate Barracuda. See here for details but keep in mind that while on ODROID HC2 also a JMS578 is used it runs a different firmware which influences idle consumption behaviour a lot. More details on JMS578 firmwares: https://forum.armbian.com/topic/3317-orange-pi-zero-nas-expansion-board-with-sata-msata/?do=findComment&comment=43735
 
What are the options? With ROCK64 production boards we're fortunately able to toggle power provided to USB ports: https://forum.pine64.org/showthread.php?tid=5001
 
So the SATA cable connected to an USB2 port would allow to regain lowest idle consumption since we could unmount the disk when not needed, then send the disk to sleep using 'hdparm -y' (JMS578 fully supports 'SCSI / ATA translation so you can access every disk feature with hdparm or other low level tools!) and finally switch JMS578 off by cutting power on  the USB2 port. My personal use case is a ROCK64 with a huge 3.5" HDD to backup various macOS devices in the household. Backup performance is close to irrelevant and the only events needing top 'NAS performance' would be large restores or 'desaster recovery'. In other words: for normal backup operation once a day it would be sufficient to connect the disk to an USB2 port.  Nope, doesn't work any more, see below for details.
 
How does performance look like with a 7.2k 3.5" HDD (Seagate Barracuda from a few years ago):
 
The Barracuda is totally empty so able to achieve nice maximum sequential performance scores since testing only on the outer tracks (~170 MB/s):
USB3 / UAS (7.9W vs. 3.3W) random random kB reclen write rewrite read reread read write 102400 4 11738 23147 25131 25087 1091 948 102400 16 62218 77830 84257 84768 4246 4136 102400 512 150052 148303 154342 163817 58563 97809 102400 1024 148290 148324 156772 164963 85125 113412 102400 16384 149840 149248 144297 151440 153146 133806 1024000 16384 167750 169544 172970 174205 160859 151406 When connected to an USB2 port performance drops a lot (maxing out at ~37MB/s):
USB2 / UAS (6.4W vs. 3.3W) random random kB reclen write rewrite read reread read write 102400 4 7735 7849 6821 7925 998 916 102400 16 17687 19040 20793 19430 3624 4096 102400 512 33472 33662 33738 34329 26020 33683 102400 1024 33836 34030 34855 35505 29941 28791 102400 16384 34294 34373 35599 36694 36174 33714 1024000 16384 33600 34516 36576 36902 36372 34111  
I tested backing up the same MacBook Air twice with ~70 GB data using Gigabit Ethernet (the usual Thunderbolt Ethernet adapter) and time difference was negligible comparing HDD connected to USB2 or USB3. When backing up through Wi-Fi there is no difference any more since Wi-Fi is the bottleneck. In other words: from a performance point of view for this use case connecting the SATA cable to an USB2 port and being able to totally cut power to both cable/JMS578 (+1.5W consumption) and a sleeping 3.5" disk (less than 0.1W consumption with almost all disks) is worth the efforts.
 
Once your MacBook gets stolen you simply disconnect the backup HDD from the USB2 and reattach it to an USB3 port and start the restore on your new device with +80 MB/s (Gigabit Ethernet now being the bottleneck) 
 
What about power requirements? ROCK64 only provides up to 650 mA on the USB2 ports! I tried to test this precisely with my usual 'monitoring PSU' approach. All I was getting were some nice kernel panics due to UNDERPOWERING. The Banana Pro I used to provide power (and measure consumption) simply does not provide enough current so Linux on ROCK64 started to fail in many funny ways once USB accesses happened.
 
So I had to revert on measuring with PSU included with a cheap powermeter (more realistic but not that precise).
 
When measuring only the 12V rail of my 3.5" Barracuda the disk consumed up to 18W when spinning up. In normal operation (either idle or with any workload) 12V consumption varied between 6W and 8W (12V only needed to spin the platters).
 
The 5V power requirements for JMS578 + 3.5" HDD disk were as follows:
USB2: 6.4W vs. 3.3W (full load vs. idle). Numbers with 5V PSU included so we're talking about needed power provided on an USB2 port of approximately ~3W which fits perfectly in the power budget of ROCK64's USB2: 650mA * 5V == 3250mW USB3: 7.9W vs. 3.3W (full load vs. idle). Numbers again with 5V PSU included so we're talking about needed power provided on an USB3 port of approximately ~4W which fits perfectly in the power budget of ROCK64's USB3: 950mA * 5V == 4750mW  
At least with my 3.5" HDD it worked pretty well to let it operate on both USB2 and USB3 ports when board powering was appropriate (with insufficient powering all weird sorts of issues popped up. My favourite was a kernel panic when issueing 'lsusb' after 30 seconds. Once I powered ROCK64 reliably all these 'software issues' were gone immediately -- again and again: insufficient powering is one of the most severe problem sources)

Getting back to development related news - basic Rock64 support was added to the mainline tree starting with 4.14-rc1: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts?h=v4.14-rc1&id=955bebde057e71b6f29b97b78c027efdd596e62d

I just booted a mainline kernel on my Rock64 (4.12-rc7 with defconfig, rest was from ayufan's minimal xenial image) and that seems to work ok.  Currently investigating a problem with the GMAC0 not finding the PHY, so no network at the moment, but USB2 seems to work, USB3, video and audio drivers are not there yet...
 
Boot log: http://pastebin.ubuntu.com/25206030/
 
I guess I will try 4.12.4, 4.13-rc2 and rockchip-next as well...

Since I would believe this eMMC connector isn't made for much matings I prefer to leave the eMMC where it is. Then there are three opportunities:
Use a male-to-male USB cable, get the device into MaskRom mode (google --> 'maskrom site:armbian.com') and flash the eMMC directly from a host device Burn an image to SD card, boot ROCK64 from SD card and then use whatever mechanism to either overwrite the eMMC with a complete OS image or use later Armbian's nand-sata-install to transfer the installation from SD card to eMMC When community+RK got an universal bootloader working and Pine Inc starts to flash this to the SPI NOR flash on the board a guided installation routine will eventually be possible that fetches an OS of choice from the Internet or locally and then overwrites the eMMC with this (device specific bootloader remaining on the SPI NOR flash, OS image being device agnostic). Not yet ready and I doubt we're talking here about 2017 too With my testings so far I had a hard time getting ROCK64 to throttle with normal workloads and the currently implemented DVFS OPP table (maxing out at 1296 MHz). This might look differently when we add more DVFS OPP to reach the advertised 1.5GHz (since then Vcore voltage has also to be increased and then throttling is more likely to occur). You should also keep in mind that ODROID-C2 has a better GPU than ROCK64 and Hardkernel folks in the beginning thought they would deal with a 2.0GHz SoC here (just to discover later that Amlogic's blobs simply reported wrong cpufreq and limited max cpufreq to 1.5GHz anyway).
 
So the heatsink on C2 is both slight overkill but also sufficient to not run into throttling situations there unless you use really stupid small enclosures. On ROCK64 I tested with my usual el cheapo $0.5 heatsink and this was responsible for maybe ~5°C less and throttling jumping in later (I used cpuburn-a53 which is the most heavy CPU load I currently know of for A53 cores). Putting ROCK64 in an upright position allowing the PCB bottom to receive some airflow instead of placing it on a pillow had a similar effect. I would believe most of the heat gets dissipated into the PCB below the SoC already.
 

I either use the eMMC adapter that came with one of my ODROIDs or write to the eMMC from a sdcard image. There is also a flash tool from RK that uses USB-OTG via USB A-to-A cable... As for heatsinks, I mounted a small 14x14x14mm sink since I build a lot on my Rock64 and that keeps it from throttling with all four cores running at 1.3Ghz. The RK3328 is implemented with 28nm node, not sure what S905 uses?
 
http://www.fischerelektronik.de/web_fischer/en_GB/heatsinks/B01/Heatsinks for PGA/PR/ICKPGA14x14x14_/index.xhtml

For Pi form factor boards I've been using a 25 x 50 mm aluminum heatsink available on Amazon, top left in image. 

I added some experimental tweaks to my development image to enable HS-200 mode for the eMMC ( was SDR50 before just like the SD card). I will submit a proper patch for ayufan's BSP linux branch during this week. To get HS-200 mode working, there were some clock definitions (looking at you, ciu-sample and drive clocks...) missing and some properties (maximum bus frequency) I had to add to the rk3328.dtsi... but it seems to run stable now...
 
Some iozone results before and after switching SDR50 to HS-200:
 
---------------- SDR50 --------------------------------------------- random random kB reclen write rewrite read reread read write 512000 4 3430 3554 10964 10472 8152 1614 512000 16 7064 7647 25009 25242 2069 6249 512000 512 10800 11494 41555 43169 42551 10620 512000 1024 11228 11736 42159 43690 43338 10890 512000 16384 11258 11733 44909 44825 44875 11165 ----------------- HS-200 ------------------------------------------- 512000 4 3414 3399 17914 8218 11523 1752 512000 16 9078 9804 56272 56583 39466 7190 512000 512 13173 14054 119128 118530 116335 13008 512000 1024 13816 14607 117665 121782 120387 13429 512000 16384 13814 14662 122756 124242 123471 14007 It seems we are getting close to the 140MB/s read performance the datasheet promises, but 15MB/s is still short of the 35MB/s write performance according to the datasheet, so any hints are welcome here...
 
I would also like some advice on the phase correction loop sublayer in the generic mmc driver, how does one pre calculate the default phase shift? 

Yeah the connectors for USB3-A are tricky. On my old Thinkpad the lower USB3 port which I used a lot more than the upper port enumerates half the time only as high speed instead of super speed because it seems to be worn out, I also noticed some USB3 connectors fit a lot tighter than others... I wonder if there is some low level stats we can pull out of Linux to see USB transmissions errors as an indicator for bad cable connections?
 
Edit: apparently there is this https://wiki.wireshark.org/CaptureSetup/USB

Well, we have to keep in mind that this is just a TV box SoC and not designed for serious storage tasks. Especially the choice of protocols/connectors is not comparable.
 
Please look at the dmesg output starting from 15.730777. That was me testing with a JMS567 enclosure and running in all sorts of errors. I shut the board down, reinserted the cable --> problem gone. When testing with the cable not properly inserted it looked like this (please notice the orange triangles which show minimum and maximum values since bus resets happened and other stuff -- surprisingly no filesystem corruption):

In other words: Cabling/connector issues are quite common with USB3. USB3 cables/receptacles have 5 more contacts than USB2 gear and those are f*cking small compared to the 2 contacts used for Hi-Speed/USB2 data lines. Only if cables really fit exactly and are inserted fully you won't run in troubles:

 
USB3 is cheap consumer electronics crap and you need to pay a lot of attention to such stuff! For the USB2 data lines it doesn't matter much whether the cable is completely inserted or not but those small USB3 contacts need 'full contact' and since the SuperSpeed data lines are on the outer contacts small movements of the cable can negatively impact connectivity (you touch the cable, it's now inserted with 3° instead of 0° and problems start).
 
In case I'll ever build a small NAS with a ROCK64 there are 3D printed parts needed to properly fix the cable since everything else is just plain stupid. Even HDD vibrations can lead to contact problems over time if the cable is not properly fixated!
 
And now have a look how 'Mini SAS' or SATA look like. The contact surface is much MUCH larger, some cable bending is exactly no problem and there are metal latches by design to fixate cable/connector:

And then all serious storage protocols know mechanisms to deal with cable/connector problems. With SATA for example we have SMART attribute 199. If this value increases this indicates a cable/connector problem since SATA uses some checksumming to ensure data integrity. SMART counter 199 should increase if this happens so you know exactly where to look at. With USB3/UAS the error messages read like 'uas_eh_abort_handler 0 uas-tag 7 inflight: CMD OUT' and people get crazy yelling 'UAS is evil!' while they would run in exactly the same problems without UAS but then the error messages read differently.

Now a second SSD (very slow Intel 540) in a second JMS567 connected to the VIA 812:
root@rock64:/home/rock64# lsusb Bus 005 Device 005: ID 0bda:8153 Realtek Semiconductor Corp. Bus 005 Device 004: ID 152d:3562 JMicron Technology Corp. / JMicron USA Technology Corp. Bus 005 Device 003: ID 152d:3562 JMicron Technology Corp. / JMicron USA Technology Corp. Bus 005 Device 002: ID 2109:0813 Bus 005 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 004 Device 002: ID 2109:2813 Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub root@rock64:/home/rock64# lsusb -t /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M |__ Port 2: Dev 3, If 0, Class=Mass Storage, Driver=uas, 5000M |__ Port 3: Dev 4, If 0, Class=Mass Storage, Driver=uas, 5000M |__ Port 4: Dev 5, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M I created a btrfs raid-0 (mkfs.btrfs -f -m raid0 -d raid0 /dev/sda1 /dev/sdb2) and tried it again:
Samsung EVO 840 and Intel 540 as RAID-0 with UAS behind VIA 812: random random kB reclen write rewrite read reread read write 102400 4 7760 6563 15659 15284 11590 4870 102400 16 21240 16059 49077 39481 39938 11588 102400 512 158914 128861 126339 127106 122961 134573 102400 1024 169372 173392 152526 128089 128313 167697 102400 16384 257307 1592 287695 284334 288541 241423 Shitty performance as expected and especially the 16M rewrite horribly low due to the yet missing fix for an USB3 PHY issue currently present on RK3328: https://pastebin.com/wkkdgV4J
 
RAID at home is stupid anyway but once the USB3 issues are fixed upstream I would believe adding more than one disk to a ROCK64 and accessing them even at the same time won't be an issue since performance will still be way faster than the Gigabit Ethernet bottleneck here (if you look closely my USB hub also contains an RTL8153 Gigabit Ethernet USB chip -- the same that is used on ODROID-XU4 BTW -- so most probably later we see crazy folks doing crazy stuff like using a ROCK64 as iSCSI server utilizing Multipathing to serve clients with up to 220MB/s)
 

New try with latest ayufan OMV build (after fixing some issues like rrdcached doing stupid things on all 4 cores or IRQ affinity settings not working and so on). Performance governor, EVO 840 120GB (cheap consumer crap), UAS/JMS567. Test with 100 MB and 12 GB (only testing with 4K and 16M blocksizes and sequential transfer speeds only:
Samsung EVO 840 (slowest 120 GB model, small TurboWrite buffer) with UAS: random random kB reclen write rewrite read reread read write 102400 4 15325 20806 22007 22979 16980 21169 102400 16 52930 77415 69738 77945 63361 67742 102400 512 287901 316528 305584 289701 279577 264499 102400 1024 314457 343568 333184 344791 336613 350049 102400 16384 359641 363954 359817 374210 374654 364461 12288000 4 17466 21834 24245 24389 12288000 16384 118447 134973 368548 368181  
The 120GB EVO 840 is a bad choice for performance tests since rather slow and bottlenecked by a pretty small 'TurboWrite buffer'. Like all cheap consumer SSDs this one shows dramatically dropping write performance if amount of data exceeds the size of the TW buffer (IIRC just 1 GB on this model). That explains why write performance with 12GB test size is that low. But looking at the above numbers we know we can trust in iozone3 results with small test sizes and this SSD known to exceed 500 MB/s on a SATA 3.0 port is good for 360 MB/s with RK3328.
 
Now with a VIA812 hub in between testing the EVO 840 with 100 MB again as above:
Samsung EVO 840 (slowest 120 GB model, small TurboWrite buffer) with UAS behind VIA 812: random random kB reclen write rewrite read reread read write 102400 4 17623 22594 22798 21271 17063 19918 102400 16 59893 65823 77422 77771 60776 72342 102400 512 298044 309659 295337 304488 294191 315187 102400 1024 326897 337167 316500 324801 323386 344312 102400 16384 357958 363964 340186 360812 360139 363830  

That is an interesting question, I have one USB3 hub at home, maybe I'll get a second JMS bridge and find out...

Not really since I lack USB-to-3.5/1.35mm cables to do some precise measurements. But since we're talking about LPDDR3 here I wouldn't be concerned about the size of memory unless there's something f*cked up with entering low power states (driver issues). That's why I did no tests yet since I lack the cable and since I don't trust in software being 'stable' yet.
 
Most probably for your use case being able to choose an appropriate PSU (5V/1.5A) would save more on consumption than RAM size.

Hmm... I think there's a misunderstanding.
 
I was only talking about my usual consumption measurements using another SBC (Banana Pro) and it's power management IC to measure its own consumption and the one of a connected other SBC (web search for 'measuring psu site:armbian.com' should give the idea). For this and only for this I would need such an USB to barrel cable, for all other use cases I would strongly recommend their 3A PSU with fixed cable.
 
Your server setup with just a single SSD might be reliably powered with only 1A (so add some peak consumption and you're at 1.5A) so if you ensure that you avoid under-voltage then you should be fine with a 1.5A PSU too. A 3A PSU is not that efficient with loads that are below 50% or even 30% of the maximum ratings so if you're after power savings you might benefit from a 'smaller' PSU. But that was only to illustrate that if you care about consumption it's most probably better to look at PSU 'size' than DRAM size  

Time for a small '2017 follow-up' on this issue this time only focussing on 'disk performance' (HDD/SSD, not onboard storage like eMMC or SD cards).
 
Since we all know that we don't need to differentiate here between individual boards but can look at board families (the SoC is the important thing) I only check the following 'families':
cheap Allwinner stuff running with A64 or H5 (that's the Pine64 numbers below, H3 boards score a bit lower) Allwinner A20, R40 or V40 (that's the Banana Pi Pro numbers below, maybe random IO numbers look better with the R40/V40 boards but since those are only available from manufacturers also known as brain damaged retards that's not an option today) i.MX6 (Wandboard Quad, not supported by Armbian but a few other boards using the same SoC) Exynos 5422 (ODROID XU3 or XU4) RK3328 (ROCK64) Armada 38x (Clearfog Pro, same numbers will apply to Turris Omnia, Clearfog Base or Helios4 soon) Why are all other boards missing? Since uninteresting if it's about storage. SATA or USB3 are a must, the only exception below are the UAS capable USB2 Allwinner devices since they show a few more MB/s sequential throughput and way better random IO numbers compared to USB2 solutions that only support the old/anachronistic USB Mass Storage mode.

All tests done with Samsung EVO SSDs (my EVO840 used for all tests except of the ODROID-XU4 results which were made with a much faster EVO850 instead and Pine64 numbers with a slower EVO750 so random IO numbers should be multiplied with 1.3 or even 1.4):
                      Random IO in IOPS     Sequential IO in MB/sec                         4K read/write           1M read/write Pine64 (USB2/UAS)         2260/1948                42 /  41 Banana Pi Pro (SATA)      3943/3478               122 /  37 Wandboard Quad (SATA)     4141/5073               100 / 100 ODROID-XU4 (USB3/UAS)     4637/5126               262 / 282 ROCK64 (USB3/UAS)         4619/5972               311 / 297 Clearfog Pro (SATA)      10148/19184              507 / 448 Testing methodology is somewhat wrong but I refuse to waste much of my time to do proper benchmarking since it's only about getting the idea what to expect. So as a summary:
USB2 SBC that lack UAS capabilities are simply too slow to be even listed here UAS capable cheap Allwinner USB2 boards show ok-ish performance for low-end setups (think of NanoPi NEO2 as NAS for example) SBC featuring 'real SATA' have to be differentiated. Armada 38x shows top performance like x86/x64 boards, i.MX6 is somewhat ok, A20/R40/V40 simply suck (you better don't buy this crap any more) USB3 SBC like ODROID-XU4/HC1 or ROCK64 show way better performance. You only have to take care of the USB downsides (XU4 with an internal USB hub and receptacles problems is in a bad position here) and ensure that you're using good USB-to-SATA bridges to connect SSD or HDD If we also take price/performance ratio into account then ROCK64 or other RK3328 boards that will follow are really hard to beat. The 1GB ROCK64 variant will most probably stay below the $25 margin and you should keep in mind that more DRAM is pretty useless if you think about (NAS) performance. Only on devices where IO throughput is way lower than network throughput having more DRAM as needed might improve NAS write performance if settings are appropriate (since then amounts of data that fit into RAM will be written at network speed and flushed later to disk)

This is ROCK64 specific. New board with correctly working USB3 arrived 10 minutes ago. Switched to performance governor and doing the usual 'iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2' with the slowest SSD I have lying around (Intel 540):
random random kB reclen write rewrite read reread read write 102400 4 10794 14075 18413 14337 12084 13125 102400 16 38316 48250 58929 50123 33636 44383 102400 512 85148 113573 217972 226149 209220 229556 102400 1024 239054 254531 226798 261436 240226 213082 102400 16384 271696 291983 316979 323006 282067 292218 In other words: this is the new single drive NAS board. Forget about overpriced fails or slow A20 boards or their R40/V40 successors currently only available from brain damaged retards.

The RK3328 seems like a very nice SoC, but the support in mainline linux is currently very limited and there are still a few issues with Rockchip's LSK 4.4 kernel.
We are currently tracking a few RK3328 issues at https://github.com/Kwiboo/linux-rockchip/issues for our LibreELEC endeavor.
 
@Xalius @Da Alchemist Android is most likely limited to 720p due to the weak GPU, we are planing on doing the same for LibreELEC/Kodi/PMP, limit gles to 720p/1080p but allow video frames to be shown in 2160p.
On the Z28 box we are only able to have a smooth gui at 720p, at 1080p there are noticeable frame rate drops at times.
 
@jernej there was a ffmpeg mpp decoder submitted earlier today, see https://patchwork.ffmpeg.org/patch/3904/
Multi-channel PCM via HDMI should work very similar as other SoCs with 8ch I2S and a DesignWare HDMI TX IP, works great on Rockchip's LSK 4.4 kernel at least.
The Rockchip RK3399TRM V1.3 Part2.pdf from Firefly-RK3399 docs is very interesting if you want more details about the HDMI TX IP and its registers.

For the record:
 
This advice is absolutely awesome Thank you soooo much!! I did not know how simulating an installation was possible and was frustrated everytime when I screwed my testing system...
 
Solving my original question:
 
using 
apt-cache policy  and
apt-cache policy nginx showed me the current pin-priority and after adding my prefered repo I could follow whether this would be considered or not. And then I just needed to setup a corresponding preferences file:
 
Package: *                       Pin: release a=unstable           Pin-Priority: 400              Package: *nginx*                Pin: release a=unstable Pin-Priority: 600                Package: *mariadb-server*       Pin: release a=unstable Pin-Priority: 600 First part lowers the priority for the whole unstable repo. The other two sections raise priority specificly for nginx and mariadb. Of course I ran into dependency problems with mariadb-server, but thats another story. Anyways... with your -s parameter I was able to see what is going to happen, thus solving everything I needed.
 
Thanks again zador.blood.stained