NicoD

I'll check that. I've used 7-zip to compare the Bpi-zero to the rpi zero/3b. But the versions are different. I think because of that the numbers aren't exactly comparable. But it is a lot better than most other tools.
The best way for me is to use as many different programs. Some do better with 32-bit architecture, some better with 64-bit. Then take an average of all the results and your close.
Any way of installing exactly the same version of 7zip on all sbc's?
 
Here's the Rasp 3B+ result you wanted. All default settings.
nicod@nicod-desktop:~$ 7zr b ; 7zr b 7-Zip (A) 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18 p7zip Version 9.20 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,4 CPUs) RAM size: 927 MB, # CPU hardware threads: 4 RAM usage: 850 MB, # Benchmark threads: 4 Dict Compressing | Decompressing Speed Usage R/U Rating | Speed Usage R/U Rating KB/s % MIPS MIPS | KB/s % MIPS MIPS 22: 1623 299 528 1579 | 45650 371 1110 4118 23: 1553 300 527 1582 | 45169 373 1108 4133 24: 1555 306 546 1672 | 40410 372 1008 3749 Killed 7-Zip (A) 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18 p7zip Version 9.20 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,4 CPUs) RAM size: 927 MB, # CPU hardware threads: 4 RAM usage: 850 MB, # Benchmark threads: 4 Dict Compressing | Decompressing Speed Usage R/U Rating | Speed Usage R/U Rating KB/s % MIPS MIPS | KB/s % MIPS MIPS 22: 1681 320 511 1635 | 39773 371 966 3588 23: 1483 310 487 1511 | 38959 370 963 3565 24: 1408 306 495 1514 | 38199 370 958 3543 Killed Here my results of the Bpi-zero(i know you don't care for that one
 
pi@bpi-iot-ros-ai:~$ taskset -c 0-3 7zr b -mmt4 7-Zip (A) 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18 p7zip Version 9.20 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,4 CPUs) RAM size: 494 MB, # CPU hardware threads: 4 RAM usage: 434 MB, # Benchmark threads: 4 Dict Compressing | Decompressing Speed Usage R/U Rating | Speed Usage R/U Rating KB/s % MIPS MIPS | KB/s % MIPS MIPS 22: 1224 328 363 1190 | 34817 393 799 3141 23: 1203 335 366 1226 | 33868 389 796 3099 24: 1078 328 353 1159 | 30588 359 789 2837 ---------------------------------------------------------------- Avr: 330 361 1192 380 795 3026 Tot: 355 578 2109 -------------------------------------------------------------------- Single Thread -------------------------------------------------------------------- pi@bpi-iot-ros-ai:~$ taskset -c 0 7zr b -mmt1 7-Zip (A) 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18 p7zip Version 9.20 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,4 CPUs) RAM size: 494 MB, # CPU hardware threads: 4 RAM usage: 419 MB, # Benchmark threads: 1 Dict Compressing | Decompressing Speed Usage R/U Rating | Speed Usage R/U Rating KB/s % MIPS MIPS | KB/s % MIPS MIPS 22: 435 99 426 423 | 9036 100 819 815 23: 425 99 436 433 | 8884 99 817 813 24: 403 99 436 433 | 8753 100 815 812 25: 349 97 411 399 | 7673 90 804 721 ---------------------------------------------------------------- Avr: 99 427 422 97 814 790 Tot: 98 620 606 And here the same for the Rpi 3b
 
pi@Raspi:~ $ taskset -c 0-3 7zr b -mmt4 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: 765 1192 1193 1193 1191 1193 1193 1193 1193 RAM size: 858 MB, # CPU hardware threads: 4 RAM usage: 450 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: 1813 319 553 1764 | 56458 391 1232 4817 23: 1756 320 559 1790 | 54822 389 1218 4743 24: 1734 328 569 1865 | 53375 390 1203 4686 ---------------------------------- | ------------------------------ Avr: 322 560 1806 | 390 1218 4749 Tot: 356 889 3277 ------------------------------------- Single Thread ------------------------------------- pi@Raspi:~ $ taskset -c 0 7zr b -mmt1 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: 1016 1192 1192 1192 1192 1192 1192 1192 1192 RAM size: 858 MB, # CPU hardware threads: 4 RAM usage: 435 MB, # Benchmark threads: 1 Compressing | Decompressing Dict Speed Usage R/U Rating | Speed Usage R/U Rating KiB/s % MIPS MIPS | KiB/s % MIPS MIPS 22: 684 100 666 666 | 15163 100 1295 1295 23: 663 100 676 676 | 14808 100 1282 1282 24: 637 100 686 685 | 14440 100 1268 1268 25: 609 100 696 696 | 13990 100 1245 1245 ---------------------------------- | ------------------------------ Avr: 100 681 681 | 100 1273 1272 Tot: 100 977 977 As you can see, bpi-zero was :
7-Zip (A) 9.20  Copyright (c) 1999-2010 Igor Pavlov  2010-11-18
p7zip Version 9.20 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,4 CPUs)
Rpi 3b :
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)

