tkaiser

Since I was not entirely sure whether 'test has been executed appropriately' I went a bit further to test no swap vs. zram on a RK3399 device directly. I had to move from RockPro64 to NanoPC-T4 since with ayufan OS image on RockPro64 I didn't manage to restrict available DRAM in extlinux.conf
 
So I did my test with Armbian on a NanoPC-T4. One time I let the build job run with 4 GB DRAM available and no swapping, next time I limited available physical memory to 1 GB via extraargs="mem=1110M" in /boot/armbianEnv.txt and swapping happened with lz4 compression.
 
We're talking about a 12% difference in performance: 4302 seconds without swapping vs. 4855 seconds with zram/lz4:
tk@nanopct4:~/ComputeLibrary-18.03$ time taskset -c 0-3 scons Werror=1 -j8 debug=0 neon=1 opencl=1 embed_kernels=1 os=linux arch=arm64-v8a build=native ... real 71m42.193s user 277m55.787s sys 8m7.028s tk@nanopct4:~/ComputeLibrary-18.03$ free total used free shared buff/cache available Mem: 3902736 105600 3132652 8456 664484 3698568 Swap: 6291440 0 6291440 And now with zram/lz4:
tk@nanopct4:~/ComputeLibrary-18.03$ time taskset -c 0-3 scons Werror=1 -j8 debug=0 neon=1 opencl=1 embed_kernels=1 os=linux arch=arm64-v8a build=native ... real 80m55.042s user 293m12.371s sys 27m48.478s tk@nanopct4:~/ComputeLibrary-18.03$ free total used free shared buff/cache available Mem: 1014192 85372 850404 3684 78416 853944 Swap: 3042560 27608 3014952  
Problem is: this test is not that representative for real-world workloads since I artificially limited the build job to CPUs 0-3 (little cores) and therefore all the memory compression stuff happened on the two free A72 cores. So next test: trying to disable the two big cores in RK3399 entirely. For whatever reasons setting extraargs="mem=1110M maxcpus=4" in /boot/armbianEnv.txt didn't work (obviously a problem with boot.cmd used for the board) so I ended up with:
extraargs="mem=1110M" extraboardargs="maxcpus=4" After a reboot /proc/cpuinfo confirms that only little cores are available any more and we're running with just 1 GB DRAM. Only caveat: cpufreq scaling is also gone and now the little cores are clocked with ~806 MHz:
root@nanopct4:~# /usr/local/src/mhz/mhz 3 100000 count=330570 us50=20515 us250=102670 diff=82155 cpu_MHz=804.747 count=330570 us50=20540 us250=102614 diff=82074 cpu_MHz=805.541 count=330570 us50=20542 us250=102645 diff=82103 cpu_MHz=805.257 So then this test will answer a different question: how much overhead adds zram based swapping on much slower boards. That's ok too
 
To be continued...

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.

Which doesn't change much wrt the name of Linux kernel modules that provide SMB3 client functionality  
 
Speaking about Linux naming conventions: 'mount_smb' is the deprecated variant of 'mount_cifs' that should be used today. And this most probably originated from the history of SMB/CIFS support in Linux. Two decades ago SMB could've been best described as a pile of rotten protocols that are pretty much useless since Microsoft's implementations differed in almost any detail. Compared to that CIFS was an advancement (read through Linux manual pages -- many of this historical stuff still there). SMB2 and SMB3 have nothing in common with the SMB we know from 2 decades ago. Robust protocols with lots of cool features and specifications worth the name.
 
Anyway: CONFIG_CIFS is not set on just 5 kernel variants (by accident) so @sunxishan please send a PR with them enabled as module.

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.
 

20x20x1mm. Ordered them 18 months ago on Aliexpress for 2 bucks (5 pieces) but the link is dead. Anyway: I don't think such a copper shim is a good solution for end users. Heatsink able to be directly attached to SoC is better.
 
Will try again with my next RK3399 board with thermal glue between heatsink and copper shim and normal thermal paste between shim and SoC. Currently I fear a bit the shim could move when vibrations occur.

