tkaiser

Not only you tested it but thousands of OpenMediaVault users (the majority on the Raspberry Pi) since I did exactly the same in our OMV images for ARM boards.
 
But this is not the recommended way any more, lz4 for whatever reasons performs not greater than lzo but it would be great if you can join testing efforts.
 

This is something hopefully suitable to become a 'Board Bring up' thread.
 
The NanoPC T4 was the smallest RK3399 board around featuring full set of interfaces (Rock960 was smaller but there you can't use GbE without a proprietary expander) but in the meantime he got two smaller siblings: NanoPi M4 and the cute NEO4.
 
Pros:
Another RK3399 board so software support is already pretty mature Rich set of interfaces (2 x USB2 without shared bandwidth, 2 x USB3, triple display output and so on) No powering hassles due to 12V (2A) PSU requirement 16GB superfast eMMC 5.1  Usable and performant Wi-Fi (dual band and dual antenna so MIMO can be used, for numbers see here) All 4 PCIe lanes exposed (M.2 M key connector on the bottom, suitable for NVMe SSDs, or to attach a 4 port SATA controller or a PCIe riser card)  
Cons:
A bit pricey (but if you compare with RockPro64 for example and order all Add-Ons you end up with a similar price) High idle consumption (4W PSU included in idle), maybe this is just bad settings we can improve over time heatsink too small for continous loads  
I started relying on @hjc's work since he's currently using different kernels than we use on RockPro64 or ODROID-N1 (though all the 4.4 kernels are more or less just RK's 4.4 LTS branch with some modifications, with mainline I didn't had a look what's different in Heiko's tree and 'true' mainline).
 
Tinymembench numbers with RK 4.4 vs. mainline kernel (the latter both showing lower latency and higher bandwidth).
 
Internal 16 GB eMMC performance:
eMMC / ext4 / iozone random random kB reclen write rewrite read reread read write 102400 4 23400 28554 26356 26143 27061 29546 102400 16 48364 48810 85421 85847 84017 47607 102400 512 48789 49075 273380 275699 258495 47858 102400 1024 48939 49053 290198 291462 270699 48099 102400 16384 48673 49050 295690 295705 294706 48966 1024000 16384 49243 49238 298010 298443 299018 49255 That's what's to be expected with 16 GB and exactly same numbers as I generated on ODROID-N1 with 16 GB size. When checking SD card performance it maxed out at 23.5 MB/s which is an indication that no higher speed modes are enabled (and according to schematics not possible since not able to switch to 1.8V here -- I didn't try to adjust DT like with ODROID-N1 where SDR104 mode is possible which led to some nice speed improvements when using a fast card -- see here and there)
 
Quick USB3 performance test via the USB-3A port:
Rockchip 4.4.132 random random kB reclen write rewrite read reread read write 102400 4 24818 29815 33896 34016 24308 28656 102400 16 79104 90640 107607 108892 80643 89896 102400 512 286583 288045 285021 293431 285016 298604 102400 1024 315033 322207 320545 330923 320888 327650 102400 16384 358314 353818 371869 384292 383404 354743 1024000 16384 378748 381709 383865 384704 384113 381574 mmind 4.17.0-rc6-firefly random random kB reclen write rewrite read reread read write 102400 4 37532 42871 22224 21533 21483 39841 102400 16 86016 104508 87895 87253 84424 102194 102400 512 274257 294262 287394 296589 287757 304003 102400 1024 294051 312527 317703 323938 323353 325371 102400 16384 296354 340272 336480 352221 339591 340985 1024000 16384 367949 189404 328094 330342 328136 139675 This was with an ASM1153 enclosure which shows slightly lower numbers than my usual JMS567 (all currently busy with other stuff). Performance with RK 4.4 kernel as expected, with mainline lower for whatever reasons. I also tried to test with my VIA VL716 enclosure directly attached to the USB-C port but ran into similar issues as with RockPro64 but since my enclosure and the cable also show problems when using at a MacBook Pro I suspect I should blame the hardware here and not USB-C PHY problems with RK3399.
 
This is NanoPC T4 with vendor's heatsink, lying flat on a surface that allows for some airflow below, running cpuburn-a53 on all 6 cores after half an hour:
13:57:31: 1008/1416MHz 8.44 100% 0% 99% 0% 0% 0% 91.1°C 0/5 13:57:40: 1008/1416MHz 8.52 100% 0% 99% 0% 0% 0% 91.1°C 0/5 13:57:48: 1008/1416MHz 8.51 100% 0% 99% 0% 0% 0% 91.1°C 0/5 13:57:57: 1200/1416MHz 8.47 100% 0% 99% 0% 0% 0% 90.6°C 0/5 13:58:05: 1200/1416MHz 8.47 100% 0% 99% 0% 0% 0% 91.1°C 0/5 So with heavy workloads you most probably need a fan to prevent throttling. 
 
Development related questions: IMO we should try to rely on single sources for all the various RK3399 boards that are now available or will be soon. And I would prefer ayufan's since he's somewhat in contact with RK guys and there's a lot of great information/feeback provided by TL Lim. What do others think?
 
Also an issue is IRQ affinity since on boards where PCIe is in use those interrupts should clearly end up on one of the big cores while on other boards USB3 and network IRQs are better candidates. I already talked about this with @Xalius ages ago and most probably the best idea is to switch from static IRQ affinity set at boot by armbian-hardware-optimization to a daemon that analyzes IRQ situation every minute and adopts then dynamically the best strategy.
 
Wrt information for endusers. All RK3399 boards basically behave the same since the relevant stuff is inside the SoC. There's only different DRAM (matters with regard to consumption and performance), different interfaces exposed and different power circuitry (and obviously different settings like e.g. cpufreq behaviour but I think we should consolidate those for all RK3399 boards). So you already find a lot of information in my ODROID-N1 'review', my SBC storage performance overview and most probably also a lot around RockPro64. No idea where to inform about RK3399 GPU/VPU stuff since not interested in these areas at all (hope others add references or direct information).

NanoPi-M4 is RK3399 based too, just no eMMC on board, and no so many interface as NanoPC-T4 So a little lower cost.
 
 

My 2 cents on this at the bottom of the list: https://github.com/armbian/build/pull/1015
 
Can't really test/review at the moment since running out of spare time. My only other 'Armbian contribution' this week will be a little bit NanoPC T4 testing (relying on @hjc's work).

Preliminary 'performance' summary
 
Based on the tests done above and elsewhere let's try to collect some performance data. Below GPU data is missing for the simple reason that I'm not interested in anything GPU related (or attaching a display at all). Besides used for display stuff and 'retro gaming' RK3399's Mali T860 MP4 GPU is also OpenCL capable. If you search for results (ODROID N1's SoC is available for some years now so you find a lot by searching for 'RK3399' -- for example here are some OpenCL/OpenCV numbers) please keep in mind that Hardkernel might use different clockspeeds for the GPU as well (with CPU cores it's just like that: almost everywhere around big/little cores are clocked with 1.8/1.4 GHz while the N1 settings use 2.0/1.5 GHz instead)
 
CPU horsepower
 
Situation with RK3399 is somewhat special since it's a HMP design combining two fast Cortex-A72 cores with four 'slow' A53. So depending on which CPU core a job lands execution time can vary by factor 2. With Android or 'Desktop Linux' workloads this shouldn't be an issue since there things are mostly single-threaded and the scheduler will move these tasks to the big cores automagically if performance is needed.
 
With other workloads it differs:
People wanting to use RK3399 as part of a compile farm might be disappointed and still prefer ARM designs that feature four instead of two fast cores (eg. RK3288 or Exynos 5422 -- for reasons why see again comments section on CNX) For 'general purpose' server use cases the 7-zip scores are interesting since giving a rough estimate how fast a RK3399 device will perform as server (or how many tasks you can run in parallel). Overall score is 6,500 (see this comparison list) but due to the big.LITTLE design we're talking about the big cluster scoring at 3350 and the little cluster at 3900. So tasks that execute on the big cores finish almost twice as fast. Keep this in mind when setting up your environment. Experimenting with cgroups and friends to assign certain tasks to specific CPU clusters will be worth the efforts! 'Number crunchers' who can make use of NEON instructions should look at 'cpuminer --benchmark' results: We get a total 8.80 kH/s rate when running on all 6 cores (big cores only: 4.10 kH/s, little cores only: 4.90 kH/s -- so again 'per core' performance almost twice as good on the big cores) which is at the same performance level of an RK3288 (4 x A17) but gets outperformed by an ODROID XU4 for example at +10kH/s since there the little cores add a little bit to the result. But this needs improved cooling otherwise an XU4 will immediately throttle down. The RK3399 provides this performance with way lower consumption and heat generation! Crypto performance: just awesome due to ARMv8 Crypto Extensions available and useable on all cores in parallel. Simply check cryptsetup results above and our 'openssl speed' numbers and keep in mind that if your crypto stuff can run in parallel (eg. terminating few different VPN sessions) you can almost add the individual throughput numbers (and even with 6 threads in parallel at full clockspeed the RK3399 just draws 10W more compared to idle) Talking about 'two fast and four slow CPU cores': the A53 cores are clocked at 1.5GHz so when comparing with RK3399's little sibling RK3328 with only 4xA53 (ROCK64, Libre Computer Renegade or Swiftboard/Transformer) the RK3399 when running on the 'slow' cores will compete or already outperform the RK3328 boards but still has 2 big cores available for heavy stuff. But since a lot of workloads are bottlenecked by memory bandwidth you should have a look at the tinymembench results collected above (and use some google-fu to compare with other devices)
 
Storage performance
 
N1 has 2 SATA ports provided by a PCIe attached ASM1061 controller and 2 USB3 ports directly routed to the SoC. The per port bandwidth limitation that also seems to apply to both port groups is around 390 MB/s (applies to all ports regardless whether SATA or USB3 -- also random IO performance with default settings is pretty much the same). But this is not an overall internal SoC bottleneck since when testing with fast SSDs on both USB3 and SATA ports at the same time we got numbers at around ~750MB/s. I just retested again with an EVO840 on the N1 at SATA and USB3 ports with a good UAS capable enclosure and as a comparison repeated the same test with a 'true NAS SoC': the Marvell Armada 385 on Clearfog Pro which provides 'native SATA' by the SoC itself:
 
If we look carefully at the numbers we see that USB3 slightly outperforms ASM1061 when it's about top sequential performance. The two ASM1061 numbers are due to different settings of /sys/module/pcie_aspm/parameters/policy (defaults to powersave but can be changed to performance which not only results in ~250mW higher idle consumption but also a lot better performance with small block sizes). While USB3 seems to perform slightly better when looking only at irrelevant sequential transfer speeds better attach disks to the SATA ports for a number of reasons:
With USB you need disk enclosures with good USB to SATA bridges that are capable of UAS --> 'USB Attached SCSI' (we can only recommend the following ones: ASMedia ASM1153/ASM1351, JMicron JMS567/JMS578 or VIA VL711/VL715/VL716 -- unfortunately even if those chipsets are used sometimes crappy firmwares need USB quirks or require UAS blacklisting and then performance sucks. A good example are Seagate USB3 disks) When you use SSDs you want to be able to use TRIM (helps with retaining drive performance and increases longevity). With SATA attached SSDs this is not a problem but on USB ports it depends on a lot of stuff and usually does NOT work. If you understand just half of what's written here then think about SSDs on USB ports otherwise better choose the SATA ports here And PCIe is also less 'expensive' since it needs less ressources (lower CPU utilization with disk on SATA ports and less interrupts to process, see the 800k IRQs for SATA/PCIe vs. 2 million for USB3 with exactly the same workload below): 226: 180 809128 0 0 0 0 ITS-MSI 524288 Edge 0000:01:00.0 226: 0 0 0 0 0 0 ITS-MSI 524288 Edge 0000:01:00.0 227: 277 0 2066085 0 0 0 GICv3 137 Level xhci-hcd:usb5 228: 0 0 0 0 0 0 GICv3 142 Level xhci-hcd:usb7 There's also eMMC and SD cards useable as storage. Wrt SD cards it's too early to talk about performance since at least the N1 developer samples do only implement the slowest SD card speed mode (and I really hope this will change with the final N1 version later) a necessary kernel patch is missing to remove the current SD card performance bottleneck..
 
The eMMC performance is awesome! If we look only at random IO performance with smaller block sizes (that's the 'eMMC as OS drive' use case) then the Hardkernel eMMC modules starting at 32GB size perform as fast as an SSD connected to USB3 or SATA ports. With SATA ports we get a nice speed boost by changing ASPM (Active State Power Management) settings by switching from the 'powersave' default to performance (+250mW idle consumption). Only then a SSD behind a SATA port on N1 can outperform a Hardkernel eMMC module wrt random IO or 'OS drive' performance. But of course this has a price: when SATA or USB drives are used consumption is a lot higher.
 
Network performance
 
Too early to report 'success' but I'm pretty confident we get Gigabit Ethernet fully saturated after applying some tweaks. With RK3328 it was the same situation in the beginning and maybe same fixes that helped there will fix it with RK3399 on N1 too. I would assume progress can be monitored here: https://forum.odroid.com/viewtopic.php?f=150&t=30126

(placeholder for a Board Bring Up thread -- now just collecting random nonsense)
 

 

 
Board arrived today. Running with ayufan's Debian 9 image (using 1.8/1.4GHz settings for the big.LITTLE cores for whatever reasons instead of 2.0/1.5GHz) I checked for heat dissipation with Pine Inc's huge heatsink first. Huge heatsink combined with thin thermal pad shows really nice thermal values:
 
below 50°C when running cpuburn-a53 on two A53 and two A72 cores in parallel with a fan blowing above the heatsink's surface Board in upright positition still running same cpuburn-a53 task without fan after 20 minutes reports still below 85°C even if heatsink orientation is slightly wrong  
Summary: passive cooling is all you need and you should really spend the additional few bucks on Pine Inc's well designed heatsink since being inexpensive and a great performer.
 

You need to adjust DT on your NanoPC since the device claims to be only capable of PCIe Gen1. Please see also https://patchwork.kernel.org/patch/9345861/
 
@FrankM: Would be interesting to test on your RockPro64 with link speed set to 1 and see whether now a x4 link will be established: https://github.com/ayufan-rock64/linux-kernel/blob/65dce4f6760180105cda50d6f8d603e25eaf26fc/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts#L260

(placeholder for a Board Bring Up thread -- now just collecting random nonsense)
 

 

 
Board arrived today. Running with ayufan's Debian 9 image (using 1.8/1.4GHz settings for the big.LITTLE cores for whatever reasons instead of 2.0/1.5GHz) I checked for heat dissipation with Pine Inc's huge heatsink first. Huge heatsink combined with thin thermal pad shows really nice thermal values:
 
below 50°C when running cpuburn-a53 on two A53 and two A72 cores in parallel with a fan blowing above the heatsink's surface Board in upright positition still running same cpuburn-a53 task without fan after 20 minutes reports still below 85°C even if heatsink orientation is slightly wrong  
Summary: passive cooling is all you need and you should really spend the additional few bucks on Pine Inc's well designed heatsink since being inexpensive and a great performer.
 

Like all of those list it's not worth to visit them since they're full of mistakes. That's only for people who are impressed by vast amounts of data and don't give a sh*t about information (data != information).
 
3 examples after looking for ONE MINUTE into this BS collection:
Banana Pi M2 Berry is listed with 4 USB ports while this board in reality just uses one USB host port to provide 4 USB receptacles (shared bandwidth due to internal USB hub). Banana Pi M2 Ultra is also listed with 4 USB ports which is BS since this board has 2 USB receptacles (+ 1 x Micro USB OTG port) and at least exposes all of the USB host ports CubieBoard6/7 is listed as one entry which is OK from a hardware point of view (since the pin compatible S500/S700 SoCs are the only change between both board variants). But under 'OSes' for both boards 'Linux, Android' is listed which is simply BS since Cubieboard 7 with it's Actions Semi S700 SoC is simply an Android toy only. No Linux image has been made available, there's only one smelly 3.10 kernel that receives no updates since a long time any more and the vendor is known for providing horrible software support these days anyway. After spotting that much errors within a minute I stopped and closed the browser tab. It's just a waste of time to look through a huge collection of data providing zero (correct) information. Also the most important factor if you also want to USE a SBC and not just buy one is missing: quality of software support. Everybody should know that 'software support' makes the difference between a SBC and a paperweight or door stop. This collection of (partially wrong) data does not differentiate at all so it's completely useless.
 

Well, every other week the same question is asked here so the mechanism to display a random version number contained in /etc/armbian-release that is part of one specific package that doesn't get updated each time Armbian version number is increased is obviously misleading.

Your installation is on 5.45
 
 
What Armbian displays with Igor's motd stuff is broken. That's all. The motd routine displays a meaningless version number based on one package's version that does not get updated every time Armbian's version number increases. It's only there to confuse people and generate unnecessary support efforts. Don't expect this to be fixed :-)

Allwinner H3 was exciting back in 2015 and early 2016. Allwinner H5 was interesting since still inexpensive but full ARMv8 feature set (especially ARMv8 Crypto Extensions). Basically all H2+, H3 and H5 boards are the same: https://forum.armbian.com/topic/1351-h3-board-buyers-guide/?do=findComment&comment=44979
 
For an Allwinner H device able to draw some attention it needs either to be dirt cheap or needs interesting features like great CPU performance (needs DVFS to go beyond 1.3 GHz) or great amount of DRAM (impossible since 2 GB DRAM are the max) or great graphics capabilities (impossible, only boring Mali 4x0 and limited video engine).
 
The Tritium board (it's just one with 3 different SoCs soldered to it) was designed as an Android TV box without enclosure (closely following Allwinner's current reference design to be able to run their BSP stuff and therefore vendor's Android). No Gigabit Ethernet, no voltage regulation and more expensive than $10. No idea why I would choose this board for which use case...
 
It's 2018 now...
 

The first and also all the 'better' H3/H5 boards from Xunlong and FriendlyELEC use an I2C accessible SY8106A voltage regulator allowing to adjust voltage in 20mV steps. No real difference to a real PMIC wrt DVFS. The Orange Pi One was the first board with a more primitive voltage regulation scheme only supporting 2 voltages using SY8113B/AX3833 voltage regulators. Then came SinoVoip and forgot voltage regulation on their overheating BPI M2+, later FriendlyELEC decided to drop voltage regulation on their NEO2 since Allwinner's H5 BSP didn't support it any more and that was most probably also Libre Computer's 'motivation' to drop voltage regulation at the same time.
 
But while Allwinner themselves do not support voltage regulation any more with H2+/H3 in their BSP (it has also been removed in their 4.4 kernel code drop) and never supported it with H5 the mainline kernel code that properly implements voltage regulation with both SY8106A and SY8113B/AX3833 without using the ARISC core exists for over 2 years now.
 
In other words: the Libre Computer Allwinner boards are designed to run with Allwinner BSP based OS images (Android / crappy Linux) and not mainline kernel   This design decision allows for lower peak performance and higher idle consumption at the same time.

Nope, that's just a random number and there's absolutely no need to obfuscate random numbers. Same with the HW address of Ethernet (derived from the SoC's SID but linux-sunxi devs discovered that they have to change the algorithm recently so MAC adresses will change sometimes in the future anyway).
 
Thanks for the nice picture but I prefer avoiding in vendor forums but the original version of this information and to use one single source for all sunxi devices: http://linux-sunxi.org/Xunlong_Orange_Pi_Zero#Expansion_Port

H2+/H3/H5 boards overview (early 2018 update)
 
For the methodology/categorization please see above. This is just a brief overview adding the boards that appeared within the last few months (Banana Pi Zero, NanoPi Duo, Orange Pi R1, Orange Pi Zero Plus, Sunvell R69) and will appear soon or are just released (ACT Power X-A1, Libre Computer's H2+/H3/H5 Tritium, NanoPi NEO Core and Core2):
 
NAS category (only due to Gigabit Ethernet available):
Banana Pi M2+: H3, 1GB DRAM, 8GB slow eMMC, 1+2 USB ports useable, Wi-Fi/BT Banana Pi M2+ EDU: H3, 512MB DRAM, no eMMC, 1+2 USB ports useable NanoPi M1 Plus: H3, 1GB DRAM, 8GB slow eMMC, 1+3 USB ports useable, Wi-Fi/BT NanoPi M1 Plus 2: H5, 1GB DRAM, 8GB slow eMMC, 1+3 USB ports useable, Wi-Fi/BT NanoPi NEO 2: H5, 512MB DRAM, no eMMC, 1+1+2 USB ports useable NanoPi NEO Core 2: H5, 512MB/1GB DRAM, eMMC, 1+3 USB ports useable, GbE on pin header NanoPi NEO Plus 2: H5, 512MB DRAM, no eMMC, 1+2+2 USB ports useable, Wi-Fi OrangePi PC 2: H5, 1GB DRAM, no eMMC, 1+3 USB ports useable OrangePi Prime: H5, 2GB DRAM, 1+3 USB ports useable, Wi-Fi/BT OrangePi Plus: H3, 1GB DRAM, 8GB eMMC, 1+4 USB ports useable (hub), Wi-Fi OrangePi Plus 2: H3, 2GB DRAM, 16GB slow eMMC, 1+4 USB ports useable (hub), Wi-Fi OrangePi Plus 2E: H3, 2GB DRAM, 16GB fast eMMC, 1+3 USB ports useable, Wi-Fi Orange Pi Zero Plus: H5, 512MB, 1+1+2 USB ports useable, Wi-Fi X-A1: H3, 1GB DRAM, 8GB eMMC, 1+2 USB ports useable IoT category (cheap, small, energy efficient, most of them headless):
Banana Pi Zero: H2+, 512MB DRAM, no eMMC, 1 USB port useable, Wi-Fi/BT,  Fast Ethernet (pin header) NanoPi Air: H3, 512MB DRAM, 8GB slow eMMC, 1+1+2 USB ports useable, Wi-Fi/BT, no Ethernet NanoPi Duo, H2+, 256/512MB DRAM, 1+1+2 USB ports useable, Wi-Fi, Fast Ethernet (pin header) NanoPi NEO: H3, 256/512MB DRAM, no eMMC, 1+1+2 USB ports useable, Fast Ethernet NanoPi NEO 2: H5, 512MB DRAM, no eMMC, 1+1+2 USB ports useable, Gigabit Ethernet NanoPi NEO Core: H3, 256/512MB DRAM, optional eMMC, 1+3 USB ports useable, Fast Ethernet (pin header)
NanoPi NEO Plus 2: H5, 512MB DRAM, no eMMC, 1+1+2 USB ports useable, Wi-Fi, Gigabit Ethernet Orange Pi R1: H2+, 256MB DRAM, 1+2 USB ports useable, Wi-Fi, 2 x Fast Ethernet (1 x USB RTL8152) OrangePi Zero: H2+, 256/512MB DRAM, no eMMC, 1+1+2 USB ports useable, Wi-Fi, Fast Ethernet OrangePi Zero Plus 2: H3, 512MB DRAM, 8GB fast eMMC, 1+0+2 USB ports useable, Wi-Fi/BT, no Ethernet but HDMI OrangePi Zero Plus 2: H5, 512MB DRAM, 8GB fast eMMC, 1+0+2 USB ports useable, Wi-Fi/BT, no Ethernet but HDMI Tritium IoT: H2+, 512MB DRAM, 1+3 USB ports useable, Fast Ethernet
General purpose (HDMI and full legacy kernel support: video/3D HW accelerated):
Beelink X2: H3, 1GB DRAM, 8GB slow eMMC, 1+1 USB ports useable, Wi-Fi, Fast Ethernet NanoPi M1: H3, 1GB DRAM, no eMMC, 1+3 USB ports useable, Fast Ethernet OrangePi Lite: H3, 512MB DRAM, no eMMC, 1+2 USB ports useable, Wi-Fi, no Ethernet OrangePi One: H3, 512MB DRAM, no eMMC, 1+1 USB ports useable, Fast Ethernet OrangePi PC: H3, 1GB DRAM, no eMMC, 1+3 USB ports useable, Fast Ethernet OrangePi PC Plus: H3, 1GB DRAM, 8GB fast eMMC, 1+3 USB ports useable, Wi-Fi, Fast Ethernet OrangePi Zero Plus 2: H3, 512MB DRAM, 8GB fast eMMC, 1+1+2 USB ports useable, Wi-Fi/BT, no Ethernet pcDuino Nano 4: See above, it's just an OEM version of NanoPi M1 done for Linksprite Sunvell R69, H2+, 1GB DRAM, 8GB eMMC, 1+1 USB ports useable, Wi-Fi, Fast Ethernet Tritium: H3, 1GB DRAM, 1+3 USB ports useable, Fast Ethernet Tritium: H5, 2GB DRAM, 1+3 USB ports useable, Fast Ethernet

No idea. The only 'good' SD card that died here so far is a SanDisk Extreme Pro 8 GB I used over 3 years intensively (since both great random IO performance and also sequential performance -- burning cards with up to 80 MB/s in my MacBook was always fun). All the other cards that died were cheap Noname/Intenso/Kingston crap.

If I understood @zador.blood.stained correctly he would prefer splitting this up in a more granular way. Currently we have the following functions in the script (the ones that can remain in armhwinfo marked with an X):
collect_information X set_io_scheduler prepare_temp_monitoring X prepare_board log_hardware_info X get_flash_information X show_motd_warning X check_sd_card_speed X add_usb_storage_quirks activate_zram So prepare_board, set_io_scheduler and add_usb_storage_quirks could go into an armbiansetuphw service and zram could be handled by armbianzram (I really would prefer to prefix all our services with armbian so users get a clue what's plain Ubuntu/Debian and what's Armbian).
 
Yes, but please see @zador.blood.stained's objections. I'm fine with any way as long as it's configurable and able to be disabled. The log2ram functionality would then have to implement a fallback mechanism to what we use today (check for /dev/zram0 whether it contains a freshly created btrfs filesystem. If yes use it, otherwise do the fallback to tmpfs)
 
It's worse also for another reason: Recompressing already compressed stuff usually wastes more storage space. An uncompressed 10 MB log might end up being a 1 MB .gz file or as uncompressed file using 1.5 MB DRAM on an lzo zram device. But the 1 MB gzip version might need +2 MB on the same lzo compressed zram device. So it's not just a waste of CPU cycles but also inefficient DRAM use.

Well, switching from tmpfs to an already existing zram block device that has been prepared before is most probably the easy part.
Prerequisit to use such a zram device would be refactoring at least armhwinfo (so that armhwinfo eventually again only does what the name tells: collecting and logging information). All the stuff that configures/optimizes should end up in own services that can be configured in a sane way so that user changes do not get lost with next update. No idea how to do that though Then the whole zram idea needs a solution since in case we reinvent the wheel and create zram devices on our own (which seems like the only way to get zram for logs to me) we need to deal with the existence of other zram related services (e.g. zram-control package in Ubuntu) And I fear the part that needs most attention is logrotate and how to interfere with. Moving old/compressed logs into RAM is no good idea at all, also moving logs compressed by logrotate from RAM to 'disk' and free RAM afterwards seems like the only sane way to me. But I've no idea how this could evolve without reinventing the wheel again and implement logrotate functionality on our own now being aware of two filesystems to use instead of one. Maybe the use of symlinks helps? The initial sync from storage to RAM does not copy old/compressed contents but creates them as symlinks to the /var/log.hdd/ variant. And then a cronjob monitors /var/log and as soon as there appear rotated logs they're moved over to /var/log.hdd and are replaced with symlinks. Active logfiles are treated differently and simply rsynced on a per file basis to /var/log.hdd

A 'new' wiki? The product pictures show early board revs from over one year ago that never got sold (showing one SATA port as optional, different SATA power ports, different layout of WAN/LAN ports, battery connector that is of no use, DC-IN is labeled '12V/2A' while it reads directly below '5 volt @2A via DC Power and/or Micro USB (OTG)'). Is this technical documentation or a joke?
 
I started reading this section http://wiki.banana-pi.org/Banana_Pi_BPI-R2#Hardware_spec but already stopped after 7 lines of which 4 are wrong (more than 50%):
'Quad-code ARM Cortex-A7' -- copy&paste as usual from their forum 'Two SATA 2.0 Port (USB-to-SATA bridge)' -- as far as I know that's not USB but PCIe based and an ASM1061 (providing SATA 3.0)? 'MTK6625L chip' -- does not exist 'resolutions up 1920x1200' -- according to SoC manual it's 1920x1080 instead So unfortunately still no technical documentation but just the careless 'copy&paste gone wrong' weirdness this SinoVoip employee is 'famous' for. Still zero progress :-(
 

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.

I experienced the same when playing with 4.14 on a NanoPi Fire 3. So maybe it's a problem of this kernel release? Anyway, I ended up adding
extraargs="maxcpus=2" to /boot/armbianEnv.txt and rebooted to get a dual-core system.

It's stupid to combine routing/firewalling with NAS and multimedia stuff on the same device. On a router/firewall you do NOT want to increase attack surface by unnecessarily running any unneeded services (especially no graphics stuff). Also you usually do NOT want to expose your NAS to the whole world (security best practices).
 
Have you ever seen a RealTek SDK? Yeah, me neither. The W2 is a 'closed source' thingie (running Android and a chrooted OpenWRT/Linux inside) and the R2 might maybe supported sometimes in the future if mainline kernel support evolves and someone wants to spend his spare time on a questionable device (again: you do NOT want to combine routing/firewalling with NAS and multimedia stuff on the same device)

Fixed but a bit different since it doesn't work the way we have before.

Thomas, I think it's problematic that you only have a watt-meter including the PSU because the PSU's efficiency depends on the consumption (usually it's optimal around 50% load). Using a USB power meter would tell you the volts, amps and watts, and would even allow to detect under-power when it happens.
 
I managed to get my board to shut down only once, it was powered by my laptop's USB3 port (that's what I do all the time but I'm probably close to the limit). It never happened on a 5V/2A PSU however. Since it was not yet very hot, I suspect that it's the power controller instead which had shut it down rather than the temperature.
 
I also had to play with the critical points to avoid needlessly throttling. I seem to remember having set them to 105, 110 and 112 degrees though I may be wrong since I ran many tests. Now I packed the board inside a cardboard made "enclosure" from which the heat hardly dissipates, and it can still throttle when reaching the first critical point, but that doesn't last long.
When it happens, usually it's at 832/1024 of 1600 MHz = 1300 MHz, and more rarely it's 640/1024*1600 = 1000 MHz. I haven't run cpuburn yet though, I can if you're interested.
 
Regarding the use cases, I think they are limited but the board is awesome when they can be met. For me, it's fantastic as a developer to test threaded code scalability on up to 8 cores, given that the L2 cache is shared between all cores. Usually you need a huge power hungry CPU to get the same, here I have this in may laptop's bag. I also want to see what performance level I can reach on HTTP compression using libslz. I'm pretty sure that making some content recompression farms using such boards could be very affordable. Also the CPU supports native CRC32 instructions which are missing on x86 and affect gzip's performance, so I'll have to improve my lib to benefit form this. Miners may like to exploit some algorithms which perform well on ARMv8 and exploit the native AES and SHA2 implementations (I'm a bit clueless in this area). Last, for computer assisted vision, you have 8 cores with NEON ;-)
 

Because zram-config package exists only in Ubuntu by default, and for reasons I don't remember (probably version numbering / potential repository priority issues?) we decided to not copy it to our repository to be available for all releases.
 
It's not set up for multi-user scenario yet (VM guests for different tasks and users instead of one shared space otherwise manual build tasks may conflict with automated ones)
 
I meant this specific thread: https://forum.armbian.com/topic/6281-board-support-general-discussion-project-aims/
Recent examples to add to that - there is no purpose in recently added "development" branch if "master" is completely abandoned as a result and suggesting to "switch to beta" to fix any issues defeats the purpose of "beta" - fixes should be immediately pushed to the stable branch and beta should be left for non-production ready stuff.