NicoD

Here my temperatures with a small fan on the underside and some screws to raise it. As tkaiser said. It works better when the fan blows over a larger area. This works good enough.
It's a great heatsink. But the downside is that it heats up the whole board. So I don't think it's healty to constantly run it at 85°C. I've done it for 1h for a test. The board smelled badly. I want do it again. With low loads it doesn't heat up quickly.

Temperature
---------------
Armbian Bionic/Stretch 64-bit 2Ghz + 1.5Ghz
                        With fan idle        36°C
                        With fan maxed   65°C
                        No fan idle           40°C
                        No fan maxed     Throttles at 85°C after 14m30s
                        
Lubuntu armhf/arm64 1.8Ghz + 1.4GHz
                        With fan idle       29°C
                        With fan maxed   54°C
                        No fan idle          42°C
                        No fan maxed     69°C (after 30 minutes maxed)

Hi all.
I've discovered Vivaldi Browser for arm. A fork of Chromium.
There is a armhf version and a arm64 version.
Youtube playback with this is a lot better. I've tested it on the NanoPi M4.
The same video in Chromium had 2/3 dropped frames. (10 frames/s) 1080p video
With Vivaldi browser you get 1/3 dropped frames. (20 frames/s)
A lot better experience.

Here you can download it.
https://vivaldi.com/nl/blog/snapshots/vivaldi-1-15-rc-2/
 
Here the source where I found it. From Meveric @ Odroid. Also explanation of how to install. No wget, and change filename to the file you've downloaded for gdebi. Or use gdebi package installer.(not tested)
https://forum.odroid.com/viewtopic.php?t=29229

I tried in armhf on the M4 in armhf Lubuntu, worked great. Also tried the arm64 in Armbian Stretch. Also great.
I didn't find any posts about Vivaldi in the Armbian forum. I thought it could be helpful.
Cheers

Hi all.
I've discovered Vivaldi Browser for arm. A fork of Chromium.
There is a armhf version and a arm64 version.
Youtube playback with this is a lot better. I've tested it on the NanoPi M4.
The same video in Chromium had 2/3 dropped frames. (10 frames/s) 1080p video
With Vivaldi browser you get 1/3 dropped frames. (20 frames/s)
A lot better experience.

Here you can download it.
https://vivaldi.com/nl/blog/snapshots/vivaldi-1-15-rc-2/
 
Here the source where I found it. From Meveric @ Odroid. Also explanation of how to install. No wget, and change filename to the file you've downloaded for gdebi. Or use gdebi package installer.(not tested)
https://forum.odroid.com/viewtopic.php?t=29229

I tried in armhf on the M4 in armhf Lubuntu, worked great. Also tried the arm64 in Armbian Stretch. Also great.
I didn't find any posts about Vivaldi in the Armbian forum. I thought it could be helpful.
Cheers

Not the final version.

 
Update(8/24/2018): It's time to deal with NEO4, this picture is not the final version. NEO4 will have PCIe x2 and eMMC connector too, and a MIPI-CSI. But the dual-layer USB connector  will share USB 3.0 & USB 2.0, Type-C take another USB 3.0.

