tkaiser

LOL! I asked my friend to try to create a RAID5 out of 3 HDDs connected to his port multiplier and then send me the output from /proc/mdstat while the initial sync is running. Since he has no 3rd HDD around he used a small 120 GB SSD as third drive which keeps the RAID size also small: md0 : active raid5 sdc[2] sdb[1] sda[0] 234178560 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU] [>....................] resync = 3.9% (4654592/117089280) finish=131.9min speed=14200K/sec bitmap: 1/1 pages [4KB], 65536KB chunk unused devices: <none> If I remember correctly when I played around myself with RAID5 today on an Armbian supported device I got +120 MB/s and not just 14MB/s. On the Banana above the RAID array is not even 240 GB in size but sync/rebuild time is still +2 hours. So if these were 3 x 4 TB HDDs both RAID creation or a rebuild after a failed disk would already took 6 whole days. Nothing has changed: Allwinner SATA + port multiplier --> worst performance possible.

Success (as expected since it's really just removing AHCI_HFLAG_NO_PMP as Hans did it with A20 legacy kernel 3 years ago). I asked a friend who for whatever reasons bought a BPi M2 Ultra to try the kernel with my 'patch' out. Et voilà: 2 disks behind the PM immediately usable: root@bpi-iot-ros-ai:/home/pi# cat /proc/partitions major minor #blocks name 179 0 62521344 mmcblk0 179 1 262144 mmcblk0p1 179 2 7269376 mmcblk0p2 8 0 117220824 sda 8 16 117220824 sdb root@bpi-iot-ros-ai:/home/pi# dmesg | egrep -i "ahci|sata" [ 1.433322] sunxi-ahci sata: sata_regulator0 "vdd-sata-25"! [ 1.433393] sunxi-ahci sata: sata_regulator1 "vdd-sata-12"! [ 1.434427] sunxi-ahci sata: regulator "vdd-sata-25" voltage set: 2500000 to 2500000! [ 1.435368] sunxi-ahci sata: regulator "vdd-sata-12" voltage set: 1200000 to 1200000! [ 1.437558] sunxi-ahci sata: frequncy of module clk for AHCI: 100000000 [ 1.437569] sunxi-ahci sata: frequncy of pll clk for AHCI: 100000000 [ 1.500043] sunxi-ahci sata: SATA power enable do not exist!! [ 1.506478] sunxi-ahci sata: forcing PORTS_IMPL to 0x1 [ 1.506539] sunxi-ahci sata: AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl platform mode [ 1.506553] sunxi-ahci sata: flags: ncq sntf pm led clo only pmp pio slum part ccc [ 1.508094] scsi0 : sunxi-ahci [ 1.508714] ata1: SATA max UDMA/133 mmio [mem 0x01c18000-0x01c181ff] port 0x100 irq 88 [ 2.040064] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 2.671284] ata1.00: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 3.230766] ata1.01: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 4.301166] ata1.02: SATA link down (SStatus 0 SControl 0) [ 5.370674] ata1.03: SATA link down (SStatus 0 SControl 0) [ 6.440684] ata1.04: SATA link down (SStatus 0 SControl 0) root@bpi-iot-ros-ai:/home/pi# uname -a Linux bpi-iot-ros-ai 3.10.107-BPI-M2U-Kernel #2 SMP Mon Sep 18 03:21:30 PDT 2017 armv7l GNU/Linux Now he's happy but this will change as soon as he realizes how slow this setup will be -- all disks behind the PM have to share bandwidth and since no FIS based switching is supported also random IO performance will be crappy

To the SATA port of course. Then you have on the M2 Ultra two more USB2 ports that can be also used to attach disks (on the Berry those Banana 'engineers' chose to not use one of the 2 USB host ports and connected an USB hub to the other USB host port so all USB receptacles have to share bandwidth). Anyway since a lot of those Banana users are keen on PM support I simply gave it a try following Dan's readme. http://kaiser-edv.de/tmp/NumpU8/BPI-M2_Ultra_Berry_PM_kernel_3.10.107.tgz root@armbian:/srv/btrfs/BPI-M2U-bsp# git diff diff --git a/linux-sunxi/drivers/ata/ahci_sunxi.c b/linux-sunxi/drivers/ata/ahci_sunxi.c index 58637dc..31c7205 100755 --- a/linux-sunxi/drivers/ata/ahci_sunxi.c +++ b/linux-sunxi/drivers/ata/ahci_sunxi.c @@ -82,7 +82,7 @@ static struct ata_port_info ahci_sunxi_port_info = { .udma_mask = ATA_UDMA6, .port_ops = &ahci_ops, .private_data = (void *)(AHCI_HFLAG_32BIT_ONLY | AHCI_HFLAG_NO_MSI - | AHCI_HFLAG_NO_PMP | AHCI_HFLAG_YES_NCQ), + | AHCI_HFLAG_YES_NCQ), }; root@armbian:/srv/btrfs/BPI-M2U-bsp# file SD/BPI-BOOT/bananapi/bpi-m2u/linux/uImage SD/BPI-BOOT/bananapi/bpi-m2u/linux/uImage: u-boot legacy uImage, Linux-3.10.107-BPI-M2U-Kernel, Linux/ARM, OS Kernel Image (Not compressed), 6832824 bytes, Mon Sep 18 10:21:59 2017, Load Address: 0x40008000, Entry Point: 0x40008000, Header CRC: 0x2A92F115, Data CRC: 0x32A05929 root@armbian:/srv/btrfs/BPI-M2U-bsp# tar cf - SD/BPI-BOOT/bananapi/bpi-m2u/linux/uImage SD/*.tgz | gzip -c >BPI-M2_Ultra_Berry_PM_kernel_3.10.107.tgz root@armbian:/srv/btrfs/BPI-M2U-bsp# I can't check whether it works as expected and I can't inform Banana users in official Banana forum since the funny guy censoring there as 'sinovoip bpi team' constantly deletes my posts or even bans my account. Performance with such a PM attached will be of course even worse than with single disk SATA operation since Allwinner SATA is magnitudes lower than SATA on the good boards we support too (again see here, here, here and maybe also here too)

Edit: 'Benchmarking gone wrong' warning: by accident I missed iozone's -I flag below ('Use DIRECT IO if possible for all file operations. Tells the filesystem that all operations to the file are to bypass the buffer cache and go directly to disk') so all read numbers with 100MB test size are wrong since coming from DRAM and not disk) Since I'm currently playing around with ZFS and have a '3 different SSDs attached to different SATA controllers' setup on my Clearfog Pro today I thought let's try out RAID-5 mdraid performance (I personally would never use RAID5 any more since it's an anachronistic concept from last century and not up to the task any more but since most Helios4 users will love it... why not giving it a try): random random kB reclen write rewrite read reread read write 102400 4 130912 161095 783497 781714 707505 139759 102400 16 147384 161478 939561 871600 894362 155135 102400 512 140284 151258 819534 784290 837237 140587 102400 1024 134588 148516 757065 687973 761542 127707 102400 16384 129696 150554 645589 675420 728091 134269 2048000 4 146697 113501 522420 542454 33662 46919 2048000 16384 123967 113916 441318 477279 460094 137773 That's the output from our usual 'iozone -e -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2' and then another 'iozone -e -a -s 2000M -r 4k -r 16384k -i 0 -i 1 -i 2' to test with a filesize twice DRAM size. It should be noted that especially the last test was limited by one of my SSDs (the Intel 540 slows down to ~60MB/s sequential write performance after approx 1 GB of data has been written that explains RAID5 performance with 3 disks being limited to 'slowest device * 2') so with a bunch of decent HDDs instead the sequential write performance could be around 180MB/s. I let 'iostat 3' run in parallel to check CPU utilization, at least with (very) small block sizes Clearfog Pro is bottlenecked by CPU utilization on the Clearfog Pro (Armada 38x clocked with 1600 MHz). %system utilization was partially above 75% but I don't know whether Marvell's RAID5/6 XOR engine was already loaded or not (a module called async_xor is loaded but I don't know whether that already makes use of HW acceleration) It should also be noted that while creating the RAID5 array SATA errors happened: http://sprunge.us/ciKT (ata6 is the 2nd port on the ASM1062 PCIe controller). With Helios4 there shouldn't be any issues since there all 4 SATA ports are directly provided by Armada 38x (I have 2 SERDES lanes configured as PCIe with an ASM1062 and a Marvell 88SE9215 used). What do the above results mean for Helios4 with its 4 x SATA configuration? Since there we're talking about a single Gigabit Ethernet 'bottleneck' RAID5 storage performance will be sufficient anyway (+100 MB/s).

