tkaiser

Better forget about these SATA port multipliers. While those from Marvell are 'good' (FIS based switching which is essential for good performance when accessing few disks in parallel) obviously all ports have to share bandwidth and latencies of the upstream SATA port and these Marvell PM work only well behind Marvell SATA ports. But if you've a Marvell SATA port you always have at least one Marvell PCIe port too so using a mPCIe SATA controller with 88SE9215 is the better idea. Wrt your RAID idea: I would forget about this since you most probably only fool yourself (wasting disks for redundancy for no reason). Correctly implementing a multi drive RAID requires testing, testing, testing and... testing. Home/SOHO RAID enthusiasts never do this and that's one of the reasons why we (OMV community) have every other day a new 'Oops, my RAID array has gone. Where's my data? I've no backup of course!!1!' threads in the forum (where you could also find a lot of rants of mine and others wrt RAID at home)

You should keep in mind that you're playing early adopter. MTK's first 'open source' MT7623 device is this BPi R2 so I would assume you need a lot of patience until such 'special' stuff is properly supported especially given that such basic stuff like cpufreq scaling still isn't working.

GCC version and/or compiler flags aren't that relevant in general. But it's absolutely important to know this when dealing with sysbench numbers (as already said: a rather crappy benchmark telling not much about the hardware but a lot about compiler optimizations). And the same is true when you look at 'sftp transmission speeds' since this is essentially just single-threaded SSH here and both sides of the connection negotiate the strongest of the available ciphers. So looking at these numbers is irrelevant since it depends on ciphers available on both sides which one gets dynamically chosen (give it a try with 'scp -vv' to see what really happens). When you choose a strong cipher and can not make use of crypto extensions then on slow ARM devices you're usually bottlenecked by a ssh or sshd process running single threaded maxing out one CPU core. Since you seem to need high crypto performance in case you are able to use AES you should better search this forum for 'armv8 aes crypto extensions' and forget about all those dog slow ARMv7 SoCs like the MT7623 on the R2 (an Espressobin for example will enrypt/decrypt magnitudes faster, cheap RK3328 devices like 'Transformer' when we're able to clock them up to 1.5GHz might then show 500% the multi-threaded AES performance of an Espressobin and of course a few thousand percent of what you get with BPi R2). BTW: 'Useless' stuff installed on OS images isn't much of a performance issue even if most users believe this. Missing optimizations are the real problem. Take a look into Armbian's /etc/init.d/armhwinfo service and the optimizations we do wrt cpufreq/dvfs stuff. Good luck over in BPi forum -- you should be aware that while you're trying to get information on this R2 they're already busy preparing another totally incompatible board relying on a RealTek SoC called W2 (great concept to throw out board after board all incompatible to each other so that software support always has to start at zero and will never get in a good shape).

It's not, you need different DT stuff for Ethernet. Z28 is like Rockbox and Z28 Pro should be somewhat similar to ROCK64 and 'Transformer' (the RK3328 thingie with integrated JMS578)

They don't build packages, if you used Ubuntu Xenial on this thing it's Ubuntu's armhf package (GCC 5.4, ~30% faster compared to GCC 4.9) Nice joke! There I wrote something about SSH/scp/sftp: http://linux-sunxi.org/Sunxi_devices_as_NAS#Benchmarking_.2F_Identifying_bottlenecks -- when you run htop in parallel you see one core being maxed out, yes?

Please forget about such tests since sysbench's cpu test mode is just a great way to fool yourself. It's most probably the most crappy performance benchmark ever since it's more or less just a compiler test. Only advantage: It's not dependent on memory bandwidth at all so if you know count and type of CPU cores, exakt sysbench version (did you use 0.4.12?) and compiler version/flags you can estimate CPU clockspeeds. You find some details when you search the forum for 'sysbench pseudo' or outlined here: Comparing your numbers from ARMv7/Ubuntu with NanoPi NEO most probably the MTK SoC is clocked slightly above 1 GHz which would be bad news wrt the storage performance numbers since I assumed that currently the SoC is only clocked with 400-600 MHz (and then that low performance numbers are to be expected).