Latest RK3399 arrival in the lab. For now just some q&d photographs:
 



 
@wtarreau my first 96boards thing so far (just like you I felt the standard being directed towards nowhere given that there's no Ethernet). And guess what: 2 x Ethernet here!
 
A quick preliminary specifications list:
RK3399 (performing identical to any other RK3399 thingy out there as long as no throttling happens) 2 GB DDR3 RAM (in April Vamrs said they will provide 1GB, 2GB and 4GB variants for $99, $129 and $149) Board size is the standard 160×120 mm 96Boards EE form factor. EE = Enterprise Edition, for details download 96Boards-EE-Specification.pdf (1.1MB) Full size x16 PCIe slot as per EE specs (of course only x4 usable since RK3399 only provides 4 lanes at Gen2 speed) Board can be powered with 12V through barrel plug, 4-pin ATX plug or via pin header (Vamrs sent a 12V/4A PSU with the board) Serial console available via Micro USB (there's an onboard FTDI chip) 2 SATA ports + 2 SATA power ports (5V/12V). SATA is provided by a JMS561 USB3 SATA bridge that can operate in some silly RAID modes or PM mode (with spinning rust this chip is totally sufficient -- for SSDs better use NVMe/PCIe) Socketed eMMC and mechanical SD card adapter available (Vamrs sent also a SanDisk 8GB eMMC module as can be seen on the pictures) SIM card slot on the lower PCB side to be combined with an USB based WWAN modem in the mPCIe slot (USB2 only) 1 x SD card slot routed to RK3399, 1 x SD card slot for the BMC (Baseboard Management Controller) Gigabit Ethernet and separate Fast Ethernet port for the BMC Ampak AP6354 (dual-band and dual-antenna WiFi + BT 4.1) USB-C port with USB3 SuperSpeed and DisplayPort available eDP and HDMI 2.0 USB2 on pin headers and 2 type A receptacles all behind an internal USB2 hub USB3 on one pin header and 2 type A receptacles all behind an internal USB3 hub 96boards Low Speed Expansion connector with various interfaces exposed 96boards High Speed Expansion connector with various interfaces exposed (e.g. the 2nd USB2 host port, see diagram below) S/PDIF audio out 'real' on/off switch to cut power. To really power on the board the translucent button next to it needs to be pressed  

Thanks for your suggestion, we made a SATA HAT prototype for NanoPi M4, it can connect  with 4x 3.5inch hard drive and work well.
 
 

And two quick storage performance updates:
 
1) This is the 8GB eMMC FriendlyELEC sells (write performance limited to 43 MB/s as it's mostly the case with low capacity eMMC, read performance exceeding 130 MB/s, nice random IO values -- compare with our overview):
random random kB reclen write rewrite read reread read write 102400 4 8565 8793 24853 24808 19463 8523 102400 16 25604 25986 66627 66701 56571 24459 102400 512 42217 42326 125788 126508 125959 40394 102400 1024 42762 43178 129692 129726 130452 42636 102400 16384 43914 42877 132828 133254 133417 43012  
2) In the meantime I built also OMV images for NanoPC T4 and NanoPi M4 and did a quick LanTest benchmark with M4 and an externally connected Seagate Barracuda in an USB3 enclosure (not UAS capable -- but this doesn't matter with HDDs)
 
Close to 100 MB/s sequential speed without any more optimizations is simply awesome:

(debug output)

Nope, everything as expected. The M4 number in the list https://github.com/ThomasKaiser/sbc-bench/blob/master/Results.md has been made with mainline kernel which shows way higher memory bandwidth on RK3399 (check the other RK3399 devices there). Cpuminer numbers differ due to GCC version (Stretch ships with 6.3, Bionic with 7.3 -- see the first three Rock64 numbers with 1400 MHz in the list -- always Stretch but two times with manually built newer GCC versions which significantly improve cpuminer performance)
 
If you love performance use recent software...

I've been doing some tests with NanoPi M4 these days. While I'm not a professional board reviewer, here I can share some early performance numbers to you. Beware that none of these tests fit into real world use cases, they are just provided as-is. Besides, Armbian development on RK3399 boards are still at a very early stage, so any of these numbers may change in the future, due to software changes.
Unless mentioned, all tests are done using Armbian nightly image, FriendlyARM 4.4 kernel, CPU clocked at 2.0/1.5GHz
 
Powering
NanoPi M4 is my first board powered by USB-C, while RK3399 is not power-hungry under normal load, I do doubt if 5V/3A power supply is sufficient when the CPU load goes higher, or when a lot of USB devices are connected. So I went a series of power measurement, with this tool

That is to measure the power consumption on the USB side, excluding the consumption of PSU.
The board is powered by the USB-C charger that came with my Huawei MateBook E, which supports 5V/2A, 9V/2A, and 12V/2A, so theoretically it is insufficient to power the NanoPi M4 board. Unfortunately I can't find a USB-C charger capable of 5V/3A output, and I have to do such test with it.
What if I connected a lot of USB 3.0 device and exceeded the 5V/2A limit? Well, I did try that (connect 4 USB HDD and run cpuburn, or even connect 2 SBCs to the USB), and the answer is simple: the board crashed. But normally the board's consumption will not exceed 10W, so the charger works just fine.
 
Test setup
1) Idle consumption
This is the typical consumption when you use it as an headless server.
 
2) Idle consumption with HDMI display output (console tty interface, no Desktop/X11/GPU stuff)
Testing with Dell P2415Q 4k 60Hz display. HDMI connected, with 2560*1440 60Hz video output. Also connect the USB 3.0 hub to
 
