Werner

I'll try to bring it up in 4.19.y ... some basic support is getting mainlined and it will be less troublesome. I hope.

Exactly same numbers as PineH64 which is not that much of a surprise given same type of memory is used with same settings. Your 7-zip numbers seem to be lower but that's just some background activity trashing the benchmark as the monitoring reveals. If you see %sys and especially %iowait percentage in the monitoring output you know you need to repeat the benchmark and stop as many active processes as possible prior to benchmark execution:
System health while running 7-zip multi core benchmark: Time CPU load %cpu %sys %usr %nice %io %irq Temp 16:15:10: 1800MHz 5.63 23% 1% 18% 0% 3% 0% 25.0°C 16:15:31: 1800MHz 5.05 84% 1% 83% 0% 0% 0% 48.2°C 16:15:51: 1800MHz 4.77 86% 1% 84% 0% 0% 0% 43.1°C 16:16:31: 1800MHz 5.15 88% 15% 53% 0% 19% 0% 39.6°C 16:16:51: 1800MHz 4.94 80% 1% 78% 0% 0% 0% 42.7°C 16:17:11: 1800MHz 4.82 92% 1% 89% 0% 0% 0% 45.0°C 16:17:31: 1800MHz 4.64 87% 1% 85% 0% 0% 0% 41.9°C 16:17:52: 1800MHz 4.74 94% 16% 72% 0% 5% 0% 43.8°C 16:18:13: 1800MHz 4.69 81% 1% 80% 0% 0% 0% 48.6°C 16:18:33: 1800MHz 4.56 86% 1% 84% 0% 0% 0% 39.5°C 16:19:28: 1800MHz 6.93 84% 12% 38% 0% 34% 0% 31.2°C I bet unattended-upgrades was running in the background (you could check /var/log/dpkg.log)

Well, but that's what the extensive monitoring is for: to be able to throw results away quickly (no fire&forget benchmarking since only producing numbers without meaning).
 
The kernel reported high %sys and %io activity starting at the end of the single threaded 7-zip benchmark and that's the only reason your 7-zip numbers are lower than mine made on PineH64. Same H6, same type of memory, same u-boot, same kernel, same settings --> same performance.
 