The result of the Bpi-zero seemed a bit on the low side. I did cool it so it wouldn't throttle.
The result of the rpi 3b+ also look lower than 3b. I'll try again with the same command on the 3b.
@tkaiser
Also yesterday I've made a new video about the Rpi 3b+ where I overclock it in Ubuntu. It clocks quite a bit higher in Ubuntu than in Raspbian. How comes? Did the people of canonical do a better job in managing the cpu? It also didn't throttle in Ubuntu. I've closed the case completely and let it run on the max to test that. More than 80°C and still at the max frequency.
Here's the video
Video install Ubuntu + Overclock

Latest sbc-bench version 0.6 implements a new 'thermal testing' mode:
root@nanopct4:/home/tk# sbc-bench.sh -h Usage: sbc-bench.sh [-c] [-h] [-m] [-t $degree] [-T $degree] ############################################################################ Use sbc-bench.sh for the following tasks: sbc-bench.sh invoked without arguments runs a standard benchmark sbc-bench.sh -c also executes cpuminer test (NEON/SSE) sbc-bench.sh -h displays this help text sbc-bench.sh -m [$seconds] provides CLI monitoring (5 sec default interval) sbc-bench.sh -t [$degree] runs thermal test waiting to cool down to this value sbc-bench.sh -T [$degree] runs thermal test heating up to this value ############################################################################ root@nanopct4:/home/tk# This mode makes only use of cpuminer and is only useful to measure thermal effects (looking at temperatures, cpufreq statistics and relative performance differences) but provides no general benchmarking functionality other than displaying thermal efficiency of
physical aspects of heat dissipation (heatsink, heatsink + fan, nothing, airflow, enclosure or not, whatever) efficiency of throttling settings (bad settings --> bad performance once throttling occurs) Both -t and -T need an integer value as second argument: e.g. '-t 50' or '-T 70'. In the former case sbc-bench ensures that SoC temperature falls below 50°C prior to starting the test, the latter case will result in the tool heating up to 70°C first and then starting the test.
 
Both modes should be used combined to generate a reproducable environement. E.g.
sbc-bench.sh -T 70 ; sbc-bench.sh -t 50 This will result in a first test heating up the SoC to 70°C, then testing, then let the second run wait to cool down to 50°C before 2nd test starts. This way it's ensured that several tests run under almost identical conditions.
 
If you want to skip pre-heating or waiting for chill down simply use -T with a very low value, e.g. 'sbc-bench -T 20'.
 
As an example comparison of NanoPC-T4 with stock heatsink. 1st test with FriendlyELEC's blue thermal pad between RK3399 and heatsink, 2nd time with the thermal pad replaced by a copper shim with thermal paste (test duration is ~302 seconds).
 

 
 
With thermal pad:
1992 MHz: 100.79 sec 1800 MHz: 0.02 sec 1608 MHz: 0 sec 1416 MHz: 169.13 sec 1200 MHz: 32.26 sec vs. copper shim:
1992 MHz: 136.00 sec 1800 MHz: 0 sec 1608 MHz: 0.02 sec 1416 MHz: 159.06 sec 1200 MHz: 7.19 sec Copper shim + thermal paste performs better but not that much in this mode (somewhat simulating the board being enclosed and idling at around 50°C).
 
And it's also obvious that there's something seriously wrong with our throttling settings since 1800 and 1608 MHz cpufreq OPP are skipped. When those would be used performance in throttling state would be a little bit better. That's what the '-T' switch is about: operating the board under conditions where thermal trip points and such stuff can be tested efficiently.
 

Are you kidding?
 
https://www.google.com/search?rls=en&q=Micro-USB_1_01.pdf
 
This is the relevant specification for WHAT YOUR USERS HAVE AT HOME. The connector is rated for 1.8A max, 99.99% of cables are made for 500mA max.
 
That is the REALITY OUT THERE if you throw an electronics device on the market equipped with this crappy Micro USB connector. It encourages users to use common Micro USB gear which simply WILL FAIL with the Tinkerboard since not made for higher currents than a few hundred mA.
 
USB PD (power delivery) specs in the meantime defined NEW specifications so with both NEW receptacles and NEW cables 3A are possible with Micro USB. The USB PD specs (see here for an overview) while now defining NEW Micro USB connections (needing NEW receptacles, jacks and cables!) do of course not define any PD profile that uses 3A at 5V. Why? Since VOLTAGE DROP. Ohm's law still exists. The lower the voltage, the higher the drop.
 
The USB PD specs define Micro USB carrying 3A with NEW Micro USB connectors and NEW cables only at 12V (Profile 3) or 20V (Profile 4). And the reason is once again called VOLTAGE DROP.
 
