tkaiser

Leaving 32-bit platforms behind and focusing on aarch64/ARMv8 is also an option: http://sprunge.us/KHCM (OPi Zero Plus at this stage clocked with 816 MHz)

Igor added in the meantime the device to the build system with our usual 'conservative' approaches (downclocking DRAM for example on those small boards with 16-bit DRAM config since we don't want to fry them). So let's test with an Armbian Xenial arm64 now (64-bit kernel 4.13.13, max cpufreq limited to 1008 MHz and clocking DRAM at 408 MHz): https://pastebin.com/2iYbFRhD Test BSP Armbian std memcpy MB/s: 887.9 634.8 std memset MB/s: 2037.9 1553.0 7z comp 22: 1288 1234 7z comp 23: 1344 1279 7z decomp 22: 3296 3329 7z decomp 23: 3215 3317 sysbench 648 (s): 14.4798 14.1447 sysbench 816 (s): 11.4151 11.2191 sysbench 1008 (s): 9.2395 9.0787 openssl speed aes: identical The way lower DRAM clockspeed ruins tinymembench numbers (and would most probably affect graphical applications that depend on memory bandwidth) but with tests that are affected by lower memory bandwidth and higher latency (like 7-zip) the difference is negligible (in fact with our kernel/settings 7-zip is finishing the first time not being oom killed). Debug output here: http://sprunge.us/KHCM So once we rebased the whole stuff to 4.14 within the next weeks, then allow H5 to clock up to 1200 MHz some more performance improvements will follow.

And with the new official OMV image you'll most probably reach or exceed 40MB/s since a few more performance tweaks are active there.

No, you still confuse 576 with 567 I updated the other thread wrt firmware naming in the meantime... Edit: you need to travel back in time for JMS567: https://web.archive.org/web/20160815000000*/http://www.jmicron.com/product0201.html

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.

Nice, so your JMS567 appears as JMS578 on the USB bus and mine as JMS561. Can you extract the firmware please as shown in the 'NAS Expansion board' thread and provide it here? I want to reflash one of my JMS567 to JMS578 too

Huh? JMS567 is not JMS576. According to your debug output the one you're using is JMS578 (152d:0578 -- JMS567 would show up as 152d:0561 instead) so in case you're talking about an JMS576 then this chip would share same Product ID with JMS578. Can you please use your magnifier glass and check? Wrt versions: Xunlong's NAS Expansion bay with JMS578 uses 0.4.0.4 ROCK64 SATA cable with JMS578 uses 0.4.0.5 Hardkernel's HC1 with JMS578 uses 0.1.0.5 FriendlyELEC's NAS bay with JMS5xx uses 0.2.2.7 Two older JMS567 lying here around use 46.3.0.2 For now I would assume JMicron is implementing a special numbering scheme where the 3rd value is not a version number but only the last. Will ask them later.

@guidol Can you please have a look which firmware version your JMS578 is running with? It's really as easy as downloading the archive Hardkernel/ODROID provided, unpacking it and running JMS578FwUpdater/JMS578FwUpdate -d /dev/sda -v directly afterwards (causing no harm, I let this JMicron firmware tool already check other JMicron, ASMedia, Genesys Logic, Prolific and Initio bridges -- they all behave well while all my JMicron bridges returned firmware version properly). Details: https://forum.armbian.com/topic/3317-orange-pi-zero-nas-expansion-board-with-sata-msata/?do=findComment&comment=43666

Well, I thought I was joking but in fact this does exist. An industrial i.MX6 design with 40 pin header does exactly that. Exposing the needed PCIe pins on the header:

Yes, whether bug or feature I'm not sure. It seems armbian-config appeared, today it left and we don't discuss this stuff Wrt which Armbian flavour: Honestly I can't tell the difference for headless use cases since Debian and Ubuntu behave the same, the age of packages usually isn't that important unlike with Desktop images and the dependency hell there to provide HW acceleration especially for video and if you want to use OMV you'll need to stick to Debian anyway.

Just a little bit: https://forum.armbian.com/topic/4921-orange-pi-zero-plus-h5-chip/?do=findComment&comment=43667 (but with UAS active also CPU utilization slightly decreases so it's good anyway)

And another update. I also tested quickly USB2 performance with Xunlong's NAS Expansion board. I had to update the JMS578 bridge firmware to get USB Attached SCSI working and now (still running with no voltage regulation at boring 816 MHz) it looks like this (still some small room for improvement once we can jump from 816 MHz to 1200 MHz): With UAS random random kB reclen write rewrite read reread read write 102400 4 9759 10091 9672 9771 9783 9505 102400 16 21267 21244 21282 21333 21332 21266 102400 512 37297 37676 40738 40983 40983 37589 102400 1024 37772 37933 40880 41180 41179 37991 102400 16384 37017 38288 41635 41802 41621 38331 Mass Storage (prior to firmware update) random random kB reclen write rewrite read reread read write 102400 4 10492 10621 10655 10651 9462 10634 102400 16 19206 21237 21273 21334 21327 21292 102400 512 36758 36901 37398 37560 37567 36962 102400 1024 37605 37660 38225 38400 38403 37572 102400 16384 36389 37763 39923 40071 40085 37839

Little update on the NAS Expansion board: the first time I had this thing in my hands and gave it a try with mainline kernel I was surprised why the JMS578 chips on the board did not allow to use UAS. It looked always like this (lsusb -t): /: Bus 04.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 With no other JMS578 device around I experienced this and since I'm currently testing with Orange Pi Zero Plus (still no UAS) and In the meantime JMicron provided us with a firmware update tool.... I thought I take the slightly higher JMS578 firmware revision from ROCK64 SATA cable (0.4.0.5) and update the NAS Expansion board (0.4.0.4) with: root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sda -v Bridge Firmware Version: v0.4.0.4 root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sdb -v Bridge Firmware Version: v0.4.0.5 root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sdb -b ./JMSv0.4.0.5.bin Backup Firmware file name: ./JMSv0.4.0.5.bin Backup the ROM code sucessfully. Open File Error!! root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sda -f ./JMSv0.4.0.5.bin -b ./JMSv0.4.0.4.bin Update Firmware file name: ./JMSv0.4.0.5.bin Backup Firmware file name: ./JMSv0.4.0.4.bin Backup the ROM code sucessfully. Programming & Compare Success!! Success! /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 480M Please keep in mind that you need to update both JMS578 of course. I won't upload the newer firmware yet since thanks to Pine's TL Lim I'm in direct contact to JMicron now and it's about fixing another JMS578 firmware issue.

To prepare next steps I booted with vendor OS image once (obviously no tuning at all for this board, it seems that's generic Allwinner H5 BSP stuff already used for Orange Pi PC 2 before, at least this is /boot/orangepi/OrangePiH5orangepi.dtb being decompiled). Performance results here: https://pastebin.com/TZhEPrqs (64-bit kernel 3.10.65, settings limiting cpufreq to 1008 MHz and clocking DRAM at 624 MHz) Then I thought I take FriendlyELEC's Xenial image for their NEO Plus 2 (since same voltage regulation, switching between 1.1V and 1.3V toggled by PL06 pin) but to no avail. IIRC they implement some board detection logic and I ended up with no cpufreq support but running at 816 MHz, DRAM clocked at 672 MHz: https://pastebin.com/8wEaPiUp (quick note wrt iperf3 tests: with Armbian IRQ affinitiy settings numbers improve from 844/922 Mbits/sec to 895/940 Mbits/sec so once we have voltage regulation configured correctly on this board and can exceed 816 MHz cpufreq full GbE saturation will be possible) With BSP kernel and without heatsink this thing idles at 55°C according to sysfs so it now wears a heatsink (and all tests above were made with a fan running in parallel).

Just created the wiki page for the device: http://linux-sunxi.org/Orange_Pi_Zero_Plus

Irrelevant (only important for OPi Plus 2E). BTW: Pine H64 board now officially announced: http://wiki.pine64.org/index.php/PINE_H64_Main_Page (the 3GB variant might disappear again since it has to be checked first whether it works -- H6 is said to be able to address up to 3 GB DRAM but there are only 1, 2 and 4 GB LPDDR3 modules available so 1 GB would be wasted anyway)

Icenowy has a direct contact to an Allwinner BU3 engineer and just uploaded http://linux-sunxi.org/File:Allwinner_H6_V200_User_Manual_V1.1.pdf and http://linux-sunxi.org/File:Allwinner_H6_V200_Datasheet_V1.1.pdf

Thank you for the test. So this box starts to throttle around 80°C and reported cpufreq also decreases (when 1512 is shown in reality it's 1200 MHz, the above execution duration indicates ~1080MHz in reality). So numbers still bogus as expected but at least there is an indication that throttling happens through sysfs (Raspberry Pi for example fakes this also: when throttling happens there and the real cpufreq goes below 1200 MHz -- eg. 800 MHz -- sysfs still reports 1200 MHz until 600.1 MHz. Only if throttled down to 600.0 MHz sysfs shows correct values again).

Well, I still don't like Micro USB for DC-IN and would hope they add a good, short and at least 22AWG rated Micro USB cable when shipping the boards (or at least later as mandatory add-on). Then while I understand why GbE is missing (since H2+ is said to not support it, so this decision allows for using the same PCB with all three Allwinner variants and just exchange SoC and DRAM chips) this limits some use cases. But on the bright side it seems all 4 USB ports are directly available as type A receptacle (Micro USB for powering only) and eMMC as module is getting more popular (and by looking at Libre Computer's web site it seems they will provide similar modules for a few other boards too):

With PCIe 2.x on it and not GPIO! (just kidding)

That's all we have (currently): http://linux-sunxi.org/File:H6-Brief_V1.0.pdf (and there Allwinner talks about DDR4 and LPDDR3). But TL Lim also today said in linux-sunxi IRC Allwinner's BU3 considers 'H6 open source support ... a key factor' and 'H6 datasheet and user manual will be release as no confidential watermark.' And there's also a H6 SDK already in the wild...

And today Steven revealed existence of two more H6 boards that might look familiar Source is linux-sunxi IRC, no more information available yet. Looks like the H6 OPi One gets a Gigabit Ethernet upgrade (if that's a GbE PHY between H6 and Ethernet Jack), looks like an USB3 upgrade on the H6 Lite and also looks like Xunlong switched from RTL8189FTV to RTL8189ETV now. On the bottom this seems to be a PMIC on both boards and LPDDR3 now.

If I understood correctly using GeoIP is a nice attempt to do it quick&dirty (at least after quickly reading through https://www.digitalocean.com/community/tutorials/how-to-use-nginx-as-a-global-traffic-director-on-debian-or-ubuntu). Configure 3 servers (two times Lauri's sitting in the US and in Russia, and uk.armbian.com sitting in the EU), done. Should then work for both images and apt traffic.

That implements another bottleneck called 'client side storage'. I had this over at OMV forum a few times already that people try to 'benchmark' their NAS boxes and report a weird slowdown in server --> client direction after some time. Being asked about the storage, they answered SSD, I explained that many consumer SSDs can get pretty slow after some amount of data has been written continously (many of them get then as slow as 60 MB/s or even lower) but usually people don't accept these explanations since it's about blaming the server. Easy alternative: Helios LanTest since it eliminates 'client side storage' influences completely (since test patterns are generated synthetically even for the 10GB test files) while on the other hand it could also be used to test the local storage on its own. LanTest does single thread testing with fixed block sizes which is not any more what Windows Explorer or macOS Finder are doing in the meantime. But that's also the reason it provides a much better picture of overall NAS performance.

Usually 15 minutes should be sufficient (at least that's my experience). Wrt Beelink B1 heat dissipation forget my question please. Jean-Luc already provided insights over a year ago: https://www.cnx-software.com/2016/09/09/beelink-gt1-4k-tv-box-review-part-1-unboxing-and-teardown/ So the heat gets spread to this large metal plate at the enclosure bottom which seems to be rather efficient.