dolphs

Wow - Would love to see my H6 and H5 boards performing with this new dev build, due to mainlining efforts code being merged in 5.6 as well official kernel support for wg. Oh yea H6 orange pi one plus now runs on 1.8 again or similar "hack" needed as back then for neo2 v1.1 to " overclock " while 1,5 is default ( 1 GHz on h5 if I remember correctly ) BTW I found something strange on 28 March update ( neo2 ): /var/log.hdd/apt/term.log { rotate 12 monthly compress missingok notifempty } /var/log.hdd/apt/history.log { rotate 12 monthly compress missingok notifempty } Where is this coming from in the armbianEnv.txt OR my podgies #fingers ?

not entirely sure if this is what you are looking for? ps axf | grep <your process> | grep -v grep | awk '{print "taskset -cp 3 " $1}' | sh #where cp 3 is core 4 (0-4)

So this means basically more efforts to be done before the orangepioneplus board will have 1,8GHz using the " cpufreq-dt " driver. cheers for clarifying

First attempt (5.5-rc2), thanks to @megi who added rc2 to the 5.5-branch This build resulted in compile errors at once, which was to be expected. Just reporting here in case DEV will be switched to 5.5 this month. The log attached holds "duplicate_label" as "well duplicate_node_names"-errors. compilation.log

check 1/ kernel settings, eg: net.core.default_qdisc = fq net.ipv4.tcp_congestion_control = bbr net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 net.ipv4.tcp_rmem = 4096 87380 16777216 net.ipv4.tcp_wmem = 4096 87380 16777216 net.ipv4.tcp_fastopen = 3 net.ipv4.tcp_no_metrics_save = 1 net.ipv4.tcp_slow_start_after_idle = 0 net.ipv4.tcp_timestamps = 0 2/ openvpn settings, eg; sndbuf 393216 rcvbuf 393216 push "sndbuf 393216" push "rcvbuf 393216" comp-lzo no #No need for streaming fast-io #Optimize I/O writes tls-version-min 1.2 remote-cert-tls client cipher AES-128-CBC ncp-disable auth SHA256 auth-nocache both ends have h5 (neo2 lts) currently and get upload/download of >100Mbit over VPN tunnel BTW kernel 5.3.9 shows on this board lower values so you should easily get 100Mbit openssl speed -evp aes-128-cbc -elapsed :~# openssl speed -evp aes-128-cbc -elapsed You have chosen to measure elapsed time instead of user CPU time. Doing aes-128-cbc for 3s on 16 size blocks: 12715522 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 10201155 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 5342908 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 1919464 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 274635 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 16384 size blocks: 138772 aes-128-cbc's in 3.00s OpenSSL 1.1.1a 20 Nov 2018 built on: Thu Nov 22 18:40:54 2018 UTC options:bn(64,64) rc4(char) des(int) aes(partial) blowfish(ptr) compiler: gcc -fPIC -pthread -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -fdebug-prefix-map=/build/openssl-d3BJKw/openssl-1.1.1a=. -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DVPAES_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2 The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-cbc 67816.12k 217624.64k 455928.15k 655177.05k 749936.64k 757880.15k

agreed, was just following the Jira stories and noticed AR-86 is not fully solved, just wanted to report back and that is it. So I do not want to put any rush on this, but at least we know now it is not fully solved yet. As said once I see either branch or kernel being updated will spin up another test drive. cheers for your efforts as you know it is appreciated!