IMO no more tests with improved cooling needed. The only remaining question is how good heat dissipation of both boards would be with otherwise identical environmental conditions (PineH64's PCB is rather huge and in both boards the copper ground plane is used as 'bottom heatsink' dissipating the heat away. But most probably PineH64 performs way better here with an appropriate heatsink due to larger PCB). But such a test is also pretty useless since results are somewhat predictable (larger PCB wins) and type of heatsink and whether there's some airflow around or not will be the more important factors. If heat dissipation problems are solved both boards will perform absolutely identical.

I hope I didn't miss anything.
https://github.com/armbian/build/commit/735a3679e2de12db555e17b0485f99f86a1d106a

Ok then, here is my take on the matter.
 
You have to build the new image or wait for @Igor
 
* Apply the patch described on the thread
* Change the regulator like this:
 
            reg_dcdca: dcdca {                 regulator-always-on;                 regulator-min-microvolt = <810000>;                 regulator-max-microvolt = <1160000>;                 regulator-name = "vdd-cpu";             };  
* rebuild Image
 
There you have it:
7z b 7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 p7zip Version 16.02 (locale=C.UTF-8,Utf16=on,HugeFiles=on,64 bits,4 CPUs LE) LE CPU Freq:  1717  1796  1796  1796  1796  1796  1796  1796  1796 RAM size:     964 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:       2679   333    783   2607  |      70708   388   1554   6033 23:       2615   333    800   2665  |      66860   388   1489   5785 24:       2545   333    821   2736  |      63737   390   1436   5595 25:       2420   329    839   2763  |      57802   388   1324   5144 ----------------------------------  | ------------------------------ Avr:             332    811   2693  |              389   1451   5639 Tot:             360   1131   4166  

You might ask @tkaiser, he did that on PineH64 and that applies to Opi One Plus.
 
 

Just built debs and upgraded my kernel.. seems to work
 
SBC bench http://ix.io/1nje
 
w/ cheap ceramic heatsink  (and a little bit of forced ambiant air)
########################################################################## 7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,4 CPUs LE) LE CPU Freq: 1791 1792 1789 1792 1791 1791 1790 1791 1792 RAM size: 994 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: 2710 340 776 2637 | 76925 398 1648 6563 23: 2665 349 779 2716 | 75245 398 1634 6511 24: 2623 360 784 2821 | 73176 398 1615 6424 25: 1276 197 741 1457 | 69984 398 1567 6228 ---------------------------------- | ------------------------------ Avr: 311 770 2408 | 398 1616 6431 Tot: 355 1193 4420  

It is fine.
 
For the torture test, better use a good heatsink.
I just would like to comment that if you have an image without HDMI (no fb) and a good heatsink you get slightly better values.
Now is time to move on and learn new platforms... 

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.
 
 

I envisage it more as a troubleshooting tool at this point for headless boards but it could be used for a lot more I suppose
 
Initial version to test: https://github.com/botfap/armbian-image-config.git
 
Working for injecting hostname and wifi and ethernet network profiles. DHCP only for now but I will update it later
 

Do you all envision this as a bolt-on that just kind of runs last after image build around the user-patches phase, or more tightly integrated into the build process?
 
At a glance it seems more like a potential extension of armbian-config that could also be executed at anytime if needed a well.

You have a build framework that works pretty good, is it out of the question to have an extremely simple configuration framework? Maybe framework is more advanced than needed, probably just a script? 
 
It it doesn’t need to be part of the normal build process but could just simply inject a configuration profile into a completed rootfs, image or actual sd card
 
Just the basics:
Single network manager profile
hostname
default user and pass
serial console config 
log2ram status
remote login status (ssh, xrdp)
 
I don’t mind writing a simple v0.1 to get started 
 
 
 

Absolutely support this. But IMO discussion should be moved out of this thread in an own thread over at https://forum.armbian.com/forum/12-armbian-build-framework/
 
@Igor can you please move last two posts to something like an 'Initial easy setup proposal' thread? I think a lot of users might benefit from a way to easily adjust the settings @botfap talked about prior to first boot.

4.18.y and 4.17.y are pretty much the same. Both are development.

I've just played with compilation a little bit and 4.18.y is selected when BRANCH="dev" is set. But script does not take KERNELTAG or KERNELBRANCH variables into account when set up in config-default.conf.
Let's play with 4.18.7 kernel a little bit...:)

Wow, love your FrankenDell.
Thanks for your testimony and advice.

I am not sure if this is what you want to know, but:

- Debian.org or Ubuntu.com officially does not support any of those boards/boxes,
- Armbian userspace has many small but vital performance or security adjustments,
- Armbian fancy some kernel development and a lot of its maintaining. Debian relies on upstream sources for ARM hardware which can be years behind and/or lack of many functions,
- Armbian userspace is lean, clean but 100% Debian (or Ubuntu) compatible
- many stock Debian bugs are fixed on the way, "better than original :)"
- a build system is a central part of this whole ecosystem. You can DIY. Debian much harder.
- dedicated support forums per boards/boxes
- plug and play vs. complicated install scenarios on Stock Debian
- unified development scenarios and user experience vs. mess of different setup instructions scattered all around
 
I must have forgotten many other important points

It works! Great
 
FYI: http://ix.io/1jJ5

FYI, Orange Pi One Plus ethernet Gbit is already working on mainline kernel.
Thanks to Jagan Teki and Icenowy for their work!
 ./iperf3 -c 192.168.254.100 Connecting to host 192.168.254.100, port 5201 [  4] local 192.168.254.253 port 32808 connected to 192.168.254.100 port 5201 [ ID] Interval           Transfer     Bandwidth       Retr  Cwnd [  4]   0.00-1.00   sec   112 MBytes   942 Mbits/sec    0    112 KBytes        [  4]   1.00-2.00   sec   112 MBytes   941 Mbits/sec    0    119 KBytes        [  4]   2.00-3.00   sec   112 MBytes   941 Mbits/sec    0    119 KBytes        [  4]   3.00-4.00   sec   112 MBytes   941 Mbits/sec    0    119 KBytes        [  4]   4.00-5.00   sec   112 MBytes   941 Mbits/sec    0    119 KBytes        [  4]   5.00-6.00   sec   112 MBytes   941 Mbits/sec    0    119 KBytes        [  4]   6.00-7.00   sec   112 MBytes   942 Mbits/sec    0    202 KBytes        [  4]   7.00-8.00   sec   112 MBytes   942 Mbits/sec    0    202 KBytes        [  4]   8.00-9.00   sec   112 MBytes   941 Mbits/sec    0    202 KBytes        [  4]   9.00-10.00  sec   112 MBytes   942 Mbits/sec    0    202 KBytes        - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval           Transfer     Bandwidth       Retr [  4]   0.00-10.00  sec  1.10 GBytes   942 Mbits/sec    0             sender [  4]   0.00-10.00  sec  1.10 GBytes   941 Mbits/sec                  receiver iperf Done. ./iperf3 -R -c 192.168.254.100 Connecting to host 192.168.254.100, port 5201 Reverse mode, remote host 192.168.254.100 is sending [  4] local 192.168.254.253 port 32816 connected to 192.168.254.100 port 5201 [ ID] Interval           Transfer     Bandwidth [  4]   0.00-1.00   sec   107 MBytes   895 Mbits/sec                   [  4]   1.00-2.00   sec   107 MBytes   896 Mbits/sec                   [  4]   2.00-3.00   sec   106 MBytes   892 Mbits/sec                   [  4]   3.00-4.00   sec   106 MBytes   890 Mbits/sec                   [  4]   4.00-5.00   sec   106 MBytes   893 Mbits/sec                   [  4]   5.00-6.00   sec   107 MBytes   894 Mbits/sec                   [  4]   6.00-7.00   sec   106 MBytes   889 Mbits/sec                   [  4]   7.00-8.00   sec   107 MBytes   894 Mbits/sec                   [  4]   8.00-9.00   sec   106 MBytes   891 Mbits/sec                   [  4]   9.00-10.00  sec   106 MBytes   892 Mbits/sec                   - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval           Transfer     Bandwidth       Retr [  4]   0.00-10.00  sec  1.04 GBytes   893 Mbits/sec  4257             sender [  4]   0.00-10.00  sec  1.04 GBytes   893 Mbits/sec                  receiver iperf Done.  

Working on it

Start with a last known working and switch kernel to NEXT if you want to follow ... but this information might be changed soon.

Recommended:
https://forum.armbian.com/topic/5246-wifi-performance-benchmark-test/?do=findComment&amp;comment=42408

Unknown or too complex to explain.
 

If there is USB support and since there is, all of those will and they do work out of the box. Just remember to use USB2 port. USB3 is also not working yet.