In my opinion wrt temperature readouts you should really check for /etc/armbianmonitor/datasources/soctemp first (after latest commit it's only two exceptions any more since I hope @TonyMac32 also thinks about RK3288 legacy kernel here but since they're already catched at board start it's easy to let the job do our startscript). And then the basic recommendation to install your software could be Choose a board that's on Pi hole's list or supported by Armbian Install Armbian run armbian-config --> Software --> "Pi hole" And I really hope both armbian-config and your installer start to take security -- temp file vulnerabilities -- seriously (and using HTTPS instead of such insane stuff)

Well, then reply to yourself in your thread over there and link to this thread. If their employee censoring the forum and having constantly deleted my posts is still active he'll delete the link if not at least others could get a clue how to solve the problem.

BTW: I was just kidding since you would be the first person to receive technical support over there. Anyway: you need to manipulate the kernel in a way that 'AHCI_HFLAG_NO_PMP' is not set in: https://github.com/dan-and/BPI-M2U-bsp/blob/master/linux-sunxi/drivers/ata/ahci_sunxi.c#L85 (can be done 'the hard way' but then you loose the ability to attach disks without PM in between or using a more intelligent approach like Hans' patch did it for A20 legacy kernel few years ago). BTW: cheap PM are always a good way to loose your data: http://forum.lemaker.org/forum.php?mod=viewthread&tid=9207&page=2#pid62287

Most probably using the same super simple patch as for A20 legacy kernel (we wrote in linux-sunxi wiki what's necessary ages ago). You might ask in official Banana forum how to do this since not many people here are willing to waste their time with Bananas these days. Besides that using a PM behind such an ultra slow SATA port without the ability to use PMs that support FIS based switching is a bad idea anyway. Wrt good Linux distros you have to differentiate: one thing is kernel stuff (grab one of their latest images since in the meantime the Banana folks don't stupidly refuse to accept community patches any more, so with their most recent images you get at least kernel 3.10.107 and the most severe stability problems of this platform fixed), the other is userland. If I would have to use such a Banana I would combine this kernel with a fresh Armbian rootfs. But the Banana manufacturer's CEO could finally convince me to stay away from their products forever

Exactly. M2 Ultra is not supported and this huge bunch of totally incompatible Bananas all with M2 in their name is just that: incompatible to each other. So you can't boot any M2 image on a M2+, M2U, M2M, M2 Berry or Zero of course. That's not an Armbian problem, that's a naming problem and hardware incompatibility (all these boards/SoCs need different bootloaders/kernels at the time of this writing -- only exceptions: M2+ and M2 Zero software is interchangeable, same with M2 Ultra and Berry). Wrt Armbian and Bananas: We support the real Bananas (A20 based M1/Pro) in every regard (only Lamobo R1 support phased out in the meantime since support nightmare) We support A31 based M2 for historical reasons since vendor's 'official OS images' were absolutely unusable while at that time back then most buyers weren't aware that more recent Bananas have nothing in common with the good original Bananas We support H3 based M2+ since 'just another H3 board' and it looked easy to add support (we learned only later that this vendor sent us partially defective dev samples, provided/provides wrong schematics and we couldn't rely on his 'technical documentation' since wrong as usual, GPIO pin mappings for example were just 'copy&paste gone wrong' for which this vendor has become famous in the meantime) End of Banana journey for now. BTW: if you bought the M2 Ultra for SATA you most probably fooled yourself since Allwinner SATA is still horribly slow SATA Check review of M2 Berry (same as M2 Ultra just with less memory/features but as a compensation stupid powering problems added) and how other even more affordable boards perform (here, here, here).