in which I can contribute to test, as I owe the "orangepioneplus" ( pihole and ovpn server ) as well a spare, so excellent for testing purposes Yet as we unfortunately can see it is not showing 1,8 which I reported also 5 December: root@orangepioneplus's password: ___ ____ _ ___ / _ \| _ \(_) / _ \ _ __ ___ _ | | | | |_) | | | | | | '_ \ / _ \_| |_ | |_| | __/| | | |_| | | | | __/_ _| \___/|_| |_| \___/|_| |_|\___| |_| Welcome to Armbian buster with Linux 5.4.2-sunxi64 System load: 0.27 0.24 0.10 Up time: 2 min Memory usage: 7 % of 989MB IP: 192.168.10.121 CPU temp: 45°C Usage of /: 4% of 15G root@orangepioneplus:~# cpufreq-info |grep cpufreq cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. driver: cpufreq-dt available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil cpufreq stats: 480 MHz:91.69%, 720 MHz:0.53%, 816 MHz:0.02%, 888 MHz:0.25%, 1.08 GHz:0.28%, 1.32 GHz:0.48%, 1.49 GHz:6.74% (147) driver: cpufreq-dt available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil cpufreq stats: 480 MHz:91.69%, 720 MHz:0.53%, 816 MHz:0.02%, 888 MHz:0.25%, 1.08 GHz:0.28%, 1.32 GHz:0.48%, 1.49 GHz:6.74% (147) driver: cpufreq-dt available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil cpufreq stats: 480 MHz:91.69%, 720 MHz:0.53%, 816 MHz:0.02%, 888 MHz:0.25%, 1.08 GHz:0.28%, 1.32 GHz:0.48%, 1.49 GHz:6.74% (147) driver: cpufreq-dt available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil cpufreq stats: 480 MHz:91.69%, 720 MHz:0.53%, 816 MHz:0.02%, 888 MHz:0.25%, 1.08 GHz:0.28%, 1.32 GHz:0.48%, 1.49 GHz:6.74% (147) Will give it another shot once @megi has 5.4.3 incorporated in orangepi-5.4 branch, both default and with the " Allwinner nvmem based SUN50I CPUFreq " driver

noticed current dev build ( default kernel ) takes still 5.4.2, would like to try 5.4.3 to see if the this generic driver takes clock speedback to 1,8GHz ( currently 1.5 ) on the orangepioneplus. Not sure if the newer driver ( Alwinner CPUFreq ) is working now, but in 5.4.3 kernel updates has been made to the Generic driver as far I read the ChangeLogs. imho AR-86 is not closed yet, it works with a workaround unless it has been confirmed the Generic driver is the one to use ( though it should be the SUN50I CPUFreq driver imho? )

While 5.4.y is not in ( sunxi64_common.inc ) current yet, at this time of writing I like to explore " KERNELBRANCH="branch:orange-pi-5.5" ". Except for just updating to this branch, I noticed it is just too early as megous github branch is not prepared yet for 5.5-RC1. I am curious to see if any of these have been applied already and what new fun stuff needs to be considered in the kernel .config

@yoq - thanks for this , currently have an OPiZero LTS on its way , perhaps following link is interesting material too rgd iwd

Still exploring kernel 5.4, little bit out of scope as I am tuning the orangepioneplus board to my needs ( .config ) and no need for WiFi or Bluetooth Thus how to disable following wifi drivers that are added to the kernel ( as well wireguard ), [ o.k. ] Adding [ WireGuard tag:0.0.20190702 ] [ o.k. ] Checking git sources [ wireguard 0.0.20190702 ] [ .... ] Up to date [ o.k. ] Patching WireGuard [ Applying workaround for headers compilation ] [ o.k. ] Adding [ Wireless drivers for Realtek 8811, 8812, 8814 and 8821 chipsets branch:v5.2.20 ] [ o.k. ] Checking git sources [ rtl8812au v5.2.20 ] [ .... ] Up to date [ o.k. ] Adding [ Wireless drivers for Realtek 8188EU 8188EUS and 8188ETV chipsets branch:v5.3.9 ] [ o.k. ] Checking git sources [ rtl8188eu v5.3.9 ] [ .... ] Up to date [ o.k. ] Adding [ Wireless drivers for Realtek 88x2bu chipsets branch:master ] [ o.k. ] Checking git sources [ rtl88x2bu master ] Did read it somewhere but I forgot, one to guide me please? At least it is not here unless I am overlooking stuff TiA!

Actually it is interesting finding these under " CPU Frequency scaling " kernel config options <M> Generic DT based cpufreq driver <M> Allwinner nvmem based SUN50I CPUFreq driver This last option should " add the nvmem based CPUFreq driver for Allwinner dule capable h6 SoC. ", thus also for the orangepioneplus imho Wonder if this is a driver issue in current kernel and if this has been fixed meanwhile in 5.4.2 ? The first driver gives result as indicated 27 Nov already, the " sun50i-cpufreq-nvmem " fails on this board so far....

try here though board is not yet listed, perhaps can be based though on "orangepi-rk3399" dev kernel ( 5.4.x )

Are you using kernel 5.3 by any chance? seems to be related to this topic

we're talking about the OPi Zero LTS here? Could you try kernel 5.4.x instead of 5.3.x please ? [ ./compile.sh BOARD=orangepizero BRANCH=dev RELEASE=buster BUILD_MINIMAL=yes BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=no ]