NicoD

@numbqq from Khadas executed sbc-bench on a Vim 2 with Bionic and kernel 4.17: https://forum.khadas.com/t/cpu-frequency-up-to-2ghz/2010/24?u=tkaiser
 
I added your and his numbers + some potential insights to Results.md. So no need to re-test with Vim 2 (maybe only again with latest sbc-bench version since detailed results provide a lot more info. But I would still prefer Bionic/Stretch when testing with kernel 4.9 again  )

I added some of your numbers and insights to https://github.com/ThomasKaiser/sbc-bench/blob/master/Results.md -- IMO we're done with RPi measurements since most important lesson learned is: we always need to check firmware version first when talking about performance. The majority of performance relevant stuff on the RPi happens in the closed source domain on the VideoCore.
 
On the other hand the average RPi user is not affected since pretty clueless and not interested in details anyway. All published RPi 3B+ benchmarks were made in March, April and May, only afterwards 1st firmware that trashed performance was released (4800f08a139d6ca1c5ecbee345ea6682e2160881 from Jun 7 2018). Now the boards in reality run as slow or even slower than the RPi 3B predecessor but as usual no one takes notice and users are happy since 'having bought the faster board' -- it's all about feelings and not reality 
 
@NicoD in case you want to visualize those 'cheating' effects in a video a nice way would be to install RPi-Monitor * and let it output in a browser windows while running 'sbc-bench.sh m' in a terminal window next to it while executing benchmarks. To my knowledge all performance monitoring solutions for the RPi rely on the Linux way of things (querying /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq) which only shows the fake clockspeeds but not the real ones.
 
 
* https://rpi-experiences.blogspot.com/p/rpi-monitor.html

I'm currently downloading the rpi-stretch from 13/03/2018. Release date of the 3B+.
I'll do the same on that. We'll be able to compare those.
I'll keep posting my results.
I found the bad 2.5A very interesting. Also my 2A PSU did very well. So I can show it isn't the amperage but the voltage that's important. Everyone always says, buy a 2.5A or 3A...
Thanks for all the info. I'm learning every minute. Cheers.
ps. Check above post for more results. I'll keep it all there to save room on this thread. RPi 3B now comming.
 
@tkaiser
Check the 3B no fan vs 3B+ no fan. The 3B outperforms the 3B+ until it overheats to +80°C.

Ok. I'm on it. Now doing the Rasp 3B+ with the new script and no cooling. After that I'll do the same with a crappy psu.

Indeed on some I use old distro's. I'll do it again with newer ones. I also have got Tinker Board, BPi M2-Zero, OPi +2, ... that I'll do too. It'll take me some time.  Cheers

@malvcr or @chwe: are you able to provide 'sbc-bench neon' output for BPi R2?
 
Anyone here with a RPi 3 B+ able to run 'sbc-bench neon' with this board one time allowing for throttling (pretty easy since operation without fan should be sufficient) and one time allowing for undervoltage/frequency capping (using any crappy Micro USB cable combined with a 2A USB wall wart)? @NicoD maybe?
 
A screenshot from a putty session showing the output would be great...

Please https://pastebin.com/raw/CXtt28y1 instead and no need for dos2unix since this can simply be achieved by stripping out the CR characters ('\015') as shown above using tr.
 