And please ask them to consider being compatible to the rest of the (Linux) world using thermal_zone0. Most probably still using thermal_zone1 is for backwards compatiblity since they had it that way on their 4.4 kernel already (a tribute to badly written software expecting things at hardcoded locations). But since every software/script out there naively expects CPU temp available as thermal_zone0 it would be better to become compatible to this (even more a tribute to badly written software expecting things at hardcoded locations )

3 attempts with freshly built images, the first two with btrfs (no boot but panic), now with ext4 I've no network. And a f*cked up screen setup so serial console logs are trashed too. Will look into it tomorrow. And thanks for the diagnose/fix!

Not really necessary. It's just that we now have exactly two exceptions from the general rule (thermal_zone0): the smelly Allwinner A20 legacy kernel and surprisingly both kernel variants for RK3288 (the two S500 boards not counted since deprecated fortunately in the meantime). But honestly I don't really mind any more now that it's just two exceptions and not like a year ago only exceptions and no generic rule.

Which one is the right syfs node for CPU cores with mainline kernel? I thought the kernel you're using would follow the general rule to expose 'CPU temperature' as thermal_zone0 by default? @TonyMac32 or @Mike C: do you have the Tinkerboard running with 4.12 currently and can have a quick look?

Me not since I use GNU tar everywhere and stuff like the following is all that's needed to speed up unpacking of Linaro toolchains (the only remaining tar call where this would improve speed a little bit in Armbian's build system so it's not worth the efforts anyway): macbookpro-tk:build tk$ PXZ=$(which pxz 2>/dev/null) && alias tar="tar --use-compress-program=${PXZ}" macbookpro-tk:build tk$ type tar tar is aliased to `tar --use-compress-program=/usr/local/bin/pxz' Besides that as Zador already explained complicating the host setup is not an option and without huge refactoring we won't gain that much speed improvements anyway since stuff like parallelism is already used where possible. And for experienced users it's always possible to make use of nice FS features (I for example have both cache/sources and cache/toolchains symlinked from a btrfs force-compression=zlib partition allowing me to save a lot of disk space without hurting performance)