3) Display connected, 802.11ac WiFi with iperf sending
With HDMI display connected (same as (2)), and WiFi connected to 802.11ac 5GHz AP in another room, run the following command:
iperf3 -c 10.24.0.1 -t 60 The WiFi throughput is around 110Mbps
 
4) Display connected, running cpuburn
With HDMI display connected (same as (2)), run cpuburn on all 6 cores
 
5) Idle consumption of 4.19-rc1 mainline kernel
Same as (1), but running mainline kernel.
 
Test results

 
The idle consumption is 1.79W, and it might need some tuning to reduce the consumption. When WiFi and display are connected, it goes higher to 2.87W.
With an active WiFi networking, the board consumes 4.67W, and with all CPU cores active, it consumes 9.86W.
Mainline kernel has a higher idle consumption, the reason might be DDR dvfs and/or devfreq are not implemented yet.
Based on these results, it seems that 5V/2A power is okay if no peripheral devices are connected. However if you connect any USB devices, it may easily exceed the 2A limit when CPU load goes higher.
 
CPU/RAM and IO Performance
While RK3399 is not a super fast chip, its performance fits into its position. To reveal the full potential of the board, I'm posting some visualized sbc-bench results taken from mainline 4.19-rc1 kernel here. This is because there might be some DRAM performance issues on RK3399 with 4.4 kernel.. For comparison, I'm also posting the results of Firefly-RK3399 (2.2/1.8GHz overclock, tested by myself), Raspberry Pi 3 B+, ROCK64 and RockPro64 (taken from existing sbc-bench results)
 
You can see the full sbc-bench log here.
 