Vim2 will be very interesting since strange things happen there. Really curious about the results. NanoPC T4 results are above (but with conservative settings limiting CPU cores to 1.8/1.4GHz instead of 2.0/1.5GHz we'll use later) and NanoPC-T3+ will be more or less the same as NanoPi Fire3 since same SoC but different amount (and maybe type) of DRAM. And yeah, XU4 is also interesting.

To sell more of these devices making nice profits? The average RPi user is pretty clueless so all that's needed to sell a new 'incremental update' is mentioning that it's faster. In fact the 3 B+ was a little bit faster for some months (1.4 GHz vs. 1.2 GHz and way better PCB design plus heatspreader resulted in higher sustained performance). Now that all the benchmarks are published they silently reverted the higher performance since everything demanding that would need the 1.4 GHz will now trigger the 60°C throttling treshold easily.
 
But hey, RPi users won't realize since /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq shows only bogus numbers. Same when undervoltage occurs. In such a situation (input voltage dropping below 4.65V which happens very very very often with Raspberries not using their 'special PSU' but standard Micro USB gear) the ARM cores are immediately downclocked to 600 MHz while /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq happily lies about 1400 MHz on the 3 B+ or 1200 MHz on the 3 B.
 
BTW: The VC4 is a 2010 design and nothing except exchanged ARM cores has changed. They have nothing else. If they would switch to a new SoC backwards compatibility wouldn't exist any more. I wouldn't be surprised if we see 2019 a last incremental update (then using an eMMC socket, implementing SDR104 mode for faster SD card access and Wi-Fi with 2x2 MIMO and real antennas) and in 2020 they're simply telling 'game over'.

Why so pessimistic/optimistic? (depends highly on point of view ) Just buy and add a cheap AI block, stick it to the SoC. RPi goes AI with Blockchain!!!1!  They will survive 2-3 years more with it..  
 
If you accept that the RPi isn't a high performance SBC made to 'learn' programming, not really low level stuff, more different sorts of 'hello world' with GPIOs and/or camera. The RPi is still an affordable board. For this use-case their last iteration is worthless (you still can do this with a RPi3) but that's part of the deal to keep the people happy who pay their rent (seems that they aren't that happy at the moment, but hey, they sold over 19M devices so they can't be wrong right?  At least it seems to be their main excuse for every thing they didn't do right).
 
Probably we should split the RPi rant part in the RPi thread, and @NicoDs 7zip results into this one?
 
 
 

This script has CR+LF line endings, it needs to be converted to Unix format first

Question out of curiosity.. What's a CPU only benchmark for else than miss information on the people reading it? Doesn't it lead to a situation which we still have? People buying CPU by:
the more cores it has the better the more GHz is written on the box the faster it must be! For me there are two sides in benchmarking which should be kept in mind. First it should be reliable, means others should get 'the same numbers out' when they repeat your benchmark (e.g. I could benchmark wifi sticks somewhere in the alps here, for sure throughput would be a way higher than in my hometown were I've actually around 20 others wifis visible. A 'good' benchmark would involve both situations with a comment on why and how performance differs..). You should also think about who reads your benchmark. For the '30 years in computer science guy' it might be obvious that ram-speed, general IO speed etc. matters too, for the average smartass probably not.
Things like "I bought *random sbc* cause *random guy* claimed that the CPU there is 10x faster than *random other boards CPU*. So others then have to explain the average smartass why this doesn't matter for his case due to someone smart enough to know it better decided to publish a benchmark which doesn't tell the full truth. Publish it with something like material and methods, discussion of this methods and a conclusion (somehow like a scientific paper). Otherwise your benchmark just lead to mis-assumptions which others had/have to correct.
Best example, with the average smartass: "I bought a 2A PSU cause the RPi guys said buy a 2A PSU and your SBC will run fine and microUSB is better than the outdated barrel plug cause my tiny tiny connector is gold plated and my outdated big barrel plug with a huge contact area is only nickel plated.. " The reality showed that barrel plug SBCs works 'in general' more reliable especially under high powerusage situations but the RPi guys seem to disagree on this, otherwise they would never release the 3B+, or they think it's funny to troll their own community and make some extra bucks by selling 5.15V RPi branded PSUs, a microUSB powered board which needs a 'special PSU' is IMO just error by design (5V on the microUSB output should be sufficient otherwise your PCB designer failed).. but different story...  
 
I tried once to 'benchmark' the CPU mostly with a tool called cachebench after reading through a paper written by Ulrich Drepper (and I'm quite sure, he knows what he's doing, for people interested, the paper is old but I think it's worth to read it) you could easily see if the benchmark happened in CPU cache or if it used RAM (as far as I've in mind, you could even distinguish between L1 or L2 cache mostly when it did memcpy) but I got results out of it which I could not explain, especially there were 'performance peaks' which shouldn't IMO be there which I couldn't explain in a rational matter. I decided to throw away the whole dataset and never published it cause it would only end in miss-assumptions (I think the bashscript which set-up the system reliable and converts data for analysis after its is still somewhere but I don't think it makes sense to work on it as long as I can't explain the results). 

First attempt on sbc-bench.sh (I'll put this later on Github)
 
In case you still have the RPi 3B+ around it would be really great if you could let the script run without a fan (I need the throttling situation to see whether everything is reported well). The script is designed to work on normal ARM SBC as well as on the crippled Raspberries (VideoCore main CPU controlling the hardware and all the proprietary TheadX stuff). Basic requirement is either Debian Stretch or Ubuntu Bionic (or something similar with somewhat recent packages)
 
Output from a RPi 2 with Raspbian Stretch I had access to:
root@raspberrypi:/home/pi# /usr/local/bin/sbc-bench.sh Installing needed tools. This may take some time... Done. Executing tinymembench. This will take a long time... Done. Executing 7-zip benchmark. This will take a long time... Done. Executing OpenSSL benchmark. This will take a long time... Done. Below benchmark results: Memory performance: memcpy: 1013.7 MB/s memset: 1167.9 MB/s 7-zip total scores (three runs): 2134,2129,2125 OpenSSL results: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-cbc 14216.59k 19191.70k 21097.90k 21513.56k 21793.45k 21785.26k aes-128-cbc 14147.59k 19138.28k 21094.49k 21632.68k 21673.30k 21796.18k aes-192-cbc 12802.24k 16565.27k 18059.09k 18446.34k 18352.81k 18568.53k aes-192-cbc 12807.21k 16660.76k 17955.16k 18443.61k 18557.61k 18459.31k aes-256-cbc 11806.24k 14964.78k 16007.42k 16251.22k 16460.46k 16465.92k aes-256-cbc 11738.95k 14962.37k 16062.21k 16279.21k 16455.00k 16460.46k Full results uploaded to http://ix.io/1irc. Please check the log for anomalies (e.g. swapping or throttling happenend) and otherwise share this URL.  
Output from a heavily throttled NanoPC-T4 with some preliminary Armbian I built few weeks ago:
root@nanopct4:/tmp# /usr/local/bin/sbc-bench.sh Installing needed tools. This may take some time... Done. Executing tinymembench. This will take a long time... Done. Executing 7-zip benchmark. This will take a long time... Done. Executing OpenSSL benchmark. This will take a long time... Done. ATTENTION: Throttling occured on CPU cluster 4. Check the uploaded log for details. Below benchmark results: Memory performance (on big.LITTLE systems measured individually): memcpy: 2060.7 MB/s (0.3%) memset: 8440.3 MB/s (0.6%) memcpy: 4000.9 MB/s (0.6%) memset: 9011.0 MB/s (0.7%) 7-zip total scores (three runs): 4496,3980,3837 OpenSSL results (on big.LITTLE systems measured individually): type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-cbc 91970.98k 292346.01k 630755.93k 914955.95k 1053515.78k 1065336.83k aes-128-cbc 272534.69k 638176.02k 956555.26k 1068235.78k 1137390.93k 1144930.30k aes-192-cbc 92993.86k 274024.58k 532484.78k 715422.38k 794593.96k 797059.75k aes-192-cbc 260573.74k 581688.00k 797185.54k 940168.87k 982846.12k 981581.82k aes-256-cbc 90710.94k 257319.98k 466747.22k 601770.33k 656547.84k 654611.80k aes-256-cbc 235117.07k 531296.70k 735206.31k 807839.74k 850635.43k 852792.66k Full results uploaded to http://ix.io/1irf. Please check the log for anomalies (e.g. swapping or throttling happenend) and otherwise share this URL.  
 
To let it run it's as easy as:
wget -O /usr/local/bin/sbc-bench.sh https://raw.githubusercontent.com/ThomasKaiser/sbc-bench/master/sbc-bench.sh chmod 755 /usr/local/bin/sbc-bench.sh sudo /usr/local/bin/sbc-bench.sh (unfortunately needs root privileges to manipulate cpufreq governor and access monitoring data)

LOL, the Moronix Test Suite: https://forum.pine64.org/showthread.php?tid=389&pid=3259#pid3259
 
 
Unixbench: http://www.brendangregg.com/blog/2014-05-02/compilers-love-messing-with-benchmarks.html
Bonnie: http://www.brendangregg.com/ActiveBenchmarking/bonnie++.html
 
And so on... all those tools usually recommended are popular since they're easy to execute, do not care about correct benchmarking but people are happy with numbers without meaning. Good luck...

@NicoD still these rely on RAM speed, compression.
 
I would go for Phoronix Test Suite and stress-ng.
 
Thanks.

I was using a fan + heatsink on the Bpi zero and rpi 3b.
 
 
I've just done the 7-zip bench in Raspbian Lite, now installing the desktop to compare. After that I'll to the same with ubuntu and with the rpi 3b+. I'll add all the numbers to this post.
Here's the Raspbian Lite results of the Rpi 3B
rpi 3b Raspbian Lite result 1st time Avr : 329 563 1853 | 393 1208 4746 Tot: 361 886 3300 2nd time Avr : 328 564 1851 | 393 1210 4752 Tot : 360 887 3301 3th and 4th times almost the same as 1st and 2nd Results Raspbian Desktop Rpi 3b
pi@RPI3B:~ $ 7zr b ; 7zr b 7-Zip (a) [32] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 p7zip Version 16.02 (locale=en_GB.UTF-8,Utf16=on,HugeFiles=on,32 bits,4 CPUs LE) LE CPU Freq: 949 1197 1198 1196 1198 1198 1198 1199 1198 RAM size: 911 MB, # CPU hardware threads: 4 RAM usage: 882 MB, # Benchmark threads: 4 Compressing | Decompressing Dict Speed Usage R/U Rating | Speed Usage R/U Rating KiB/s % MIPS MIPS | KiB/s % MIPS MIPS 22: 1793 317 550 1745 | 56845 394 1231 4850 23: 1759 323 555 1792 | 55419 394 1218 4795 24: 1733 329 566 1863 | 54065 394 1205 4746 25: 1280 252 580 1462 | 50155 384 1162 4464 ---------------------------------- | ------------------------------ Avr: 305 563 1716 | 391 1204 4714 Tot: 348 883 3215 7-Zip (a) [32] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 p7zip Version 16.02 (locale=en_GB.UTF-8,Utf16=on,HugeFiles=on,32 bits,4 CPUs LE) LE CPU Freq: 801 1089 1126 1059 1167 1184 1186 1186 1186 RAM size: 911 MB, # CPU hardware threads: 4 RAM usage: 882 MB, # Benchmark threads: 4 Compressing | Decompressing Dict Speed Usage R/U Rating | Speed Usage R/U Rating KiB/s % MIPS MIPS | KiB/s % MIPS MIPS 22: 1785 316 550 1736 | 56654 392 1232 4834 23: 1757 322 556 1791 | 55426 394 1219 4796 24: 1737 329 568 1868 | 53818 392 1205 4724 25: 1710 337 579 1953 | 51503 387 1184 4584 ---------------------------------- | ------------------------------ Avr: 326 563 1837 | 391 1210 4734 Tot: 359 887 3286 Desktop is a little bit slower.
 
Raspberry Pi 3b+ Raspbian Lite
 
rpi 3b+ Raspbian Lite result 1st Avr : 336 610 2051 | 390 1381 5388 Tot : 363 996 3720 2nd Avr : 329 608 2000 | 390 1382 5394 Tot : 360 995 3697 Raspberry Pi 3b+ Raspbian Desktop
i@raspberrypi:~ $ 7zr b ; 7zr b 7-Zip (a) [32] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 p7zip Version 16.02 (locale=en_GB.UTF-8,Utf16=on,HugeFiles=on,32 bits,4 CPUs LE) LE CPU Freq: 753 1393 1393 1393 1393 1393 1393 1392 1388 RAM size: 911 MB, # CPU hardware threads: 4 RAM usage: 882 MB, # Benchmark threads: 4 Compressing | Decompressing Dict Speed Usage R/U Rating | Speed Usage R/U Rating KiB/s % MIPS MIPS | KiB/s % MIPS MIPS 22: 1915 314 594 1863 | 64588 391 1410 5510 23: 1893 322 599 1930 | 62188 388 1388 5381 24: 1889 332 612 2032 | 60452 388 1368 5307 25: 1508 277 621 1722 | 57029 386 1313 5075 ---------------------------------- | ------------------------------ Avr: 311 607 1887 | 388 1370 5318 Tot: 350 988 3603 7-Zip (a) [32] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 p7zip Version 16.02 (locale=en_GB.UTF-8,Utf16=on,HugeFiles=on,32 bits,4 CPUs LE) LE CPU Freq: 922 1317 1270 1178 1279 1299 1341 1349 1346 RAM size: 911 MB, # CPU hardware threads: 4 RAM usage: 882 MB, # Benchmark threads: 4 Compressing | Decompressing Dict Speed Usage R/U Rating | Speed Usage R/U Rating KiB/s % MIPS MIPS | KiB/s % MIPS MIPS 22: 1978 325 592 1925 | 63685 387 1404 5433 23: 1977 335 602 2015 | 62343 389 1387 5394 24: 1888 332 611 2031 | 61095 390 1374 5363 25: 1891 350 617 2160 | 56111 375 1333 4994 ---------------------------------- | ------------------------------ Avr: 335 606 2032 | 385 1374 5296 Tot: 360 990 3664 08:33:52: 39.7'C 600/ 600 MHz 0000000000000000000 1.2V 08:33:58: 41.3'C 1400/1400 MHz 0000000000000000000 1.3250V 08:34:03: 44.5'C 1400/1400 MHz 0000000000000000000 1.3250V 08:34:08: 47.8'C 1400/1400 MHz 0000000000000000000 1.3250V 08:34:13: 47.2'C 1400/1400 MHz 0000000000000000000 1.3250V 08:34:18: 49.4'C 1400/1400 MHz 0000000000000000000 1.3250V 08:34:23: 48.3'C 1400/1400 MHz 0000000000000000000 1.3250V 08:34:28: 48.3'C 1400/1400 MHz 0000000000000000000 1.3250V 08:34:33: 49.4'C 1400/1400 MHz 0000000000000000000 1.3250V 08:34:39: 49.9'C 1400/1400 MHz 0000000000000000000 1.3250V Time Temp CPU fake/real Health state Vcore 08:34:44: 48.9'C 1400/1400 MHz 0000000000000000000 1.3250V 08:34:49: 49.4'C 1400/1400 MHz 0000000000000000000 1.3250V 08:34:54: 49.4'C 1400/1400 MHz 0000000000000000000 1.3250V 08:34:59: 49.4'C 1400/1400 MHz 0000000000000000000 1.3250V 08:35:04: 49.9'C 1400/1400 MHz 0000000000000000000 1.3250V 08:35:10: 50.5'C 1400/1400 MHz 0000000000000000000 1.3250V 08:35:30: 47.2'C 1400/1400 MHz 0000000000000000000 1.3250V 08:35:35: 48.3'C 1400/1400 MHz 0000000000000000000 1.3250V 08:35:40: 50.5'C 1400/1400 MHz 0000000000000000000 1.3250V 08:35:45: 49.9'C 1400/1400 MHz 0000000000000000000 1.3250V 08:35:50: 50.5'C 1400/1400 MHz 0000000000000000000 1.3250V 08:35:56: 50.5'C 1400/1400 MHz 0000000000000000000 1.3250V 08:36:01: 50.5'C 1400/1400 MHz 0000000000000000000 1.3250V 08:36:06: 50.5'C 1400/1400 MHz 0000000000000000000 1.3250V 08:36:11: 51.0'C 1400/1400 MHz 0000000000000000000 1.3250V Time Temp CPU fake/real Health state Vcore 08:36:16: 49.9'C 1400/1400 MHz 0000000000000000000 1.3250V 08:36:21: 50.5'C 1400/1400 MHz 0000000000000000000 1.3250V 08:36:26: 50.5'C 1400/1400 MHz 0000000000000000000 1.3250V 08:36:31: 51.5'C 1400/1400 MHz 0000000000000000000 1.3250V 08:36:37: 50.5'C 1400/1400 MHz 0000000000000000000 1.3250V 08:36:42: 50.5'C 1400/1400 MHz 0000000000000000000 1.3250V 08:36:47: 51.0'C 1400/1400 MHz 0000000000000000000 1.3250V 08:36:53: 52.1'C 1400/1400 MHz 0000000000000000000 1.3250V 08:36:58: 46.2'C 600/ 600 MHz 0000000000000000000 1.2V @tkaiser
Again a little slower than Lite. In the afternoon I'll check Ubuntu.
More to come. Cheers
 

Not exactly the best way  There could be some automated apt process with some purpose in the background. For example, we run index updates (apt update) every 21 days which means usually also at the first boot. This is getting some changes lately ... but on most images, it goes that way. 

The best tactic is to wait for a minute that index is updated, then proceed with apt get ...

THE MEDIA SCRIPT IS DEPRECATED, IN FAVOR OF THE OFFICIAL LEGACY MULTIMEDIA FRAMEWORK. PLEASE REFER TO THIS TOPIC:
 
 
 
The UN-official, UN-supported, UN-necessary, UN-popular, UN-precedented...
RK3288 MEDIA TESTING SCRIPT [2.0: Bionic update]
 
So here is the final release of the RK3288 media testing script. Basically, the script provides the following functionality:
Installing all the libraries and system configurations necessary for GPU accelerated X desktop, Chromium WebGL, full VPU video play acceleration up to 4k@30 HEVC (the maximum supported by the SoC), and GLES 3.1 / OpenCL 1.2 support. Three video players supporting full VPU acceleration (RKMPP) and KMS display (GBM or a X11 DRM "hack", as described by the authors), namely: MPV, Gstreamer and Kodi 18.0 alpha preview. Two example programs using the OpenCL functionality: Examples form the Arm Compute Library, and a GPU crypto miner (an old version, but small and simple). A library that will act as an OpenGL to OpenGL-ES wrapper, allowing you to run programs that use OpenGL 1.5-2.0. Two additional small packages, that have no big interest from the developer prospective, but I find them interesting to play with: Support libraries for commercial web video streaming (tested with Netflix), and a simple Pulseaudio GTK equalizer using LADSPA.  
Here is a more thorough documentation:
 
Version 2.0 (Bionic):
 
Version 1.0 (Xenial):

>>> DOWNLOAD LINK (2.0, FOR BIONIC DESKTOP) <<<
 
> Older Download link (1.0, for Xenial) <
 
Instructions:
Download the file above Untar it: tar xvf media-rk3288_*.tar.xz cd media-script ./media-rk3288.sh  
Notes:
This script is not officially supported by the Armbian project. It is just a community effort to help the development of the main build, by experimenting with a possible implementation of the media capabilities of this particular SoC. Therefore, questions about the script should not be laid out as support requests, but as commentaries or community peer-to-peer assistance. That being said, all commentaries/suggestions/corrections are very welcome. In the same way, I will do my best to help solve any difficulty that may arise regarding the script.  
Enjoy!
 
 
 

Hello all.
I've finished my video on the NanoPC-T3+.
I forgot to mention a lot of things as always. But it is how it is
@IgorWith what I promised. I hope it'll help. Thank you.
 
 

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.
 

linuxgizmos
 
Our June 2018 round-up of hacker-friendly single board computers comprises three resources: an overview of recent SBC market trends; this catalog; and a Google docs spreadsheet that tabulates the boards’ key features.
 
I haven't checked the list, well beside sunxi which lists all Allwinner another list..
http://linuxgizmos.com/catalog-of-116-open-spec-hacker-boards/

Just in time for FOSDEM some more infos on the new Pine64 H6 and RK3399 boards are available now...
 
https://forum.pine64.org/showthread.php?tid=5614

Whom have you talked to? The UK guy trying to get as much people as possible currently sending him money through PayPal?
 
The M2 Zero is just the most boring H2+/H3 device we've ever seen. Since those irresponsible guys do not 'develop' in the open you have to download 'BPI-files/SD/BPI-BOOT/BPI-BOOT-bpi-m2z.tgz', then extract this archive and look into bpi-m2z/linux/sys_config.fex (line 3 already being wrong -- as lousy as expected). They use my recommendation to clock single bank DRAM H2+/H3 boards with 'dram_clk = 408', they use our kernel and all our settings for their M2+ (even 'corekeeper_enabled = 1' we developed last year having a hard time dealing with their crappy other H3 device), if 'pmuic_type = 0' is true then they again moronically 'forgot' to implement voltage regulation (the reason why BPi M2+ so badly overheats, if they use now the same fixed VDD_CPUX voltage setup on this M2 Zero good luck since due to much smaller board size heat dissipation is even more of an issue!).
 
But we don't know whether these settings are not as usual just the result of their copy&paste monkey doing something stupid or if these are really settings that match the hardware. In the past they never succeeded to provide these fex hardware descriptions correctly and it would be a wonder if they would do this time. And since they're too ignorant or stupid to provide schematics (still nothing to see here) we'll need to buy the next Banana board ourselves to see which flaws they implemented this time. If we're stupid of course, better ignore hardware that is not supported by its own manufacturer.
 
If their fex file would be correct it would take me less than an hour to get this BPi M2 Zero FULLY SUPPORTED by Armbian. We did this with the following other H2+/H3 boards in the past without having them in our hands solely based on CORRECT hardware descriptions provided by the board makers: NanoPi Neo, NanoPi Air, NanoPi M1, Orange Pi Zero, Orange Pi Zero Plus 2, NanoPi M1+ -- if you deal with hardware vendors that do NOT behave like brain damaged retards you get correct hardware descriptions (either fex file or DT and schematics of course -- all correct and not the result of 'copy&paste gone wrong'). That's really all you need as developer and that separates other board makers from SinoVoip.
 
But since the SinoVoip guys still behave like brain damaged retards I hope no one will be dumb enough to add this M2 Zero thingie to Armbian's build system ever. Unless they hire someone able to write technical documentation (or at least someone who understands that providing CORRECT information is necessary), they stop censoring their forum and start to support their own hardware nothing will change. You must be stupid as open source community member to try to support their hardware...
 
BTW: Since with their 'RPi Zero W' competitor called M2 Zero they completely rely on our underlying work you get at least a kernel patched up to latest 3.4 LTS version (3.4.113 fixing tons of issues). Unfortunate customers buying their 'RPi 3 killer' called M2 Berry suffer from their ignorance/stupidity and get a 3.10.65 kernel only (outdated since over 2.5 years containing a lot of exploitable security vulnerabilities). Community tried to help them by even sending them all the fixes necessary to get to latest 3.10.107 LTS kernel or the fix for the DRAM instability issues: https://github.com/BPI-SINOVOIP/BPI-M2U-bsp/pulls
 
It would take them maybe 10 seconds to merge these pull request. They refuse to do since they don't seem to give a sh*t about anything else than selling hardware to clueless people (or maybe the 'responsible' guys over there are simply too ignorant to get the meaning of 'security' just like they don't understand what 'open source' means).

It's just an idea, I've no experience in this field.. 
 
 
I wouldn't call it fake. Fact is we don't support it officially (see: https://github.com/armbian/build/blob/master/config/boards/bananapim2zero.csc). We provide a buildoption as CSC.
I made ~2 months ago what I understand as csc (I didn't follow every patch around H2+/H3 boards but to my knowledge, currently a CSC build will not boot):
Some might agree with this statement, some might disagree and 'often' discussions around BPi products tend to be harsh due to issues happened in the past (and progress is for different people not fast/good enough). Their documentation tends to be 'questionable' (sometimes corrections are made, sometimes not and it's not really clear to me why they don't spend more attention to do it properly - IMO, it would be a good starting point clean up their documentation).  If you have a look at our buildscript we it's marked as (GPL 2.0) which means that they are free to fork it and provide images based on the buildscript (as long as they follow the GPL). If you build (or use their Image) an Image you'll see something like (we don't provide support for user-built images, cause we've no clue what the user changed compared to stock images):
That said, it's a user-built and no official built which would look like (example for a nightly - which is actually also not supported officially, but I don't need support for this image ):
 
People often complain, why we don't support it officially. As far as I know, some of the patches which are needed to let it boot can harm other H2+/H3 boards due to a 'questionable' design decision related to the SD-Card. Fact is, there was never a pull-request providing WIP or even sane patches for CSC support for this board, even when we reminded @Nora Lee or @Lion Wang which both work for Sinovopi/Foxconn (I don't know their official title/job description don't pay much attention to that stuff ). @tkaiser showed them a potential starting point to improve the current CSC support (maybe it wouldn't change from csc to wip, but at least csc could be built for their users and it would boot! and it would show they fulfill some of their claims made in public in this forum) but it seems that this isn't a priority at the moment. See here (read the whole thread not only the teaser!):
 
but there was no reaction to it.
They claimed in the past:
Nora Lee:
see here:
 
or lion wang:
here:
 
Things may improve since then or not, I simply have no time to follow their documentation or image quality due to 'other projects' and I have a life besides SBCs  (and it's not my job or 'field of competence' to be their quality control person - IMO it would help them to have a better 'quality control'/ technical writer but it's their decision how they run their company). 
 
In the past facebook had something like this (don't care about FB anymore, so no clue if this is still an option ):

IMO, this describes somehow the relationship between part of the armbian user-base/devs and sinovoip quite good.  Some experienced users/devs avoid to touch any BPi product due to faults made in the past, others simply don't care anymore and some try to improve the situation from time to time but it seems that sinovoip doesn't focus on an improvement at the moment whereas other boardmakers are more willing to improve the support of their boards.  
 
In case you want to make a youtube video about the BPi-M2 Zero I strongly suggest that you read/search through all those threads and 'form your own opinion'.  Posts related to their products are often 'colored' due to own experiences and opinions and might be 'not objective' (including mine). I tried to be 'as objective as possible' but I'm quite sure I'm failed on this goal (but at least, I made a 'disclaimer' here ).. 
 
Personally I think, we shouldn't make this to a new 'BPi' thread. It's just a 'more detailed' answer to 'is it fake ?' I wouldn't say it's a 'fake Armbian' but it is also not a 'official Armbian'. It's a user-built and therefore prone to break during updates since we don't test updates for user-built/csc boards. Freezing kernel before update or a proper patch so that it doesn't affect H2+/H3 boards we officially support would improve the situation. Even if the board doesn't get wip (it's not my decision whenever a board is wip or CSC), I think, a proper patch from a pull request for it would be merged into armbians github.  

http://linux-sunxi.org/Banana_Pi_M3 and here in the forum you need to search for 'NanoPi M3' (that's the cheaper variant with same SoC and just 1 GB DRAM now replaced by NanoPi Fire3 which should be the fastest el cheapo SBC around with 8 x A53 clockable at up to 1.6 GHz according to Willy Tarreau -- click on 'reviews' here: http://www.friendlyarm.com/index.php?route=product/product&path=69&product_id=206)
 
Fascinating aspect is that all the more powerful SBC except the ODROIDs are prone to underpowering by design by using the most crappy connector possible. And also an awfu lot of them show thermal problems since the 'engineers' forgot to allow to mount an appropriate heatsink/fansink. No idea what those 'engineers' thought...

Now I understand, I thought you wanted to use your Tinker in your car. Cool what you've done, for that I also use a power bank. Here a video of me building a simple robot with an Arduino. Keep up the good work. Sorry for the misunderstanding.