We still have one since 1 or 2 weeks (but it seems no one is using Jessie any more ). Currently jessie-utils and jessie-desktop packages throw errors. Hmm... if we stay with http deb sources (which I'm fine with) what about better using round robin DNS?

I was thinking about DNS spoofing attacks (not that realistic but at least possible if I understood the current KRACK implications correctly)

Hmm... downloaded https://dl.armbian.com/orangepiplus2e/Debian_jessie_default.7z, booted OPi Plus 2E and get W: Failed to fetch http://apt.armbian.com/dists/jessie/InRelease Unable to find expected entry 'jessie-desktop/binary-armhf/Packages' in Release file (Wrong sources.list entry or malformed file) What happened to both jessie-utils and jessie-desktop packages in the repo? Armbianmonitor -u and contents of /etc/apt/sources.list.d/armbian.list: deb http://apt.armbian.com jessie main utils jessie-desktop BTW: Wouldn't be switching to https://apt.armbian.com a good idea?

This is a kernel problem. Check https://forum.armbian.com/index.php?/topic/4567-banana-pi-r2/ ('no performance numbers known, no info about real clockspeeds, currently cpufreq seems still to be broken: /cpus/cpu@0 missing clock-frequency' -- seems nothing has improved within the last 4 months and no one has a clue how fast the CPU cores clock.) Can you provide the output from 'sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=4' with this Ubuntu image? Most Marvell SoCs use a technology called 'SERDES' to provide high-speed interfaces. Can then be configured to transport either SATA (then you get +500 MB/s per port) or PCIe (then it's just ~400 MB/s when attaching a PCIe SATA controller due to a PCIe lane having lower throughput and the additional overhead). With the MTK thingie here I would assume once they get their software problems sorted we're talking about 400 MB/s max (the two SATA ports have to share) since that's what's usually possible with the ASM106x SATA controller used on the board. But I doubt we will ever see OS images from them using appropriate settings so performance will always be an issue (if you see a company providing Raspbian images you don't need to ask any more questions)

And one of that products you can only sell online since everyone trying it out in real life wants to throw it out of the window or back at the manufacturer asking for a refund https://www.cnx-software.com/2017/02/15/gpd-pocket-cherry-trail-7-portable-computer-runs-ubuntu-16-04-or-windows-10-crowdfunding/

Which custom board will this be? If the SoC is not already supported by Armbian chances are great that you won't see Armbian running on it anyway. If you choose an Ubuntu Xenial Armbian variant there will be not that much differences at the distro level since most packages are then coming from Ubuntu's repositories anyway. We just have a slightly different package distribution (eg. we neither install Ubuntu's ondemand service nor the irqbalanced packages since both counterproductive on ARM). Everything that's really relevant happens below the distro layer anyway. And that's Bootloader stuff (u-boot and ARM trusted firmware) Kernel stuff (Armbian collects a huge bunch of patches for the various kernels we support and tests them) Settings (both wrt lowering consumption and increasing performance -- often at the same time) You might happen to find $some Ubuntu image for a random SBC out there (eg. an OS image provided by the board manufacturer) that consumes overall more energy while performing only half as fast as Armbian with certainor even most use cases. The other huge difference is that Armbian images are created from scratch and no one ever has logged into when you burn your image to SD card and start the board. So you don't have to fear OS misbehaviour due to stupidity or unthoughtfulness. If a mistake is found on any of the Armbian images, the fix will not applied to an already existing OS image manually but always goes into the central development repository so every bug will be fixed in a documented and reproducable way.

https://forum.openmediavault.org/index.php/Thread/17855-Building-OMV-automatically-for-a-bunch-of-different-ARM-dev-boards/?postID=153760#post153760 ODROID C2 booting with exactly this kernel version. Check the sprunge.us link and there the 'quick iozone test' line. Almost 8MB/s read and almost 3MB/s write with 4K blocksize while booting -- there should be nothing wrong with this kernel and I would check contacts in the SD card slot and dmesg output for SDIO errors and stuff like that first.

The throttling code uses the first thermal trip point defined and that's 75°C in default fex file. When you click around in RPi-Monitor graphs using your setting (14 days) will show averaged numbers so for any such 'in depth' looks switching to default graph display (24 hours) is required.

Thank you for the report. Fixed (strangely it was only wrong on those two boards you own). Explanation: The DRAM driver in legacy kernel implements some throttling code that is invoked as soon as cooling state exceeds 0 (in your case that happened when SoC temperature reached 75"C). So the board starts with DRAM clockspeed set by u-boot (624 MHz) but as soon as throttling occurs starts to use the (wrong) value in fex file. Is fixed now and will be rolled out with next major update. BTW: In case H3 doesn't wear a heatsink I would recommend installing one on each board.

BTW: This is marketing BS or 'technical documentation done like BPi is doing it' (copy&paste gone wrong and not caring about this). The 546 MB/s are the theoretical maximum you get with a SATA 3.0 connection (6Gbps + 8b10b encoding) but here we're talking about the SATA controller being behind a single PCIe 2.x lane (6GT/s + 8b10b encoding = 500 MB/s absolute maximum, add the overhead and you get numbers lower) and since on BPi-R2 they chose to use the cheapest controller possible you end up with a maximum of ~400MB/s anyway (see the ASM1062 numbers we made in the linked threads above or anywhere else). Then the SanDisk 'tech specs' show 546/342MB/s for all Z400s models regardless of their capacity which can't be true since with all consumer SSDs it's a known fact that sequential performance gets the better the larger the capacity since the SSD controller will use parallelism to write to more cells at the same time. And of course it's like that, the 128GB variant for example shows a maximum write speed of just 180MB/s and those with less capacity will show a lot lower sequential throughput. So your SSD is already insufficient to test the limitations BPi R2 has wrt SATA storage access but also as already written above this shouldn't matter that much since +100MB/s should be fast enough for most use cases anyway and since SinoVoip OS images don't take care about the few necessary performance tweaks you won't see high real-world storage performance anyway.

All H2+/H3 boards share the same kernel so I wonder why you try to build the (already included) driver from source? What's not there on the Zero images are the settings (either fex contents or device-tree with mainline kernel).

If you think about how SATA is implemented here (ASM1062 attached via PCIe) it should be obvious that your numbers are too high (benchmarking gone wrong). In case you want to produce another set of numbers follow @chwe advise but also check with one test using a test size 3 times the available DRAM: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 iozone -e -I -a -s 6000M -r 16384k -i 0 -i 1 -i 2 If results for 16M blocksize match when testing with 100M and 6000M filesize you know that you don't need to throw the 100M numbers away. But it's still just numbers without meaning since to get the device's capabilities you would need to switch to performance cpufreq governor (otherwise if cpufreq scaling is implemented most probably zero optimizations have been applied) and if the available OS images generally don't take care about performance (eg. default IRQ affinity or using the 'wrong' cpufreq scaling settings) then benchmarks now show nice numbers but later in reality you suffer from bad performance (eg. since CPU cores don't clock up when needed and all IRQs being processed on cpu0).

Had worked or is working? If you claim it is working very well there too then please show us performance numbers made now on these other boards. Otherwise moving the thread to https://forum.armbian.com/index.php?/forum/31-sd-card-and-power-supply/ would be a good idea.

Seems ayufan fixed eMMC issues now and it seems also he switched in the meantime to a branch with active drm (no changes to the branch Armbian uses since 3 months)

Legacy kernel (all USB ports enabled on every board) OPi Plus 2 and not Opi Zero 2+ The next time you try it with Armbian please provide output from 'armbianmonitor -u' so we get an idea which OS image you tried.

Sure. And if the Espressobins really come with a real MAC address we should also take care to preserve the address when updating u-boot and stuff when it's set in the flash by factory.

See also https://forum.armbian.com/index.php?/topic/5104-xu4-next-nand-sata-install-usb-disk-rootfs-not-found/

Nope, for A20 (BananaPi M1) performance see here and for the M2 just search for 'iperf' in this thread there: 'Funny': By searching for M2 iperf results I stumbled accross this here again: https://groups.google.com/d/msg/linux-sunxi/sMMqCjUfoLE/RXYJwz0U_C4J

This is often a problem caused by an external disk not mounted and so $something starting to fill up eg. /Backup on the SD card instead of the disk (since sdb not mounted). Always an idea: umount all external disks and run a 'du -sh /' again.