Here are results for 800 and 1000:
http://ix.io/1l2a
http://ix.io/1l2n
 
The inferred CPU frequencies are now reasonably consistent with configured u-boot values.  We also have the old OpenSSL
performance back.  So, the bug is in the Linux frequency scaling code.
 
Maybe this helps with reboot issue.

For 4.4 kernel, there's no other issues. Everything else works fine (at least as a headless server. Haven't tried to connect a monitor yet). I may try the Bionic desktop image this weekend.
As for mainline, WiFi and USB 3.0 does not work. lsusb only shows the otg 2.0 root hub.
 
PCIe and MIPI are not tested yet.
 
Yes, AFAIK Rockchip's binary blobs can detect the DDR type and initialize them accordingly. I can see different DRAM initialize log output on T4 and M4, although they use the same rk3399_ddr_800MHz_v1.14.bin file and exactly the same u-boot config.

There's something wrong (DRAM related) when running Rockchip 4.4 kernel, which causes the latency to be twice as much as other RK3399 boards. This causes very poor 7-zip performance, and it takes a long time to run the tinymembench. (~20 minutes both on big and little cores)
However the DRAM is performing normally on mainline kernel (4.19-rc1), and the benchmark numbers are identical to other boards.
 
Mainline kernel benchmark details: http://ix.io/1lzx. I didn't modify the opp table and thermal trip point, and it's limited to 70℃ and 1.8/1.4GHz, so thermal throttling occurs very frequently. Though it's still very powerful running under 1.6/1.4GHz and keeps cool.
 
Edit: Re-run with opp/trip point modified: http://ix.io/1lzP

Hi,
 
I saw you tested your Up board based on atom z8300, so I tested my x5 based on z8350: http://ix.io/1lwg
However, I have only manjaro installed on it and cpufreq is not reported, nor the soc temperature, so maybe this numbers are not relevant for you.
 

M4 (4.4 armbian nightly kernel) w/ the official huge heatsink attached: http://ix.io/1lvP
Ambient temperature is ~29℃
I'll write a full review this weekend.

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

@tkaiser I've managed to boot 4.18 kernel on Firefly RK3399 (those problems on 4.17 seems gone), and ran sbc-bench after editing the dts in the same way (set trip point to 85℃, OC to 2.2/1.8GHz), results are here: http://ix.io/1lmN.

Just to have some sort of comparison to x86 based SBC I benchmarked my UP Board (lying in the drawer for years) right now:
 
As can be seen the Intel Atom x5-Z8300 CPU will be outperformed by an RK3399 or even an el cheapo NanoPi Fire3 pretty easily: https://github.com/ThomasKaiser/sbc-bench/blob/master/Results.md
 