Memory

 
7-zip

 
cpuminer

 
For IO performance, I use iozone to measure the performance of SD card, eMMC and USB SSD. NanoPC T4's NVMe SSD results are added as a reference.
SSD performance are measured by command "iozone -e -I -a -s 1G -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2", SD card and eMMC are using 100M instead of 1G size.

 
Networking
NanoPi M4 comes with a 1Gbps ethernet port and a 802.11ac 2x2 MIMO WiFi module, and I tested both with iperf3.
GbE iperf3 full duplex test:
hjc@nanopim4:~$ iperf3 -c 10.20.0.1 & iperf3 -Rc 10.20.0.1 -p 5202 [1] 27486 Connecting to host 10.20.0.1, port 5201 Connecting to host 10.20.0.1, port 5202 Reverse mode, remote host 10.20.0.1 is sending [ 4] local 10.20.0.2 port 43782 connected to 10.20.0.1 port 5201 [ 4] local 10.20.0.2 port 45102 connected to 10.20.0.1 port 5202 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 64.6 MBytes 542 Mbits/sec [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 95.1 MBytes 798 Mbits/sec 0 314 KBytes [ 4] 1.00-2.00 sec 110 MBytes 919 Mbits/sec [ 4] 1.00-2.00 sec 94.5 MBytes 793 Mbits/sec 0 320 KBytes [ 4] 2.00-3.00 sec 110 MBytes 920 Mbits/sec [ 4] 2.00-3.00 sec 95.8 MBytes 803 Mbits/sec 0 317 KBytes [ 4] 3.00-4.00 sec 110 MBytes 920 Mbits/sec [ 4] 3.00-4.00 sec 94.5 MBytes 792 Mbits/sec 0 317 KBytes [ 4] 4.00-5.00 sec 110 MBytes 920 Mbits/sec [ 4] 4.00-5.00 sec 94.6 MBytes 794 Mbits/sec 0 314 KBytes [ 4] 5.00-6.00 sec 110 MBytes 919 Mbits/sec [ 4] 5.00-6.00 sec 95.7 MBytes 803 Mbits/sec 0 314 KBytes [ 4] 6.00-7.00 sec 110 MBytes 919 Mbits/sec [ 4] 6.00-7.00 sec 95.5 MBytes 801 Mbits/sec 0 317 KBytes [ 4] 7.00-8.00 sec 110 MBytes 920 Mbits/sec [ 4] 7.00-8.00 sec 94.8 MBytes 795 Mbits/sec 0 314 KBytes [ 4] 8.00-9.00 sec 110 MBytes 920 Mbits/sec [ 4] 8.00-9.00 sec 94.5 MBytes 792 Mbits/sec 0 314 KBytes [ 4] 9.00-10.00 sec 97.2 MBytes 816 Mbits/sec 0 320 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 952 MBytes 799 Mbits/sec 0 sender [ 4] 0.00-10.00 sec 949 MBytes 796 Mbits/sec receiver [ 4] 9.00-10.00 sec 110 MBytes 921 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr iperf Done. [ 4] 0.00-10.00 sec 1.03 GBytes 884 Mbits/sec 9 sender [ 4] 0.00-10.00 sec 1.03 GBytes 882 Mbits/sec receiver iperf Done. [1] + 27486 done iperf3 -c 10.20.0.1  
Wireless
hjc@nanopim4:~$ iperf3 -c 10.24.0.1 Connecting to host 10.24.0.1, port 5201 [ 4] local 10.23.4.116 port 39730 connected to 10.24.0.1 port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 13.0 MBytes 109 Mbits/sec 13 1.21 MBytes [ 4] 1.00-2.01 sec 12.9 MBytes 107 Mbits/sec 5 618 KBytes [ 4] 2.01-3.00 sec 12.6 MBytes 106 Mbits/sec 0 618 KBytes [ 4] 3.00-4.00 sec 9.35 MBytes 78.7 Mbits/sec 4 329 KBytes [ 4] 4.00-5.00 sec 11.1 MBytes 92.9 Mbits/sec 0 348 KBytes [ 4] 5.00-6.00 sec 10.2 MBytes 85.5 Mbits/sec 0 363 KBytes [ 4] 6.00-7.00 sec 9.37 MBytes 78.6 Mbits/sec 0 387 KBytes [ 4] 7.00-8.00 sec 10.9 MBytes 91.5 Mbits/sec 0 409 KBytes [ 4] 8.00-9.00 sec 13.6 MBytes 114 Mbits/sec 0 409 KBytes [ 4] 9.00-10.00 sec 13.8 MBytes 116 Mbits/sec 0 410 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 117 MBytes 98.0 Mbits/sec 22 sender [ 4] 0.00-10.00 sec 116 MBytes 97.0 Mbits/sec receiver iperf Done. hjc@nanopim4:~$ iperf3 -c 10.24.0.1 -R Connecting to host 10.24.0.1, port 5201 Reverse mode, remote host 10.24.0.1 is sending [ 4] local 10.23.4.116 port 39734 connected to 10.24.0.1 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 10.6 MBytes 88.8 Mbits/sec [ 4] 1.00-2.00 sec 10.9 MBytes 91.5 Mbits/sec [ 4] 2.00-3.00 sec 4.41 MBytes 37.0 Mbits/sec [ 4] 3.00-4.00 sec 2.07 MBytes 17.3 Mbits/sec [ 4] 4.00-5.00 sec 1018 KBytes 8.34 Mbits/sec [ 4] 5.00-6.00 sec 1.29 MBytes 10.8 Mbits/sec [ 4] 6.00-7.00 sec 6.48 MBytes 54.4 Mbits/sec [ 4] 7.00-8.00 sec 10.8 MBytes 91.0 Mbits/sec [ 4] 8.00-9.00 sec 10.7 MBytes 89.9 Mbits/sec [ 4] 9.00-10.00 sec 10.7 MBytes 89.8 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 70.1 MBytes 58.8 Mbits/sec 0 sender [ 4] 0.00-10.00 sec 69.1 MBytes 58.0 Mbits/sec receiver iperf Done. It's too complicated to analyze the performance of a WiFi connection, but so far I've never seen more than 200Mbps throughput on AP6356S.

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.