If you put a Micro USB receptacle on your product to power your board you do two things at the same time:
Encourage users to use the Micro USB gear that's already lying around (crappy phone chargers, average cables not suitable for more than 500mA). You introduce underpowering hassles Encourage users to make the wrong calculation since they think they won't need a new and special PSU if they already have a charger or an USB PSU lying around. You try to create the impression your product would be cheaper than it is (since always needing a SPECIAL Micro USB PSU which is additional costs) By using Micro USB board makers trick their customers into believing they could re-use existing PSUs so the board appears to be a less expensive buy compared to honestly stating that while the board uses a pretty common connector it's incompatible to 99.99% of all Micro USB gear that consumers already have.
 
And the whole sh*t show started over at the RPi. If they would've started with a sane barrel plug this whole mess wouldn't exist. Since then those other board makers who copied the crappy Micro USB connector would now copy this barrel plug instead to advertise their '1:1 replacement for the RPi'.
 
Since having the same moronic discussion with the RPi fanclub some while ago: https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=208192&start=50#p1292499 (just a quick check how many different Micro USB connectors at which amperage rating a company like RS sells. If you read through the whole thread please keep in mind that RPi forum moderators act as censors. They partially edited my posts and banned my account as a result of frequent mentions of competitor's products. But that's normal over there)

This just works (on RockPro64 -- I did the testing already of course):
 

There are four M.2 holes designed to mount the heatsink, two close to USB port, and the other two close to the gold fingers :)
 
Actually, we designed the heatsink as the enclosure and same with VIMs heatsink it support to mount a cooling fan on it.
 
the M.2/PCIE is on the bottom of the Captain carrier board.
 
More details will be update on Khadas Webiste soon.
 
Have fun!
 

That's great since the purpose of this test is an overall estimate how performant the relevant board would be when doing 'server stuff'. If you click directly on the 7-zip link here https://github.com/ThomasKaiser/sbc-bench#7-zip then you get an explanation what's going on at the bottom of that page:
 
 
In other words: as expected.
 
Your use case with Blender is something entirely different and 7-zip scores are useless for this. Primarly for the reason that Blender involves floating point stuff (while 7-zip focuses on integer and low memory latency). It's as always about the use case
 
If we look closely on the other results we see that S905 for example has an advantage with cpuminer compared to the rather similar A53 SoCs S905X and RK3328 (that perform rather identical with 7-zip for example). Maybe the root cause for cpuminer's better scores will also be responsible for better Blender results on S905 compared to other A53 SoCs? It needs a different benchmark and a lot of cross-testing with the real application to get an idea how to reliably test for your use case.

OPi+2 Armbian Stretch http://ix.io/1iX4

 

No, the Vim2 Max. Odroid XU4 with armbian now.

Hmm... not really needed since @zador.blood.stained already tested with exactly same image (I was curious whether openssl distro package can make use of the crypto engine with Hardkernel's image -- but to no avail). If XU4 again then our https://dl.armbian.com/odroidxu4/Debian_stretch_next.7z would be interesting but most probably exactly same numbers as already collected).
 
Vim2 would be interesting with Debian Stretch and 4.9 kernel (no idea whether that's available somewhere). Do you also have the S905X Vim?
 
Testing 32-bit boards with A7 cores IMO isn't needed. Maybe the OPi Plus 2 with mainline kernel...

LOL, jamesh's excuse for the RPi always showing only faked cpufreq readings is really funny ('Due to using upstream code for CPU frequency reporting...'). Here his colleague Phil is explaining the real cause (their mailbox interface simply returning requested instead of real values): https://github.com/raspberrypi/linux/issues/2512#issuecomment-382703153

I'm surprised to see that the NanoPC-T3+ seems to do better than the XU4 in multicore. And almost everything else...
It does outperform the XU4 in Blender too.

Here the scores from zador.blood.stained XU4
 
http://ix.io/1ixL Old bench xu4 with Jessie
VS
NanoPC T3+
 
Also T3+ vs T4 is interesting. T3+ outperforms in all Multicore tasks.
@tkaiser
Could you do the bench with the T4 again with 2Ghz/1.5Ghz?


Here the results for the Odroid C2 : http://ix.io/1iSh
All expected results when it's not overclocked.
Cheers

http://ix.io/1iRJ NanoPC-T3+
The changes did the work, but indeed no space left. Just checked with gparted, it shows that the partition sda1 is 59GB.
No idea if I'm doing this right.
http://ix.io/1iR0 Armbianmonitor results

I'll install the Image again.

@tkaiser
I've finished my video. Here it is.

I had to keep it simple. As always I forgot to mention a lot of information. I don't script to save time, but it also shows in the (non)quality of my work.
Thanks for all the help and info.
Now I can begin with the other sbc's. You'll hear from me.
Cheers
 

@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...