tkaiser

All PSUs eventually die so if this power adapter is already a few years old most probably it's the culprit. Wrt your requirements any board (even an el cheapo Orange Pi Zero or a NanoPi NEO) will do. Pi Hole has zero hardware requirements, Plex Media Server the same if transcoding is not needed. Depending on the count of Docker containers you need a sufficient amount of DRAM though. Not entirely: https://forum.armbian.com/topic/6171-odroid-hc1-sata-disk-switches-between-sda-and-sdb/ Another possibility is the N1 never happening since too expensive.

You would do it that way: extraargs="maxcpus=4" extraargs="mem=1G" extraargs="maxcpus=1 mem=1G"

Totally wrong. The original bl30.bin blob provided by Amlogic/Hardkernel for the C2 was just the usual cheating mess Amlogic is known for. Just read the thread you are posting to to get the details. Hardkernel is obviously the only vendor around able to provide a bl30.bin blob that does not cheat on users. All other Amlogic board vendors are not in that position. Confirmed by your mhz tool. It's 1.8 GHz even with full load on all CPU cores. With Allwinner's legacy kernel all that's needed is to understand their 'budget cooling' stuff to get the idea how to influence cpufreq limits imposed by thermal constraints. With mainline kernel there are no limitations whatsoever. Unlike with Amlogic cpufreq/dvfs is fully under our control (not talking about H6 here since code yet not ready, the above only applies to all other Allwinner SoCs so far)