Onboard eMMC performance (16GB on my model) also not that impressive (random IO ok, but sequential write performance below SD card level at just ~20 MB/s):
Internal 32 GB eMMC random random kB reclen write rewrite read reread read write 102400 4 2959 3431 16319 16706 11944 3400 102400 16 6710 6162 23026 23813 21143 6775 102400 512 15525 20512 100141 97841 98877 20622 102400 1024 20925 21024 102145 105088 100305 17150 102400 16384 20425 20749 106923 107996 108337 20844 1024000 16384 18512 19994 106359 106060 103988 20007 I backed this board in the beginning to check it with NAS usage in mind but never managed to attach fast storage since UP Board (just like LeMaker's Guitar back then) uses the crappy Micro-B USB3 receptacle (designed for OTG/device and not host mode -- you need an UEFI update and a special cable to be able to attach USB3 SuperSpeed peripherals to this board).
 
BTW: kernel situation as crappy as with a lot of ARM boards (or maybe the board now fully works also with mainline kernel -- I don't know). At least the official kernel enabling majority of board features is a 4.9.45 that received zero fixes for over a year now: https://github.com/emutex/ubilinux-kernel

LOL! Yeah, asking the SoC vendor constantly cheating on users... haha, no, my simple approach is to stay away from everything where's Amlogic printed on!  

Just a little bit list, more detail would be done on wiki soon.
1. NEO4 board size is 45 x 56mm, but M4 is 85 x 56mm
2. NEO4 has 1GB DDR3 RAM with single chanel, But M4 has two version 2GB DDR3 RAM/4G LPDDR3 RAM with Dual Chanel.
3. NEO4  will use AP6212 wireless module with single antenna , but M4 use AP6356S dual-band module, and use 2x2 MIMO and 2 real antennas. 
4. NEO4 has one MIPI-CSI, M4 has two MIPI-CSI
5. NEO4 has USB3.0  x1 & USB 2.0  x1, but M4 has USB 3.0 x4 behind a VL817 internal hub.
6. NEO4 use 1.27mm pitch SMD connector for GPIO-40 pinout,  M4 is same with RPi3 40pin GPIO.
 
Both have:
1. PCIe x2 pin-out
2. eMMC module connector
3. GigE port.
4. TypeC is for power supply and OTG.
5. HDMI-A & MicroSD slot.
6. Big CNC heat sink, with two side 1/4 screw hole

Please see
 
It seems writing something to /etc/resolvconf/resolv.conf.d/head at image creation time creates this issue and removing the file should solve it. @Igor wanted to look into but no idea what happened.
 
IMO neither using Google's DNS nor Cloudflare's is a brilliant idea and we should really change this so user's local config always wins. Details: https://blog.powerdns.com/2018/03/22/the-dns-camel-or-the-rise-in-dns-complexit/
 

That is not a problem. How about this way:
 
RK3288 -> rockchip with whatever source, ayugan if there will be not much hassle
RK3399 (RockPRO) and RK3328 (Rock64) ->  rockchip64 (ayufan source)
RK3399 (FriednlyARM) remains RK3399 (fa source) ... we postponed this merge for the future

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):
 

One of the Banana Pi employees took @zador.blood.stained's work, added a Windows GUI and extended SoC support from H3 only to A64, A83T and even H5: http://forum.banana-pi.org/t/the-3rd-party-emmc-flash-tool-for-bpi/4080

Tried a fix with https://github.com/armbian/build/commit/f10acc0080825faf711eb6e6b7425910d75d840c
 
Would be great if you could try next nightly version and report back.

Well, FFmpeg's RKMPP support includes only decoding so far, so not many chances that Plex/Emby will support accelerated encoding for RK3399 anytime soon. Gstreamer should be pretty well supported, in theory just as RK3288, but I haven't tested it. Now I'm returning to SBC's after some weeks, so I'll make sure to test video encoding when I do the RK3399 media script, God willing.

I hope you added the heatsink?
 
My take on 'enclosure' is all those boards landing in a drawer. Since most recent boards generate more and more heat I'm thinking about adding 2 large and silent fans + dust filters in a similar way as shown here: https://forum.openmediavault.org/index.php/Thread/18962

Ok, so it's confirmed:
 
Powering also possible through pins 2 and 4 so since the SoC is at the right side and heat dissipation is no problem @mindee could evaluate a 'SATA HAT' using the 2 PCIe lanes, a Marvell 88SE9235 SATA controller (x2 PCIe to host, 4 x SATA 3.0 to disks) and power circuitry with 12V input able to feed board and 4 x 3.5" disks.
 
If I understood correctly RK3399's VPU capabilities make it interesting as transcoding NAS (once video support is ready in Linux, though no idea how far things are. @JMCC do you know about the state of video transcoding with RK3399?)

I thought they were two different names for the same upcoming board, with various intermediary designs. But you're right, the NEO4 is even smaller than the M4! So yes that makes sense, it's a single channel RAM. Then I think I'm more interested in the M4. However if they made a complete aluminum enclosure like they recently did with the NEO/NEO2 with the buttons and OLED, it could be very tempting to get one as well for about everything you can do with a machine lying in your computer bag!