Or H3Droid.

Unfortunately you constantly confuse or mix up two totally independent tools: 1) armbianmonitor This tool is (mis)used for various actions, it prints its capabilities simply by calling it without arguments and its monitor mode looks like this: root@clearfogpro:/usr/local/src/smartmontools# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU 13:26:31: 800MHz 0.40 1% 0% 1% 0% 0% 0% 70.8°C 13:26:36: 800MHz 0.36 1% 0% 1% 0% 0% 0% 70.4°C 13:26:42: 800MHz 0.33 1% 0% 1% 0% 0% 0% 70.8°C 13:26:47: 800MHz 0.31 1% 0% 1% 0% 0% 0% 71.3°C There are two issues: The '%cpu %sys %usr %nice %io %irq' values are wrong on some/many kernels: https://github.com/armbian/build/issues/728 Temperature reported might be wrong (since we use an exception for RK3288 legacy kernel now that will be wrong when running mainline) but this needs to be addressed in the prepare_temp_monitoring function in /etc/init.d/armhwinfo. I'm pretty sure this here needs an adjustment with mainline kernel running on RK3288 devices (though I would prefer a patch for legacy kernel and removing the exception) 2) RPi Monitor This tool is not even part of Armbian (but an outdated version can be installed with armbianmonitor -r for convenience reasons and to ease supporting people that work on a new board and want to optimize thermal/dvfs settings). I simply threw the few templates I created the last years into the repo. Original idea was to make this work with armbianmonitor-daemon (a 3rd tool we better don't talk about since nothing happened within the last 18 months) but in the meantime this was more or less 'backing up to the Internet'. If people want to contribute they could make the '%cpu %sys %usr %nice %io %irq' values displayed in armbianmonitor working everywhere, also a Tinkerboard or MiQi owner could try to address wrong temperature (I personally would prefer a fix for the legacy kernel so that this old kernel we won't deal in 2018 any more with uses same sysfs nodes as mainline kernel!) but that's not related to any release (policy). And anyone contributing should be aware that armbianmonitor is tweaked constantly while only being updated from time to time as part of 'board support packages' so before you even start replace the armbianmonitor script in your local installation with latest version on Github.