I know but the only purpose of these quick measurement was to show how important a stable PSU and especially the Micro USB cable is when a board encourages its users to power through Micro USB (as it's the case with all FriendlyELEC boards even if all of them are also able to be powered via a 4 pin header). And this was the interesting observation: With such an artificial high load as cpuburn-a53 consumption at the wall exceeded 14W which simply means that FriendlyELEC's provided Micro USB cable solves a lot of the Micro USB related powering problems due to very low resistance. At least the cable problem avoding the usual horrible voltage-drop with 'average USB cables'. The other problem still remains: users choosing insufficient USB chargers or PSUs that result in a voltage drop under load on their own. But it's even worse: I could watch consumption increase with increasing SoC temperature, IIRC at 1300 MHz consumption difference was ~1W depending on SoC temperature at 50°C or 90°C (with huge fan then board idled at ~35°C so the increase in temperature was just waiting 30 seconds -- cpuburn-a53 is really a beast)

...which are both 5V pins (6 would be GND).

Thank you. I just repeated the test while limiting my NanoPi Fire3 to 1200 MHz with zram/lz4 and vm.swappiness=100 (/etc/sysctl.conf): 51m34.139s (and with lzo it was 50m30.884s -- so again with this workload no advantage for lz4 for whatever reasons) But since we know that Vim2 unfortunately relies on an Amlogic SoC with cheating firmware blob (fake clockspeeds) the only reasonable way to get a real comparison would be you repeating the test twice: First time with purged zram-config package and commented swap entry in fstab to force the board to do no zram paging at all Then again this time with the Vim2 limited to 1 GB DRAM ('mem=1G' added to kernel cmdline), setting up vm.swappiness=100 and activating zram with the following modified activate_zram routine in /etc/init.d/armhwinfo (needs to be uncommented of course too): Edit: Added lzo numbers above.

Thank you. But for the target audience needing to read this first it's unfortunately invisible (two black bars somewhere with small white text they never read).

Seriously?

In the past we had displayed on top of every single technical support subforum a link explaining 'most common issues' (power supply and SD card crappiness). This is gone now. Why exactly?

This has been discussed already in this thread. We could enable this on our own (and make it configurable in a sane way) but the way it's prepared by me (as part of our armhwinfo script) is not a good idea. So it would need someone to split all the armhwinfo functionality into different parts that can also be configured by the user. Also our current policy with vm.swappiness=0 is something that could be discussed/changed or at least be configurable by the user in an easy way. But since at least I have not the slightest idea in which direction Armbian is moving and since I have a hard time understanding for what time is wasted and especially since i really hate to waste my own time with stuff I don't like (e.g. trying to repair broken patches or insecure scripting) I simply do not care any more. Same with 'speed' of progress. I started with this zram journey over one year ago, wasted my time to analyze 'armbianmonitor -u' output from various installations, waited another few months whether there are complaints from Ubuntu users about zram now being active (I'm not aware of a single one) and would like to see better usage of RAM rather sooner than later. But as it's today I simply don't care any more since all this stuff simply feels like time wasted.

Just spotted another important difference between NanoPi M3 and Fire3: 'AXP288 PMIC is gone, and replaced by an STM32 Cortex M0 MCU'. So DVFS implementation is different which also explains why with Armbian there's no difference in idle consumption/temperature when clocking with 400 vs. 1400 MHz.

This little and inexpensive ($35) board is fully compatible to discontinued NanoPi M3. From a software point of view both boards are identical (though Wi-Fi is missing on the Fire3) and as such identical OS images can be used for both boards. The good news: compared to the last time I looked at the M3 kernel support has improved a lot. Back then we had to run a smelly 3.4.39 (32-bit only) while we can now run mainline on it. I gave it a try using our Armbian Stretch nightly running with 4.14.40 (full armbianmonitor -u output) and did a couple of tests. The Samsung/Nexell S5P6818 SoC consists of 8 A53 cores running at up to 1.4GHz with default settings (can be slightly overclocked up to 1.6 GHz according to Willy Tarreau -- see the reviews at the product page). All cores behave like one big cluster (so adjusting /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq affects all 8 CPU cores at once, this is no artificial pseudo big.LITTLE as Amlogic does it with their S912). Now with a recent 64-bit kernel with the CPU cores brought up in ARMv8 mode we can also make use of ARMv8 Crypto Extensions making the S5P6818 to one of the most powerful boards when it's about AES crypto and stuff can run on all 8 cores in parallel (33 times faster than a RPi 3 and still 28 times faster than a RPi 3+). While the octa-core config sounds interesting for CPU intensive workloads one should keep in mind that this board has only 1 GB DRAM which is simply not enough for many such workloads (or you would need to make massive use of zram instead which performs better than swap on slow storage but of course bottlenecks a lot). Talking about a somewhat powerful CPU we also have to talk about temperatures and consumption. The board is always part of a kit so FriendlyELEC sells it together with a heatsink and a high quality Micro USB cable that solves a lot of the Micro USB related powering problems. In idle I measured 2.6W with Armbian (PSU included at the wall) while Willy Tarreau reported 'It consumes 400mA/5V in idle, and 1.2A/5V under openssl RSA with 8 cores at 1.6 GHz' (most probably using FriendlyELEC's OS image). So I tested for consumption with worst case workloads and used cpuburn-a53 for this. Since I knew from last time when I tested that the board deadlocks when starting cpuburn-a53 at 1.4 GHz I increased max cpufreq in steps (consumption always with PSU included): 1000 MHz: 9.3W 1100 MHz: 10.7W 1200 MHz: 12.2W 1300 MHz: 13.8W 1400 MHz: 14.7W After a short time with cpuburn-a53 running at 1.4 GHz the board deadlocked again which is not a surprise since my PSU is rated for 2A (10W) and Micro USB itself is only rated for 1.8A (9W). As usual with FriendlyELEC boards there's a 4 pin header for serial debug console that can also be used to power the board more reliably so even demanding tasks that increase consumption to 15W are possible when powering through the header. Talking about temperatures: After applying the heatsink I did a simple compile test (Arm Compute Library) with -j8 and after a minute the board did an emergency shutdown since CPU temperature reached 100°C. So all following tests were done with a huge fan blowing air over the heatsink laterally. IMO for demanding tasks improved airflow / heat dissipation is a must and the small heatsink simply not sufficient. What other hardware is there? The usual 40 pin GPIO header, Gigabit Ethernet (with Armbian's settings and mainline kernel we're talking about iperf3 numbers of ~925 Mbits/sec in both directions), a mini HDMI port (most probably supported by Armbian), a camera and a LCD port (both not supported by Armbian as far as I know), the Micro USB OTG port and a single USB2 type A port. USB Attached SCSI (UAS) is yet not available with mainline kernel so storage performance is a little lower as it could be. This is a Samsung EVO840 in an ASM1153 enclosure connected to the USB2 port: random random kB reclen write rewrite read reread read write 102400 4 7544 9889 10098 10117 7996 9770 102400 16 16143 20165 20365 20260 19858 20172 102400 512 33138 33659 33120 33373 33417 33321 102400 1024 33511 33663 33429 34020 34119 33521 102400 16384 32731 34012 36483 36750 36674 34291 I also did a quick test as NAS and got numbers as expected: everything a little bit slower compared to those USB2 platforms that can make use of UAS -- so if NAS is the use case some of the cheaper Allwinner boards with Gigabit Ethernet are a better idea. As usual FriendlyELEC did a great job documenting the board: http://wiki.friendlyarm.com/wiki/index.php/NanoPi_Fire3 -- they also provide OS images that make full use of all hardware features (camera, LCD displays auto-detected by u-boot, GPU/VPU acceleration, HDMI resolution switching in Linux sounds a bit like PITA though). Still not sure for which use cases this board applies. The octa-core CPU would better be accompanied by more DRAM (though then you need to get the NanoPC-T3 Plus -- same SoC but 2 GB DRAM) and I fear making use of the processor power almost always requires a fan blowing in addition to the heatsink (without a fan I measured in idle always +60°C after a few minutes)

And just a waste of time...

Follow-Up on https://www.cnx-software.com/2018/05/13/how-to-get-started-with-opencl-on-odroid-xu4-board-with-arm-mali-t628mp6-gpu/  It's about a compile job requiring up to 3 GB memory. Jean-Luc tested on an ODROID-XU4 with 2 GB RAM so he had to add 1 GB swap since otherwise compilation failed. It's 2018 and we all should know that swap on HDD is anachronistic or even stupid. But Linux users still do it since they did it already one or even two decades ago. Time for a 'quick' benchmark: I test on a board that is even more limited with regard to physical RAM: It's a freshly arrived NanoPi Fire3 with eight A53 cores but just 1 GB RAM so very likely to run in out of memory situations with compile jobs running on all 8 cores in parallel. I used an Armbian Stretch image running with kernel 4.14.40 and configured 2.5 GB swap (either as /var/swap or zram). Also vm.swappiness is set to the default (60). When compiling the job I've seen over 2.3 GB swap being used while building with zram with an average 3.5:1 compression ratio: root@nanopim3:/home/tk# zramctl NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT /dev/zram0 lz4 495.3M 370.1M 99.3M 104.5M 8 [SWAP] /dev/zram1 lz4 495.3M 370.2M 99.4M 104.5M 8 [SWAP] /dev/zram2 lz4 495.3M 371.3M 99.8M 105M 8 [SWAP] /dev/zram3 lz4 495.3M 368.8M 99.1M 104.2M 8 [SWAP] /dev/zram4 lz4 495.3M 370.2M 99.4M 104.5M 8 [SWAP] First tests were with zram (trying to compare lzo with lz4), then I used a swap file on ext4 formatted SD card (a fast A1 rated one and not 'the average SD card' showing magnitudes lower random IO performance). Afterwards I tested with an older 7200rpm notebook HDD and then a Samsung EVO 840 both attached via USB2 without UAS support (so both random and sequential IO are bottlenecked by USB2 -- 'typical SBC conditions'). Filesystem used was a freshly created ext4 so no performance difference between swap file and partition. Benchmark execution as follows: I deleted the working directory, then untared the archive (see above) and then let the following run: time scons Werror=1 -j8 debug=0 neon=1 opencl=1 embed_kernels=1 os=linux arch=arm64-v8a build=native Results: zram lzo 46m57.427s zram lz4 47m18.022s SSD 144m40.780s SanDisk Ultra A1 16 GB 247m56.744s HDD 570m14.406s Using zram is a no-brainer. The job finished within 47 minutes with both lzo and lz4 compression scheme. When testing with swap on real storage for obvious reasons the SSD won (best random IO performance), then the A1 rated SD card could finish the job in 4 hours and of course swap on HDD failed miserably since spinning rust simply sucks when it's about random I/O performance. Swap on HDD is BS. A device with 1 GB physical DRAM is able to perform a build job requiring 3 GB memory within 47 minutes when using modern approaches (zram), when doing it like we did it last century (swapping to storage) then it's all about random I/O performance. A great performing SSD even if bottlenecked by USB2 is able to finish the job in less than two and a half hours. An el cheapo SanDisk Ultra A1 SD card with 16 GB scores 4 hours while as expected a 7.2k notebook HDD takes almost 10 hours to do the same job. HDDs suck at random IO. Period. What can we learn from this? Nothing since Armbian is only focused on adding more and more irrelevant boards to the build system instead of improving situation for all boards. As a reference iozone numbers for the 3 storage scenarios: SanDisk Ultra A1 random random kB reclen write rewrite read reread read write 102400 4 3677 3856 9344 9320 8070 2787 102400 16 3890 7780 16398 16216 14832 6716 102400 512 9925 13902 22494 22501 22411 13178 102400 1024 13826 13750 22651 22649 22640 13792 102400 16384 14031 13936 23141 23137 23163 15395 Hitachi 2.5" 7200 rpm random random kB reclen write rewrite read reread read write 102400 4 7537 9837 8016 7763 671 1119 102400 16 17452 20618 20852 20997 2522 4250 102400 512 33123 33403 34165 34756 25589 32262 102400 1024 33580 33310 34331 35056 29620 33148 102400 16384 32592 33804 34921 35591 35277 33838 Samsung EVO 840 SSD random random kB reclen write rewrite read reread read write 102400 4 7322 9481 9636 9682 7433 9496 102400 16 16654 19453 18576 18639 18301 19370 102400 512 31296 31489 32778 32876 32977 31337 102400 1024 31016 31986 33334 34283 33991 31273 102400 16384 30600 31336 33318 33678 33236 31913

For no reason. No idea why the board has been added at all. It made absolutely no sense to add a broken and untested patch to the build system. One of the many reasons contributing to Armbian got so frustrating.

@Da Xue, may I remind you on this?

Exactly. And everyone has 'to go through an apt upgrade process' since this is the way u-boot and kernel are updated. The current image is not deprecated but unmaintained (no testing, no further development) and unsupported (no support questions answered like yours now )

More or less irrelevant since btrfs is a modern filesystem utilizing modern concepts. E.g. 'checksumming' to ensure data integrity. This does not only 'waste' CPU cycles but results also in higher storage activity for the same tasks (since checksums have to be calculated, written, read, verified). E.g. Copy-on-write (CoW) which directly affects performance of write patterns that are of the same size or less than the filesystem's block size (usually 4K or larger) since now every write is in reality a 'read, modify, write' cycle since already existing data needs to be read from disk, then the new stuff will be added and then the modified block will be written to a new location and only afterwards the old reference deleted. That's why btrfs and other CoW filesystems in all benchmarks writing small chunks of data shows horribly low performance. Same when running database benchmarks on btrfs with defaults --> horrible performance as expected since a CoW filesystem is nothing you want to put database storage on (and if you disable CoW in btrfs then also checksumming is gone and then you're better off using ext4 or XFS anyway) The (in)famous clickbait site dedicated to provide only numbers without meaning (Phoronix) periodically 'benchmarks' various filesystems inappropriately so if you're after numbers visit https://www.phoronix.com/scan.php?page=article&item=linux414-fs-compare and similar posts. Unfortunately not since passive benchmarking ('fire and forget' mode) never works. It only provides numbers without meaning and nice looking graphs but zero insights. With storage benchmarks as with every other benchmark only 'Active benchmarking' works. And that requires some understanding, a lot of time and the will to throw away most of your work (+95% of all benchmark results since usually something goes wrong, you have to find out what and then repeat). Almost nobody does this. On every benchmarked host but especially on SBC with their weak ARM CPU cores and limited resources you always need to monitor various resources in parallel (htop, 'iostat 5', 'vmstat 5' and so on), switch at least to performance governor, take care about process and IRQ affinity (watching htop) especially on those boards with big.LITTLE implementations since otherwise you end up with the usual passive benchmarking result: Casual benchmarking: you benchmark A, but actually measure B, and conclude you've measured C. Next problem: if you generated numbers it's about to generate insights from these numbers. Recently someone showed me this link as a proof that bcache in Linux would be a great way to accelerate HDD access by using SSDs: http://www.accelcloud.com/2012/04/18/linux-flashcache-and-bcache-performance-testing/ True or not? What do the numbers tell? While almost everyone looking at those numbers and graphs will agree that bcache is great in reality it's exactly the opposite what these benchmark numbers show. But people ignore this since they prefer data over information and ignore what the numbers really tell them. Back on topic (SBC storage and not filesystem performance): only reasonable way to compare different boards is to use same filesystem (ext4 since most robust and not that prone to show different performance depending on kernel version) and performance governor, eliminating all background tasks that could negatively impact performance and having at least an eye on htop. If you see there one CPU core being utilized at 100% you know that you run in a CPU bottleneck and have to take this into account (either by accepting/believing that a certain SBC is simply too weak to deliver good storage performance since CPU bottlenecked or by starting to improve settings as it's Armbian's or my 'Active Benchmarking' approach with benchmarks then ending up with optimized settings --> there's a reason 'our' images perform on identical hardware sometimes even twice as fast as other SBC distros that don't care about what's relevant)

Sure. It's even part of Autonegotiation (part of GbE standards). So if the switch doesn't support to adjust settings and performance degradation happens the only way to solve the problem is to replace the switch with another one that allows to enable flow control there (managed switches should allow for this and the majority of 'smart managed' too). I would first do a primitive test with iperf3 in the local net and speedtest if there's fast Internet connection to see whether it's an issue in reality (could become an issue with high latency connections like Internet access)

Nope since the same happens when testing with a normal HDD or SSD as well (see numbers and comment here). With btrfs writes and iozone the -I switch (direct IO) has no meaning and this is testing filesystem buffers in reality. That's why the numbers are higher. You simply can't use iozone -I to test btrfs writes but you would need to adjust the test filesize to 3 or 4 times the amount of DRAM to eliminate filesystem buffers. Just another example that you always have to benchmark the benchmark first to be able to generate insights from it. Two more notes: Almost all btrfs code lives inside the kernel so different kernels --> different behaviour and performance possible Doing such tests without switching first to performance cpufreq governor always only produces numbers without meaning since cpufreq governor behaviour especially with small accesses can become a significant factor (different fs might result in different cpufreq scaling behaviour so while this is interesting too it doesn't tell about 'filesystem performance')

Nope, please look at the details and how storage works. The 1.6GB/s above are just a confirmation that RK3399 has no crippled internal bandwidth (Hardkernel assumed such thing and designed their ODROID N1 around that assumption RK3399's PCIe implementation would be bottlenecked to 400 MB/s or something like that). These 1.6GB/s are just the proof that an x4 Gen2 connection can be established with RK3399 (4 x 5 GT/s with 8b10b encoding) and that a NVMe (!!!) SSD shows nice high bandwidth numbers. NVMe is not a protocol from stone age (like SATA/AHCI), it's made for modern CPUs with multiple cores. If you attach an old SATA or SAS controller to the PCIe bus you will run into IRQ affinity issues for sure and you have to keep in mind that you're now using the PCIe bus to talk to an own storage controller that implements protocols from last decade/century made for single CPU core systems with spinning rust connected (that's what SCSI, PATA, SATA, AHCI is all about). Lots of overhead and inefficiency involved now and when you then also try to combine a bunch of disks in special ways (e.g. RAID which is in my opinion a really stupid setup at home) performance will again drop drastically. RK3399 is a general purpose ARM SoC and not a NAS SoC. Those exist though -- look at Marvell Armada 7k/8k for example. These SoCs differentiate between AP (application processor, that's the part with ARM cores) and CP (communcation processor(s)) and all the relevant work is offloaded on the CP. That's why they're fast as NAS. BTW: RK3399 and PCIe GPUs won't work but please no off-topic discussions here. Let's focus on storage performance on SBC and try to avoid flooding this thread with babbling. So many 'educational' threads here meant as a tutorial to share knowledge have already been destroyed by babbling.

This one is funny. The Kconfig talks about 'eMMC module socket, MicroSD Card slot, Pi-2 Bus, Pi-P5+ Bus, USB 3.0 and many others peripheral devices interface for makers'. Weird language and there's no 'Pi-P5+ Bus' on this board but ROCK64 is providing another 22 pin header inspired by the old RPi P5 header. The Kconfig text for this Renegade board is simply copy&paste of Rock64 product page typos included Also I asked 5 weeks ago for the necessary blobs but to no avail. Obviously having the device vendor 'on board' here doesn't help that much with Libre Computer hardware The only real difference is DDR4 vs. DDR3 memory but as we already learned DDR4 is not automagically faster, also often higher memory bandwidth is accompanied by higher latency so I wouldn't call DDR4 automatically an advantage (only for media streaming use cases -- using an SBC as TV box). For obvious reasons I do not trust in the memory bandwidth numbers published here any more (also there's only memcpy/memset mentioned but no word about latency). And then there's Micro USB for DC-IN... how should this work with a connected USB3 disk that wants to be powered by the host (many popular external 2.5" USB3 disks do this)?

Seriously? Please report back in a day whether it's really fixed or if you now just get different error messages reporting the same (underlying) problem (see issue 7 here). The ASM1153E with original ASMedia firmware is known to be fully UAS capable. If your problem is not related to UAS please also correct the various posts on stackexchange.com. One reason so many Linux users think UAS would always cause issues is the vast amount of wrong reports on the Internet people stumble accross once they google for the error messages they run into.

@TonyMac32 so does reading out the temperature with e.g. armbianmonitor works now after this commit?

If you read through the other thread closely you'll realize that there's nothing related to temperatures. It's just some proprietary closed sourced code running on an own MCU inside the SoC controlling the clockspeeds, ignoring the cpufreq framework running in the Linux kernel and reporting bogus values back to the kernel. It's Amlogic you're dealing with. The benchmarks @Da Xue did a while ago clearly demonstrate this: https://libre.computer/2018/03/21/raspberry-pi-3-model-b-review-and-comparison/ (see the openssl numbers. If S905X would be running at 1.5 GHz as claimed the openssl scores need to be much better compared to RK3328, but this is an indication that the code running on the M3 Core simply does what it wants while cheating on the kernel and reporting wrong cpufreq clockspeeds while running lower in reality.)