dolphs

Hi - I would be happy to test Rockpi4A with accompanying heatsink, but it seems a bit expensive to order in EU ( EUR48,29 ) instead China (USD39) - once I received these items I like to contribute testing its stability at 2.0GHz. Anyway the heatsink looks decent to me and since it does not have to run 24/7 at 2.0GHz I am confident it can be "overclocked" to 2.0GHz for shorter periods, but I like to test that out for my use case ( ovpn with pi-hole ) . Applied similar tweaks recently overlocking the nano pi neo2 lts (v1.1), updating armbianEnv.txt and cpufrequtils . The key to this is temperature, based on current findings neo2 board runs for little while ( 10-15 minutes ) on 1.3Ghz which makes roughly a 10 degrees CPU increase within 6 minutes, but once it throttles back temp drops rapidly ( of course ) and as said I am condifent similar could be achieved with the Rockpi4...

thanks very much - this makes me confident model A should be able to handle 2.02 as well although stated differently at their page " Dual Cortex-72, frequency 1.8GHz ", cheers

Can someone show me the output of "cpufreq-info" please, wonder if model B ( and A ) have 1,8GHz freq limit or 2GHz like NEO4. thanks

bypassing ovpn tells me theoretically I should be able to reach +/- 240Mbit upload BTW as earlier I accused RCSRDS of setting a 100Mbit cap... " ~# iperf3 -4 -V -c DNS-entry -t 60 -b 0 -P 1 " <snip snip> - - - - - - - - - - - - - - - - - - - - - - - - - Test Complete. Summary Results: [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-60.00 sec 1.71 GBytes 245 Mbits/sec 87842 sender [ 4] 0.00-60.00 sec 1.70 GBytes 243 Mbits/sec receiver CPU Utilization: local/sender 2.8% (0.1%u/2.7%s), remote/receiver 15.4% (1.1%u/14.4%s) Although at a colleague board I found some more interesting details, however I'd be very interested if someone with at least 300Mbit upload/download can share these iperf results using ovpn 2.4.6 ( server/client ) on two NEO4 ( RK3399 ) please as with NEO2 LTS (1300) I was able to reach roughly 160Mbit on average, tops 200Mbit. thanks

The NanoPI NEO4 ( Rockchip 3399 ) might be an interesting upgrade after all as I was convinced there was a 100Mbit upload cap but "overclocking" the NanoPi NEO2-LTS gave me tops 200Mbit, 160Mbit average. Yet pity NEO4 comes with WLAN and BT, perhaps friendlyelec can release a "lite" version without these components as there is an alternative available, called "Rock Pi 4 Model A", just the size is a bit bigger: 85*54mm instead of 60*45mm ( neo4 ) thanks all will closely follow this !

thanks a lot, it is highly appreciated: new values ( overclocked ) show: <snip snip> current policy: frequency should be within 408 MHz and 1.30 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1.30 GHz (asserted by call to hardware). cpufreq stats: 120 MHz:0.38%, 240 MHz:0.19%, 480 MHz:59.06%, 648 MHz:0.41%, 816 MHz:0.06%, 960 MHz:0.05%, 1.01 GHz:0.07%, 1.06 GHz:0.05%, 1.10 GHz:0.07%, 1.15 GHz:0.24%, 1.20 GHz:0.04%, 1.22 GHz:0.03%, 1.25 GHz:0.01%, 1.30 GHz:39.35% (128) first board results :~# openssl speed -evp aes-128-cbc Doing aes-128-cbc for 3s on 16 size blocks: 15572277 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 12847235 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 6787237 aes-128-cbc's in 2.99s Doing aes-128-cbc for 3s on 1024 size blocks: 2456283 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 353175 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 16384 size blocks: 178446 aes-128-cbc's in 3.00s OpenSSL 1.1.1-pre9 (beta) 21 Aug 2018 built on: Tue Aug 21 19:00:17 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-Z0GDqL/openssl-1.1.1~~pre9=. -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 83052.14k 274074.35k 581114.61k 838411.26k 964403.20k 974553.09k 2nd board ( of course similar results ): :~# openssl speed -evp aes-128-cbc Doing aes-128-cbc for 3s on 16 size blocks: 16151752 aes-128-cbc's in 2.99s Doing aes-128-cbc for 3s on 64 size blocks: 13172479 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 6906353 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 2458131 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 353291 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 16384 size blocks: 178478 aes-128-cbc's in 3.00s OpenSSL 1.1.0j 20 Nov 2018 built on: reproducible build, date unspecified options:bn(64,64) rc4(char) des(int) aes(partial) blowfish(ptr) compiler: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DVPAES_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/lib/ssl\"" -DENGINESDIR="\"/usr/lib/aarch64-linux-gnu/engines-1.1\"" 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 86430.78k 281012.89k 589342.12k 839042.05k 964719.96k 974727.85k

thanks a lot - it indeed shows the NEO4 ( RK3399 ) is about double ( 2Ghz ) of what I can squish out of the NEO2 currently (1). Which reminds me of the cpu discussion back then. In fact I owe two NEO2 LTS boards and these should be able to handle 1.3 ( instead of 1 ), hence v1.1. Both boards run currently as ovpn server/client on stable debian9, meaning kernel 4.19 ( armbian 5.73 ). Perhaps in referred topic you can guide me thru this on a running system as updating just "/boot/armbianEnv.txt " and MAX_SPEED=1300000 in /etc/default/cpufrequtils," is not sufficient at least I set it to: verbosity=1 console=both overlay_prefix=sun50i-h5 overlays=cpu-clock-1.3GHz gpio-regulator-1.3v usbhost1 usbhost2 rootdev=UUID=5455aad0-a830-48da-b4ba-18795372ece0 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u thanks again!

Hello, Can someone show results of "cpufreq-info" ( both on kernel 4.4 ( stable ) and 4.20 ( dev )) just to determine how things look like, please? ... My NEO2's show 1.01GHz ( kernel 4.19 ) while the "new" NEO4 should be able to get to 1.8 if I am not mistaken. Therefore in near future might replace this NEO4 with my current NEO2 boards , mainly used for oVPN and Pi-hole. At this time I get +/- 100Mbit speeds over my VPN tunnel - which for my streaming needs is sufficient - but I am always interested to see if things can be improved. Also it appears the 100Mbit limit is set by my ISP (RCSRDS), lucky me, considering " asemenea viteaza de upload international s-a marit la 100Mbps. ". Yet quoting from a site " There’s a significant single-core performance boost (+73%), and lower multi-core delta (+30%) as expected since RK3399 has 2 fast Cortex A72 cores, 4 low power Cortex-A53 cores, against 4 fast Cortex-A17 cores for RK3288. If you look into the details AES is over 10 times faster on RK3399, so there must be some special instructions used here, or AES hardware acceleration. " Can one show me some results using ovpn 2.4.6 please as for oVPN use this "single core" and "AES" stuff is important and maybe moving to Rockchip RK3399 will be worth it. Perhaps forcing use of the Dual Core Cortex A72 and disable the Quad Core Cortex-A53 [ echo "0" > /sys/devices/system/cpu/cpu[2-5]/online ] would be another tweak to speed things up? Oh, inerested in " grep -m1 -o aes /proc/cpuinfo " as well " openssl speed -evp aes-128-cbc " and last but not least " iperf3 -4 -V -c 192.168.10.2 -t 60 -b 0 -P 1" #where IP is address neo4 My NEO2 reads": grep -m1 -o aes /proc/cpuinfo aes openssl speed -evp aes-128-cbc 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 53449.87k 172470.12k 364346.54k 527213.91k 606710.44k 613225.81k iperf3 -4 -V -c 192.168.10.2 -t 60 -b 0 -P 1 Test Complete. Summary Results: [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-60.00 sec 734 MBytes 103 Mbits/sec 930 sender [ 4] 0.00-60.00 sec 727 MBytes 102 Mbits/sec receiver CPU Utilization: local/sender 1.6% (0.1%u/1.5%s), remote/receiver 31.5% (2.5%u/29.0%s) - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth [ 5] 0.00-60.11 sec 0.00 Bytes 0.00 bits/sec sender [ 5] 0.00-60.11 sec 727 MBytes 101 Mbits/sec receiver tuned kernel settings: net.core.default_qdisc = fq 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_congestion_control = bbr 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

Hi thanks sharing this with me. tried with both CBC and GCM ( last results ) and indeed interesting results also with GCM. Any kernel settings changed to get 160Mbit as I seem to get stuck around 110Mbit while in theory I should be able to get 300Mbit ( limit upload ) iperf3 -4 -V -c 192.168.10.2 -t 60 -b 0 -P 1 - - - - - - - - - - - - - - - - - - - - - - - - - Test Complete. Summary Results: [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-60.00 sec 795 MBytes 111 Mbits/sec 1190 sender [ 4] 0.00-60.00 sec 787 MBytes 110 Mbits/sec receiver CPU Utilization: local/sender 1.9% (0.1%u/1.7%s), remote/receiver 34.0% (2.6%u/31.4%s) - - - - - - - - - - - - - - - - - - - - - - - - - Test Complete. Summary Results: [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-60.00 sec 774 MBytes 108 Mbits/sec 2724 sender [ 4] 0.00-60.00 sec 766 MBytes 107 Mbits/sec receiver CPU Utilization: local/sender 1.9% (0.1%u/1.8%s), remote/receiver 30.9% (2.3%u/28.6%s)

excellent news Igor, done well - highly appreciate all your efforts! ( and of course all others that contributed to this major )

hello all - trying to find out when v5.67 will be final having all these juicy bits from DEV incorporated, in my case both NanoPi NEO2 ( older version ) and current LTS do work fine so far on this release. then again I use the boards just for ovpn so nothing to fancy ( in terms of GPU, etc )

hi running armbian ( kernel 4.14 ) and ovpn 2.4.6 and both nanopi neo2 boards. ovpn is configured with cipher AES-128-CBC and auth SHA256, following results can be seen: top - 04:53:47 up 26 days, 11:42, 2 users, load average: 0.16, 0.16, 0.09 Tasks: 102 total, 2 running, 57 sleeping, 0 stopped, 0 zombie %Cpu0 : 1.0 us, 1.0 sy, 0.0 ni, 98.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu1 : 1.0 us, 2.0 sy, 0.0 ni, 97.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu2 : 20.7 us, 30.1 sy, 0.0 ni, 43.5 id, 0.0 wa, 0.0 hi, 5.7 si, 0.0 st %Cpu3 : 0.3 us, 0.3 sy, 0.0 ni, 99.0 id, 0.0 wa, 0.0 hi, 0.3 si, 0.0 st KiB Mem : 494152 total, 128980 free, 92528 used, 272644 buff/cache KiB Swap: 247072 total, 229664 free, 17408 used. 382416 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1191 root 20 0 10180 6132 5324 R 59.1 1.2 137:16.90 openvpn and following with single thread " iperf3 -4 -V -c 192.168.10.2 -t 60 -b 0 -P 1 " iperf 3.1.3 Linux vpn01 4.14.70-sunxi64 #274 SMP Wed Sep 19 12:09:30 CEST 2018 aarch64 Time: Sun, 09 Dec 2018 02:53:07 GMT Connecting to host 192.168.10.2, port 5201 Cookie: vpn01.1544323987.071807.somewhat TCP MSS: 1276 (default) [ 4] local 10.8.0.2 port 63472 connected to 192.168.10.2 port 5201 Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 0 seconds, 60 second test [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 9.07 MBytes 75.9 Mbits/sec 199 1.24 MBytes [ 4] 1.00-2.00 sec 8.75 MBytes 73.4 Mbits/sec 166 1.09 MBytes [ 4] 2.00-3.00 sec 12.5 MBytes 105 Mbits/sec 0 1.35 MBytes [ 4] 3.00-4.00 sec 7.50 MBytes 62.9 Mbits/sec 0 1.36 MBytes [ 4] 4.00-5.00 sec 7.50 MBytes 62.9 Mbits/sec 54 1.22 MBytes [ 4] 5.00-6.00 sec 8.75 MBytes 73.4 Mbits/sec 0 1.22 MBytes [ 4] 6.00-7.00 sec 7.50 MBytes 62.8 Mbits/sec 0 1.24 MBytes [ 4] 7.00-8.00 sec 8.75 MBytes 73.5 Mbits/sec 0 1.16 MBytes [ 4] 8.00-9.00 sec 8.75 MBytes 73.3 Mbits/sec 0 1.21 MBytes [ 4] 9.00-10.00 sec 11.2 MBytes 94.4 Mbits/sec 0 1.41 MBytes [ 4] 10.00-11.00 sec 8.75 MBytes 73.4 Mbits/sec 3 1.59 MBytes [ 4] 11.00-12.00 sec 7.50 MBytes 63.0 Mbits/sec 46 1.58 MBytes [ 4] 12.00-13.00 sec 10.0 MBytes 83.9 Mbits/sec 0 1.27 MBytes [ 4] 13.00-14.00 sec 7.50 MBytes 62.9 Mbits/sec 25 1.17 MBytes [ 4] 14.00-15.00 sec 11.2 MBytes 94.4 Mbits/sec 0 1.40 MBytes [ 4] 15.00-16.00 sec 11.2 MBytes 94.4 Mbits/sec 15 616 KBytes [ 4] 16.00-17.00 sec 6.25 MBytes 52.4 Mbits/sec 9 1.25 MBytes [ 4] 17.00-18.00 sec 8.75 MBytes 73.4 Mbits/sec 252 1.15 MBytes [ 4] 18.00-19.00 sec 7.50 MBytes 62.9 Mbits/sec 0 1.24 MBytes [ 4] 19.00-20.00 sec 10.0 MBytes 83.8 Mbits/sec 29 684 KBytes [ 4] 20.00-21.00 sec 7.50 MBytes 62.9 Mbits/sec 0 1.24 MBytes [ 4] 21.00-22.00 sec 7.50 MBytes 62.9 Mbits/sec 194 1.26 MBytes [ 4] 22.00-23.00 sec 8.75 MBytes 73.4 Mbits/sec 0 1.25 MBytes [ 4] 23.00-24.00 sec 7.50 MBytes 62.9 Mbits/sec 0 1.16 MBytes [ 4] 24.00-25.00 sec 12.5 MBytes 105 Mbits/sec 0 1.43 MBytes [ 4] 25.00-26.00 sec 6.25 MBytes 52.4 Mbits/sec 46 1.42 MBytes [ 4] 26.00-27.00 sec 8.75 MBytes 73.4 Mbits/sec 0 1.40 MBytes [ 4] 27.00-28.00 sec 8.75 MBytes 73.4 Mbits/sec 18 1.24 MBytes [ 4] 28.00-29.00 sec 8.75 MBytes 73.4 Mbits/sec 0 1.23 MBytes [ 4] 29.00-30.00 sec 10.0 MBytes 83.9 Mbits/sec 0 1.37 MBytes [ 4] 30.00-31.00 sec 7.50 MBytes 62.9 Mbits/sec 0 1.26 MBytes [ 4] 31.00-32.00 sec 8.75 MBytes 73.4 Mbits/sec 64 1.15 MBytes [ 4] 32.00-33.00 sec 8.75 MBytes 73.4 Mbits/sec 0 1.16 MBytes [ 4] 33.00-34.00 sec 10.0 MBytes 83.9 Mbits/sec 0 1.34 MBytes [ 4] 34.00-35.00 sec 8.75 MBytes 73.4 Mbits/sec 0 1.34 MBytes [ 4] 35.00-36.00 sec 8.75 MBytes 73.4 Mbits/sec 0 1.26 MBytes [ 4] 36.00-37.00 sec 8.75 MBytes 73.4 Mbits/sec 0 1.29 MBytes [ 4] 37.00-38.00 sec 8.75 MBytes 73.4 Mbits/sec 0 1.25 MBytes [ 4] 38.00-39.00 sec 7.50 MBytes 62.9 Mbits/sec 0 1.25 MBytes [ 4] 39.00-40.00 sec 10.0 MBytes 83.8 Mbits/sec 0 1.16 MBytes [ 4] 40.00-41.00 sec 11.2 MBytes 94.4 Mbits/sec 0 1.37 MBytes [ 4] 41.00-42.00 sec 10.0 MBytes 83.9 Mbits/sec 0 1.38 MBytes [ 4] 42.00-43.00 sec 7.50 MBytes 63.0 Mbits/sec 79 1.07 MBytes [ 4] 43.00-44.00 sec 8.75 MBytes 73.4 Mbits/sec 34 728 KBytes [ 4] 44.00-45.00 sec 7.50 MBytes 62.9 Mbits/sec 99 1.38 MBytes [ 4] 45.00-46.00 sec 7.50 MBytes 62.9 Mbits/sec 200 1.38 MBytes [ 4] 46.00-47.00 sec 8.75 MBytes 73.4 Mbits/sec 62 1.21 MBytes [ 4] 47.00-48.00 sec 7.50 MBytes 62.9 Mbits/sec 22 1.26 MBytes [ 4] 48.00-49.00 sec 8.75 MBytes 73.5 Mbits/sec 0 1.33 MBytes [ 4] 49.00-50.00 sec 8.75 MBytes 73.4 Mbits/sec 5 1.23 MBytes [ 4] 50.00-51.00 sec 7.50 MBytes 62.8 Mbits/sec 0 1.25 MBytes [ 4] 51.00-52.00 sec 10.0 MBytes 84.0 Mbits/sec 0 1.30 MBytes [ 4] 52.00-53.00 sec 7.50 MBytes 62.9 Mbits/sec 0 1.29 MBytes [ 4] 53.00-54.00 sec 8.75 MBytes 73.4 Mbits/sec 4 1.26 MBytes [ 4] 54.00-55.00 sec 7.50 MBytes 62.9 Mbits/sec 0 1.24 MBytes [ 4] 55.00-56.00 sec 8.75 MBytes 73.4 Mbits/sec 0 1.23 MBytes [ 4] 56.00-57.00 sec 7.50 MBytes 62.9 Mbits/sec 0 1.19 MBytes [ 4] 57.00-58.00 sec 10.0 MBytes 83.9 Mbits/sec 0 1.23 MBytes [ 4] 58.00-59.00 sec 7.50 MBytes 62.9 Mbits/sec 0 1.21 MBytes [ 4] 59.00-60.00 sec 6.25 MBytes 52.4 Mbits/sec 0 1.24 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - Test Complete. Summary Results: [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-60.00 sec 520 MBytes 72.7 Mbits/sec 1625 sender [ 4] 0.00-60.00 sec 514 MBytes 71.8 Mbits/sec receiver CPU Utilization: local/sender 1.5% (0.1%u/1.3%s), remote/receiver 3.5% (0.4%u/3.2%s) iperf Done. also did not tweak kernel settings too much atm - both ends read: net.core.default_qdisc = fq_codel net.core.netdev_max_backlog = 1024 net.core.rmem_max = 33554432 net.core.wmem_max = 33554432 net.ipv4.tcp_rmem = 4096 87380 33554432 net.ipv4.tcp_wmem = 4096 87380 33554432 net.ipv4.tcp_congestion_control = bbr # RETEST westwood OR cubic net.ipv4.tcp_max_syn_backlog = 1024 net.ipv4.tcp_slow_start_after_idle = 0 net.ipv4.tcp_no_metrics_save = 0 net.ipv4.ip_local_port_range = 9000 65535 If you want a cheap and low wattage VPN consider H5 boards ( eg nanopi neo2 or orange pi zero plus2 ) that should handle proper TV streaming (15-20Mbit) over ovpn this is your option. If speed will be most important consider other platforms, I'm currently looking in to the ASRock J4005B-ITX and should do 300Mbit ...

isn't jessie deprecated now anyway, since stretch came to life officially last year. I am aware many are still on jessie as it will be maintained till 2020? Anyway, DNS I assume in Stretch either " /etc/resolvconf/resolv.conf.d " or as it used to be ( thru /etc/network/interfaces ) in Jessie.

thanks a lot, this helped a lot. I managed now by cleaning file " head " as that contained the google DNS entry I was looking for and is the primary entry. The tool " nmtui " still can be used to add DNS entries, but instead I believe these can be added to " head " so no need to use the text user interface. thanks again

Hi - I flashed a new nanopineo2 with debian9 ( Armbian_5.44.180510_Nanopineo2_Debian_stretch_next_4.14.40 ) and set this to stable build before updating to latest "stable". Next step after reboot is to configure my static network ( eth0 ), but here things tend to be a bit different than previous flash ? Previously in advanced I edited /etc/network/interfaces to add my DNS-servers but in this build it seems " Network is managed by NetworkManager " so I instea I used " nmtui " to set these for "Wired Connection 1". Unfortunately I still see in /etc/resolv.conf : " nameserver 8.8.8.8 " first before my entries. I like to get rid of this nameserver but I am unable to find it. Anyone please? TiA!