Can you please post the output of 'psd p' please (should look like https://wiki.archlinux.org/index.php/profile-sync-daemon#Preview_.28parse.29_mode and I'm interested in activation mode and overlayfs size)

Well, my build times won't improve with a 'build farm' or something like that but only with a huge refactoring of Armbian's build system which won't happen anytime soon or at all. Maybe better read through former discussions/approaches first? https://forum.armbian.com/index.php?/topic/1942-ok-runtime-835-min-time-for-upgrade/ https://forum.armbian.com/index.php?/topic/1660-420-build-tools-testing-for-improvements-andor-documentation/ https://forum.armbian.com/index.php?/topic/1379-would-a-vastly-reduced-build-all-time-aid-the-project/

Well, I'm surprised why people expect $anything from TV boxes. These things aren't for Linux enthusiasts but for clueless people that only buy numbers (8 CPU cores vs. 4 cores --> 8! 2 GB DRAM vs. 3 GB DRAM --> 3! $30 vs. $28 --> 28!). They have to look performant by specs while they have to be as cheap as possible for their target audience to buy them. Why does someone think both can work at the same time? This means manufacturers don't have to take care about performance but only about cluelessness (use 8 cores even if it's totally useless since the competitors also use 8 cores now so you are not able to sell faster boxes with less CPU cores anymore in the markets where they make money, put recycled DRAM on the PCB and combine it with an u-boot that dynamically tunes DRAM clockspeed down until the box doesn't immediately crash so you as manufaturer can afford putting 3 GB crappy/slow DRAM on board since customers would never buy your box with 2 GB faster DRAM) And then this kind of 'cheating' also happens everywhere. Don't know exactly how it works with Amlogic (since I consider all their SoCs not worth a look, might change if a dev board relying on Amlogic A113D appears) but I know how it's done with Allwinner and there it's easy: the 'board support packages' (BSP) TV box vendors get contains a kernel with a list of cpufreq operation points (that's the entire 'up to x.x GHz' thing) that does not need to have any relationship with reality (Allwinner sets 1536 MHz here for A64 as an example). Then there are other settings defining how voltage and clockspeed relates (DVFS) and then there's another settings defining thermal behaviour. The result is that the TV box will be marketed as 'up to 1.5GHz', the real settings already prevent everything above 1152 MHz and due to shitty thermal design of most boxes the SoC won't even see those 1.1GHz when running under constant load since already throttled down to less than 1 GHz. And their target audience is happy since in Android's CPU-Z and stupid benchmarks like Geekbench '4 cores @ 1536 MHz' is listed and that's all they care about, IMO interesting read: https://www.cnx-software.com/2017/09/12/factory-price-of-some-tv-boxes-and-accessories/#comments

Ok, will try this out soon! Thank you.

In my environment (depends on the router box that is both DHCP server and assigns itself as DNS resolver) a simple 'ssh nanopineo2' would already be sufficient (since Armbian sets the board name as hostname, the DHCP client tells the server this name and the DHCP server hands this information over to the DNS server running on the same machine). An alternative to list also most non-Armbian hosts that works on macOS: 'ping -c3 192.168.83.255 ; arp -a' (192.168.83.255 being the broadcast address of my lab network, of course the little script I use does a bit more getting this stuff dynamically querying the networksetup tool included in macOS). In the past I also thought about announcing on first boot a simple Bonjour registration of type 'Your new Armbian host ready to login' but since most users don't know Bonjour/ZeroConf and most network admins even hate it...

No, just unlucky for whatever reasons when trying to order these two items. No hassles so far with all the other stuff I ordered there. But to be honest: If I order stuff for $2 from the other end of the world I do not really expect that everything works flawlessly or at all. There's also a lot of curiosity involved why I try Aliexpress again and again

Well, I would prefer the least hackish attempt but fear I can't help much since I've no serial cable for my C1+ / C2 (as I understood the serial cable for XU4/HC1 is not compatible to the other boards since 1.8V vs. 3.3V)?

Both. Ordered on Aliexpress, then some stuff arrived I've not ordered (electronics I've not the slightest idea what they do) and weeks later I realized that adapters/antenna will never arrive since they obviously sent wrong stuff. So ordered again. Very low priority task since Feb 2016: testing Clearfog Pro with 3 native SATA SSDs -- still not managed to do this. Same with 3 antennas with u.FL to SMA cables. First order canceled by seller, 2nd never received, then got distracted somehow

Before. And highly frustrated that day since wasted hours already due to stupid mistakes I made and some unfortunate decisions (build host related). Boot failure --> putting XU and HC1 in the drawer waiting for you finalizing armbianEnv.txt vs. boot.ini stuff. Only positive result from this day back then was the finding that symlinking cache/sources and cache/toolchains from a btrfs force-compression=zlib partition doesn't hurt performance wise (while savong over 100% needed storage)